Three different databases for gsm celltower locations

[Onen]

Hi,

Jan Lübbe wrote:
> 
> The cell db is currently exposed via ogsmd. The "location" interface
> should be distinct from that. I've been talking with Daniel about this
> for some time:

If you put the GSM db in ogsmd, what about future WiFi or sth else 
databases? Where would you put them? I was thinking about putting the db 
in "location" service.

> * each client should request an accuacy and an update frequency, the
> location daemon will then choose the an approach to find the location
> (cells/wifi, GPS)

Why an update frequency? I was thinking about a location daemon which 
would use everything possible to get the best accuracy (+ some rules 
about which means to use, to prevent battery for example).

Then it would provide it uppon request, or by signaling a position change.

I can imagine your approach would allow to use a less power angry mean 
of location, if this fits precision expected from the client?

> * maybe also some notifications for locations
>  
>> I would like to know what is your opinion about all of this. Are you 
>> interested in our approach, and are you interested in taking in 
>> consideration in your code the extra fields our data contains (Dops, 
>> speed, software id, software version, etc.) to possibly filter measures 
>> to keep only higher quality?
> 
> I would propose to include even more data:
> * some GPS receivers can give an inaccuracy in cm in addition to DOP,
> this even includes position errors from reflections, fading and not just
> the satellite position geometry

Did not know that, I would welcome this in the database, for sure.

> * speed and *direction*, the handover algorithm used by operators take
> these into account, so we should collect them

openBmap already stores GPS "speed" and "heading".

> * if we are in a call or have a GPRS

I have noticed that signal strength reported by framework was decreasing 
when in a call. To prevent from interactions, I have added code to only 
log when not in a call.

> * if available, log the timing advance
> * don't log each neighbour seprately, but upload a "measurement report"
> with time, position and *all* current cells (serving + neighbours). also
> log what the max amount of tracked neighbours is. then we can deduce
> which cells are *not* visisible at that position. this should give us
> better accuracy by using signal shadowing.

The structure of our log unit is: one "scan" with scanning time. This 
scan unit contains: GPS data, GSM serving, (and neighbours, beta code, 
not activated so far). Would that fit your expectation?
Why would that be important to be not logged separately, it can be 
retrieved afterwards in the database, isn't it?

> * also allow logging of different radio technologies (GSM, UMTS,
> Bluetooth, Nearfield/RFID, WiFi b/g, ...) with the same measurement
> report.
> 

That is our original vision.

> Also please take a look at:
> http://lwn.net/Articles/304218/ and http://lwn.net/Articles/325016/ 
> 

I am an OpenStreetMap contributor, and knew all of this when we started 
the project. Still we chose the same license as OSM, and thought we may 
make the same move as them. Many people at OSM have been forging this 
license: we at OBM would not have been able to do better ;-)

Onen