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 <jlue...@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@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
