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