Future of location services on OM

Stefan Schmidt stefan at openmoko.org
Thu Jan 15 00:59:52 CET 2009


On Thu, 2009-01-15 at 00:18, Onen wrote:
> Stefan Schmidt wrote:
> >
> > Great. What interface do you use for this? Already the new monitor interface?
> >   
> Well, no. Would you mind pointing me more precisely what you are talking 
> about? I use code similar to the examples you find in the 
> /usr/share/freesmartphone/examples files. That is to say, 
> org.freedesktop.Gypsy interfaces (GetPosition, GetCourse).

It's a GSM monitor for cell informations. Also neighbour cells. And yes, you got
us. Not documented API until now. Mickey fixed it:


> > Seriously, if you come up with some ideas and  code for something like olocationd
> > we would appreciate it.
> >   
> I am not aware of this, I cannot find it in the FSO API documentation. 
> Where can I find some more information?

I used olocationd as a synonym for what you will create. It does not exist yet,
neither the docs.

> > Once you have a recipe ready we can put it into OE, build it and put it into the
> > feed.
> >   
> Ok. So far I had a quick look at the way to build an opk package. I will 
> look at this afterwards.

Sure, just ping me if you have something you want to integrate into the feed.

> > IIRC the new monitor interface should give you the needed infos. Jan just put
> > some code into zhone to demonstrate the usage. It's python, check it out.
> >   
> I have noticed that things were coming on this side. But first release 
> the basics.

Jup, Release early and often. No need to make everything in one release.

> >> * another application using the openBmap database located on the phone, 
> >> to get location ( I have a quick look at rocinante, it seems you guys 
> >> already built something for use inside TangoGPS. Would be nice :-) ). 
> >>     
> >
> > I'm more in favor of navit as it is real navigation and not only displaying
> > images. But that's a matter of taste.
> >   
> 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
* 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.
> >   
> Ok, then we have the same thing in mind :-)
> I was thinking about Tichy in the way of plugins:
> * one tichy plugin which provides let's say GPX files
> * one tichy plugin which gathers GSM and package this with GPX
> * one upload plugin
> * one plugin which updates the local database
> * one tichy plugin which provides GSM location,

Tichy plugins are for the user interface part. I would put none of the above
into it. That's what we have the framework for.

> * one plugin which consumes it.

That could be the right place for a consumer.

With this method all the goodies would also be available to SHR or other
applications in an easy way.

> My main point was providing a GSM location service, embedded in the 
> phone. I love my privacy (no need to ask any third party on the Internet 
> where I am located ;-)), and my battery (GSM is on all the time anyway, 
> GPS needs quite a lot of power, plus waiting for the fix).

Good thinking. Just work on your current code and make a release. People can
play with it and you can come up with other interested people and work on
putting it into the framework.

Stefan Schmidt

More information about the devel mailing list