Three different databases for gsm celltower locations

[Yorick Moko]

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
> 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
>
>
> _______________________________________________
> devel mailing list
> devel at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/devel
>