Three different databases for gsm celltower locations

[Jan Lübbe]

Please excuse the late reply...

On Mon, 2009-04-06 at 21:53 +0200, Onen wrote:
> Hallo Jan,
> 
> I have seen the last commits from you about adding GSM based localisation.
> 
> First this is great, that it reaches the framework!
> 
> This brings me some questions:
> 
> 1. This has been especially a surprise to us, as we at openBmap have 
> currently been thinking how to bring this to the users. We already did 
> some work on exporting the database under SQLite files for every 
> country. And on top of this, a small DBus service to bring the 
> localisation to everyone...

I hacked this together in some spare hours while i was in Bern for
OpenExpo, so this is in no way the final code or interface. I just
wanted to try out the data i've been collecting with Cellhunter (BS
conenction).

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:
* 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)
* maybe also some notifications for locations

> I am no hacker, but still would have hoped to bring some help on this... 
> If you are interested, how would you like to proceed?

> 2. I had a look at the code, and suppose you are building your database 
> out of the data from CellHunter. Am I correct?

Yes. The "algorithm" i use is extremly simple:

I just calculate the boundingbox of all measurements for a given cell
and then store the center and "radius" in a binary file.

When calculating the position, i just average all found positons, or if
none a found, take the center of the LA's bounding box.

> I think CellHunter is a great project but we still think that we should 
> log HPV-Dops, speed, in order to be able to filter low quality measures. 
> This is currently discussed on another thread on this list [1]. If you 
> combine a high speed with low Dops, you end up with very unprecise 
> positions for building the cells coverage, don't you think?

For now even the signal strength is not used in my code. Still, it gives
an accuracy that should be useful for AGPS.
 
> 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
* speed and *direction*, the handover algorithm used by operators take
these into account, so we should collect them
* if we are in a call or have a GPRS
* 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.
* also allow logging of different radio technologies (GSM, UMTS,
Bluetooth, Nearfield/RFID, WiFi b/g, ...) with the same measurement
report.

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

-- 
Jan Lübbe <jluebbe at lasnet.de>            http://sicherheitsschwankung.de
 gpg-key      1024D/D8480F2E 2002-03-20
 fingerprint  1B25 F91F 9E7B 5D4F 1282  02D6 8A83 8BE4 D848 0F2E