Future of location services on OM

Mat Real realtimeblog at gmail.com
Mon Jan 12 16:03:50 CET 2009


Gents,

I am responsible for the openBmap website: http://www.openbmap.org

As mentioned on the main page
"openBmap is a free and open map of wireless communicating objects
(e.g. cellular antenna, Wi-Fi, Bluetooth). It provides tools to mutualize
data,
create and access this map. "

At this time, only cellular networks are concerned.
All the software code is AGPL v3 and data are Creative Commons License
(creative commons Attribution-Share Alike 3.0 Unported)

This site is quite similar to the opencellid.org website
(and I am currently merging the opencellid data into the openbmap database)

I identify tow main differences between openbmap.org and opencellid.orgsites:

1) the way the coordinates of cells are calculated.

I am not using a simple barycenter method but the following method:

For a set of gps points concerning a cell, I identify the gps points which
belong
to the envelope of the cell zone. After that I use the barycenter method on
these points.

This method is not perfect but it works fine and can be much more precise
than a simple
barycenter method.

For each cell zone, I generate a kml file. This is nice to see how cells
enveloppe and
how coordinates have been generated.

http://realtimeblog.free.fr/cell_map.php?mcc=208&mnc=1&lac=1024&cellid=55608&display=Display

http://realtimeblog.free.fr/kml/cell_208_1_1024_55608.kml in google earth


2) the openBmap database contains much more information than opencellid
one.(for raw data
and for processed zone data)

We are keeping track of all attributes available such as:

*** gsm signal strength
*** quality of gps received
...

These attributes are not available in opencellid database. From these
"extra" datas,
we can for example decide to use only gps data of correct quality (with low
vdop, hdop, hdop)

About the Android solution, the main drawbacks I see:
*** you must always be connected to get GPS coordinates from
mcc/mnc/lac/cid.
*** the cell database is not complete (tested from France, Paris suburb)


On our side, we plan to introduce an offline mcc/mnc/lac/cid->gps database.
but at this time, only one api is available at
http://realtimeblog.free.fr/api/getGPSfromGSM.html

What is interesting with this api is that if the cell is not in the
database, it returns
the lac position and the max radius of the lac

For your information I have implemented a reverse geocoding in the Mapping
Manager
in order to get the name of the city where the cell coordinates points at.


About openBmap client side, as you can see on the web site, a windows mobile
version
is available. It logs mcc/mnc/lac/cid/signal strength and gps data.

The openmoko version is almost ready !
The gsm/gps capture is ready and I guess it will be soon out.
The developer in charge will post soon on this thread.

Of course, I am here to provide you with all the information you need.
(and to change API if needed...)


kind regards,
Nick

2009/1/12 Stefan Monnier <monnier at iro.umontreal.ca>

> > I'm just curious how much this is built into the Android code. If any
> > Android phone can call the mothership to get the information, why
> > shouldn't we be able to do that? There are unlocked Andorid phones on
> > sale - do they have cell-based positioning disabled??? I would wager
> > that it isn't....  So what is the limit if is in the Android code?
> > Phones sold by Google? Phones supported with Android? Any phone
> > running Android? Any phone running an OS based on Android?
>
> Think about it: the provider cannot reliably tell if your phone logs
> this data or not.  So if you write your own code that does that, they'll
> never know, so even if their contract doesn't allow you to do it,
> they'll never be able to enforce it (and won't even try, I'd guess).
> If Google distributes an OS that does that, the providers will know, so
> Google has to arrange some contract with them, to avoid prosecution.
>
> The providers don't care about individual uses, only about the
> larger picture.
>
> So, it's OK to write and distribute such code for the FR, but if OM
> starts distributing it they may be exposing themselves, although they're
> probably marginal enough that it doesn't matter much (yet).
>
>
>        Stefan
>
>
> _______________________________________________
> devel mailing list
> devel at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/devel/attachments/20090112/c316badb/attachment-0001.htm 


More information about the devel mailing list