Future of location services on OM

[Joel Newkirk]

On Thu, 15 Jan 2009 00:59:52 +0100, Stefan Schmidt <stefan at openmoko.org>
wrote:

>> I was referring to the fact that I could use their code to do something
>> similar. But what I have in mind is to provide a dbus service, providing
>> GSM based location. Now I think I understand what you meant above in
>> your mail, about integration in FSO. Is it what you had in mind?
> 
> I was thinking along these lines, just thinking , no code or descision:
> 
> * ogsmd offers the MCC/MNC/LAC etc informations via dbus, no need to
> duplicate
> this.
> * What different _does_ you offer? Location from GSM.
> * A dbus interface that gives you the name of the city or even the
> district with
>   zero extra costs like tunring on the GPS would be nice.
> * You could offer the appr. GPS coordinates from the db. How would we
> integrate
>   this? Some dummy GPS device?
> * We want for sure use this when we power up GPS to set the appr.
location
> so we
>   can get a faster fix.
> 
> This kind of stuff I would like to see as a service via dbus. Prefered
> would be
> a subsystem in FSO. This would fit into a framework as it provides data
> that
> different applications can use.
> 
>> > Well, I would not put to much into the application itself. We have a
> framework
>> > you improve to your own needs. That's really different from other
> systems, make
>> > use of it! :)
>> >
>> > Meaning, I would put the logic and the communication with the
> webservice either
>> > in a fso subsystem or in a small daemon process. Eyporting a nice API
> will allow
>> > more then one app to make use of it.

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


-- 
Joel Newkirk
http://jthinks.com      (blog)
http://newkirk.us/om (FR stuff)