Three different databases for gsm celltower locations
yorickmoko at gmail.com
Tue Apr 7 14:41:09 CEST 2009
i can only see possible enhancements when logging more
and those who find that extra data not usefull just ignore those parts in the db
On Tue, Apr 7, 2009 at 9:08 AM, Jan Lübbe <jluebbe at lasnet.de> wrote:
> 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
> 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 . 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
> 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
> devel mailing list
> devel at lists.openmoko.org
More information about the devel