Future of location services on OM
stefan at openmoko.org
Wed Jan 14 23:01:28 CET 2009
On Mon, 2009-01-12 at 23:52, Onen wrote:
> Stefan Schmidt wrote:
> > On Mon, 2009-01-12 at 16:03, Mat Real wrote:
> >> For each cell zone, I generate a kml file. This is nice to see how cells
> >> enveloppe and
> >> how coordinates have been generated.
> > The maps looks already quite nice, even if germany is not in the db yet. ;)
> Of course it is, I take care of Germany by myself so far ;-)
My bad. I searched only for Vodafone and E-Plus not for O2. :)
> >> The openmoko version is almost ready !
> > How does it get the gsm and gps data? I hope from the FSO framework!
> What else? ;-)
Great. What interface do you use for this? Already the new monitor interface?
> >> The gsm/gps capture is ready and I guess it will be soon out.
> >> The developer in charge will post soon on this thread.
> > Great.
> Indeed ;-) . I have been working on a freerunner logger. My target is:
> simple and stable. It is pretty straight forward:
> * GUI (pygtk) displays current GPS data, GSM data (MCC, MNC, lac, cell
> id, signal strength, etc...).
> You have so far four buttons: start logging, stop logging, upload, exit.
> * The main part (python) creates small log files containing the GPS and
> GSM data. And upload it.
> What remains before releasing:
> * upload to openBmap server is not working yet
> * save config file
> * packaging
Sounds like a good and fast approach. Once this is done we could think about how
we could integrate such things clever into fso. Sascha was already interested
and if you are also there would already be a team. :)
Seriously, if you come up with some ideas and code for something like olocationd
we would appreciate it.
> I take this opportunity to ask for advice: I was wondering where would
> be the best place to put the code and package? I have been thinking about:
> * sourceforge page of the openBmap project (aka keeps everything
> together option)
> * projects.openmoko.org (aka what is linked to openmoko, stays at
> openmoko option)
> * or merge with the projects.openmoko.org/projects/rocinante/ (aka why
> reinvent the wheel option)
> What do you think would be the best place?
All of them are fine. As long as you have a place where we could fetch it, OE
could build it. :)
> And get the package in the feeds, would be also a target.
We can take care of this. Do you use distutils? if yes, writing a OE recipe (the
bb file) should be easy. Have a look at the other python packages in OE.
Once you have a recipe ready we can put it into OE, build it and put it into the
> TODO (among others...):
> * display/log neighbour cells
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.
> * 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.
> * move all of this into Tichy?
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.
More information about the devel