Future of location services on OM

[Stefan Schmidt]

Hello.

Sorry that it took that long. Such a proposal needs a bit more thinking then
easy two sentence mail replies. :)

On Fri, 2009-01-16 at 02:28, Sascha Wessel wrote:
> 
> On Mon, Jan 12, 2009 at 10:31:00PM +0100, Stefan Schmidt wrote:
> 
> ok, one possibility would be the geoclue api (as already mentioned by
> various people on the mailinglists).

For this we would need at least to check if the project is still alive and how
intersted they are in APIs that we may want to add.

> An alternative would be a more
> generic mapping of location-depended informations (please note that
> this is only a very raw concet so far).

Some quick feedback below. I'll poke other people after MS5 to also have a look.

> 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)

Good idea. Never thought about this as an location source. :)

> * 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

How do you like to handle the accuracy here?

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

I really like this.

Of course we have to pay this flexibility with more work in the actual
implementation, but IMHO a flexible and powerful API is worth it.

> 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
> * ...

Good stuff. Plugins, or something similar, do we need for sure with all this
different location data sources. Fine with me.

> 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()

What do the openBmap guys are thinking about this? This sounds to me like a good
aaproach and handles the tasks we discussed earlier in this thread.

> 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()

For the signals we need to know a mixture of radius and accuracy to trigger
them. Needs to be saved with the name.

The naming schmeme needs a lot thinking I fear. It is great for users as it
gives them an easy understanding where they are, but on the engineering side I
get a bit of a headache when thinking how to handle this nicely. We have to find
a way. :)

> 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.

Hmm, not sure if we need an API for this. We will have a "internet available"
signal once the network stuff gets in place. Wouldn't a simple rules that
triggers on this and update the time via ntp be fine here?

> > > 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

Cool. Need to try this out.

Thanks for coming up with such a proposal. It's way easier to discuss this topic
this way. Perhaps it would also be a good idea to send it to
smartphone-standards to gather more feedback.

regards
Stefan Schmidt