Future of location services on OM

[Joel Newkirk]

On Thu, 15 Jan 2009 22:36:39 +0100, Onen <onen.om at 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 at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/devel
-- 
Joel Newkirk
http://jthinks.com      (blog)
http://newkirk.us/om (FR stuff)