Future of location services on OM
onen.om at free.fr
Thu Jan 15 22:36:39 CET 2009
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.
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.
More information about the devel