On Thu, 15 Jan 2009 22:36:39 +0100, Onen <onen...@free.fr> wrote: > Hi, > > these are interesting ideas. At the moment I imagine building something > really simple. Give cell id to location system, gets position. > > I then would like to test the use of neighbour cells to increase > accuracy, by identifying the smallest common area. Give cell idS to > location system, gets position. > > As Nick pointed to me, use neighbour cells to build the database brings > a risk of enlarging quite a lot the cells diameter, thus nullifying the > benefit from using more cells at a time. > > Onen
I don't see that. If we look at the current and neighboring cells and the current cell is NOT in the DB with coords, but two neighboring cells ARE, then we can feed the APGS with the midpoint between those two known neighbor cells, and an accuracy radius of perhaps 30km*. This has quite limited usefulness for informing the user of location, but is sufficient for a significant improvement in GPS time-to-first-fix. (of course that presumes ability to retrieve AGPS assistance data via GPRS or some other on-demand connection) Lots of processing /could/ be performed to narrow it down, IE if we see two known (in-DB) neighbor cells and already have known data stored on cells surrounding those two on two or three sides, but I don't know if the extra processing (and coding) required would be worth it. But simply saying "OK, I don't know /THIS/ cell, but two neighbors are each within 10km* of xx yy so I'm sure to be within 30km* of that point too" seems useful to me. Take it a small step further and say "OK, I know neighbor X and it's strong enough that I could be using it even though Y is what I'm using since it's stronger, so I must be close to X". j * I'm making these numbers up. In actual practice the range is dependant on terrain, power capability of the cell site, frequency involved, etc. IE, 850mhz is much better at penetrating obstructions like trees and walls than 1900Mhz, so as a result higher-frequency cells tend to be located more closely together - particularly where terrain or development present obstructions. A reasonable model of what tower density and ranges are actually utilized on various freqs would be critical to properly massage this data and get useful results. > > Joel Newkirk wrote: >> >> I was contenplating (and proposed via ML, IIRC) some time ago utilizing > a >> local DB to store correlations between GSM towers, visible wifi APs and > GPS >> coords when GPS /was/ on, and later retrieving those coordinates > (rounded >> and noting error) on demand by simply requesting 'current location'. If >> GPS is on that can of course supply precise data from the GPS, but if > it's >> off and the DB includes reference to a visible GSM tower or wifi AP it > can >> return the stored coords with accuracy represented as a separate value. >> (eg '5' indicating +-5km) >> >> So this would entail the DB itself, a daemon stuffing newly-discovered >> correlations into it, and a dbus interface that both provides current > GPS >> coords if available (with error noted as '0' meaning "presumed > accurate"), >> and provides DB-retrieved approximations when necessary and available. >> Presuming a daemon in use, it could also calculate rougher > approximations >> based on understanding that even though it has no GPS data stored for > the >> current GSM towers visible, that 10 minutes ago it saw a GSM tower it > DID >> have in the DB, and return coords with a larger error factor noted. >> >> j >> >> >> > > > _______________________________________________ > devel mailing list > devel@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/devel -- Joel Newkirk http://jthinks.com (blog) http://newkirk.us/om (FR stuff) _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
