Future of location services on OM

[Sascha Wessel]

Hi,

On Mon, Jan 12, 2009 at 10:31:00PM +0100, Stefan Schmidt wrote:
> So far we have no real structurized ideas how we would like to handle all this
> nice location opportunities aside GPS. Stuff like
> 
> - timezone from GPS coordinates
> - City from GSM cell
> - ...
> 
> are just small things we could offer applications this way.
> 
> If you, and other interested people, would come up with ideas for how we should
> handle this in FSO that would be great. From our side I fear not much will come
> before the MS5 milestone.

ok, one possibility would be the geoclue api (as already mentioned by
various people on the mailinglists). An alternative would be a more
generic mapping of location-depended informations (please note that
this is only a very raw concet so far).

Ok, first some examples of location-dependent informations:
* position (lat, lon)
* altitude
* name (e.g. University of xyz, Room 1234)
* profile
* timezone
* country
* city
* street
* wlan ap
* gsm (mcc, mnc, lac[], cid[], rxlev[])
* phone number prefix (+49 -> Germany, +4930 -> Berlin)
* weather
* contact -> opimd
* ...

olocationsd could provide some universal query syntax to map one or more
of these informations to one or more other informations:
  Location.Query(a{sv}, a(s)) -> a{sv}
  * Parameters:
    - a{sv}: what i know (special case: [] = use actual position)
    - a(s): what i want (one of the strings above)
  * Returns
    - a{sv}: whatever was requested + accuracy

Some examples:
  Location.Query([], [profile])
  Location.Query([], [position, country, city, street])
  Location.Query([{contact = Sascha}], [weather])
  Location.Query([{phone = +4930...}], [timezone, country, city])

Internally olocationsd could provide some sort of a plugin based
architecture with different providers for (preferably simple)
mappings, e.g:
* [] -> [lat/lon, alt]          Gypsy.Get{Position|Accuracy}
* [] -> [gsm]                   GSM.Monitoring.Get{Serving|Neighbour}CellInformation
* [wlan ap] -> [lat/lon, alt]   wlan + local db (+ auto logging)
* [gsm] -> [lat/lon, alt]       gsm + remote db, e.g [1][2]
* [gsm] -> [lat/lon, alt]       efficient gsm fingerprinting (see below)
* [gsm] -> [country]            gsm + /etc/freesmartphone/ogsmd/networks.tab
* [lat/lon] -> [country, city]  local db (share with navit?)
* [country] -> [timezone]       /usr/share/zoneinfo/zone.tab
* [lat/lon] -> [timezone]       local db (get timezones into osm? and dump
* ...                           this data? country borders are already there...)
* [] -> [lat/lon]               gsm (o2 germany) + cb channel 221
* ...

In the case of openBmap (of course you can use osm or whatever
db you like) we register a mapping function for:
        [gsm] -> [lat, lon, alt, accuracy]
And maybe you want to provide some openbmap specific methods:
  Location.Openbmap.EnableLogging(b)
  Location.Openbmap.SyncDB()
  Location.Openbmap.Upload()

Another example would be an provider for named areas:
        [name] -> [lat/lon, radius]
Additional methods:
  Location.Area.Register(lat, lon, name)
  Location.Area.Unregister(name)
Signals:
  Location.Area.Enter()
  Location.Area.Leave()

olocationd's primary task would be to find each possible path from the given
informations to the requested informations and to merge these informations
according to their accuracy.

Another "feature" that I want is something like
  Location.SetAllowInternetAccess(b)
  Location.GetAllowInternet(Access) -> b
This could also be useful for otimed's ntp service.

> > If someone is interested, I will clean it up and put it online.
> 
> For sure.

I've attached the source. cell-log.py is just a simple script to log
rxlev values of gsm cells using Get{Serving|Neighbour}CellInformation.
The c program (celldb) builds a berkeley db with areas of overlapping cells
and calculates the current position based on this db and rxlev values.
A `make run` should start logging and position calculation:

GPS: 49.5906/11.0352 GSM: 49.5911/11.0344 ERR: 76.4m AVG-ERR: 68.3m
GPS: 49.5905/11.0352 GSM: 49.5910/11.0344 ERR: 81.2m AVG-ERR: 68.5m


Greetings,
Sascha


[1] http://maps.alphadex.de/datafiles/location_from_cell_info.py.txt
[2] http://developer.yahoo.com/yrb/zonetag/locatecell.html