Future of location services on OM

[Stefan Schmidt]

Hello.

Al gave a good description already. Let me add some informations and thoughts to
it.

On Sat, 2009-01-10 at 11:20, Al Johnson wrote:
> On Saturday 10 January 2009, Gergely Imreh wrote:
> >
> > The IMHO best would be a d-bus 
> > interaction with the userspace software, because it will put the
> > burden of interpreting the NMEA  (and possible other) messages on the
> > LocationProvider, so the userspace software does not have to duplicate
> > the functionality (less possible points of failure).
> 
> ogpsd does exactly this. On GTA02 it reads native binary UBX format data from 
> the ublox gps chipset and interprets it to produce gypsy format data on dbus. 
> I think it reads NMEA from gllin on GTA01 but I haven't looked into it as I 
> don't have one. 

On GTA01 it is a NMEA stream that get parsed, correct. On GTA02 we use the UBX
protocol as it allows us to configure the GPS chip. Uploading almanac, ephemeris
and D-GPS informations for example. There are a lot more configuration options
that we don't even use yet, but plan to. The UBX binary protocol reference
should give more details for the interested people.

> >   Previously, a few of us tried to make a fast positioning app based
> > on GSM cell info [4-5], but we had to map the cell tower positions
> > ourselves (pretty imprecise) and do the position discovery algorithm
> > (I think I borked that a bit, sometimes it was good, by chance, most
> > of the time it was very off).  Andorid uses Google's on cell database,
> > but I'll check it out, whether we too would be able to / allowed to
> > use that info. Will try to learn from them, not to clone, but to make
> > less mistakes.
> 
> FSO has just gained a GetNeighbouringCellInformation command which may be 
> useful in this context.

Having a database with GSM cell location informations would indeed be great.
With the available informations you get from the framework it should be easy to
write a small logger that does the job.

The problem for this may come from the legal side and not the technical one.
IIRC we had this here before. Let me try to describe the problem. To log the
cell id you need to be booked into the cell, thus having a contract with the
provider. Now these provider see the value of this location data and like to
sell to interested parties thus disallow you to log it. (Hope I got this right)

A database with wifi AP locations may be easier as 802.11 lives in the ISM band
and thus available without a contract with some provider.

I don't want to de-motivate people to work on this things just want point out
potential issues.

> >   I was thinking, what route you think would be more advantageous for OM?
> >   Gpsd / gypsy / multi-provider Android-type / other? There might not
> > be a single preferred way, and you might say that it's not the core
> > teams responsibility. In any case, I'd be interested in your opinion.
> > (I hope I'm not replicating a previous discussion either :)
> 
> For pure GPS data the current combination works well, barring implementation 
> bugs. Extra location sources would be useful for times when gps isn't 
> available. I think it would be reasonable to provide this as a dummy gps 
> device under gypsy to provide an interface to current programs. Some protocol 
> extensions could then be used to make the non-gps aspects available to 
> programs that want to use them. There would be some interesting work in 
> integrating multiple data sources

There is also geoclue, no idea how active they are at the moment tho.

http://www.freedesktop.org/wiki/Software/GeoClue

regards
Stefan Schmidt