[openBmap] New cells visualisation interface on the website (beta)

[Onen]

Hi,

Alex (Maxious) Sadleir wrote:
> 
> For me, the average position markers on the website map give a good but 
> simple indication of how well covered an area is. I don't know of any 
> openmoko gps programs that can handle overlaying colored regions but 
> individual points are represented in Navit and TangoGPS.
>  

Then I would suggest not to display the average cell position as 
displayed on our map, but the positions of measures.

>      > Is there any work underway into opening/fixing the API?
> 
>     What API?
>     What is not open?
>     What needs to be fixed?
> 
> 
> I've tried using the API page at 
> http://realtimeblog.free.fr/api/getGPSfromGSM.html but it never returns 
> useful results for me even when the map shows a radius. For example 
> given MCC: 505, MNC: 2, LAC: 2624, Cellid: 12213, I get
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <gsm mcc="505" mnc="2" lac="2621" cid="12213">
> 
> <zone countrynamecode="Australia" />
> 
> </gsm>
> 

Hey, we were not aware of that! I have just tried and it does not work 
for me neither. I ping Nick about this and will come back to you!

> What would be good to be open is the edge points of a given cell, just 
> like you can see in the map: 
> http://realtimeblog.free.fr/with_osm4.php?mcc=505&mnc=2&lac=2624&cellid=12213&zoom=13 
> <http://realtimeblog.free.fr/with_osm4.php?mcc=505&mnc=2&lac=2624&cellid=12213&zoom=13>
> 

Nick is working on integrating this info in the SQL statements I pointed 
in my previous emails. In fact they are already open, as they lay in the 
KMLs, but of course this would make things easier to play with, right?

> I'd eventually be wanting to use several cells in combination, along 
> with their signal/rx strength to try to work out a more accurate 
> position.

Well that is the whole point of our project. I have started the work on 
the D-Bus location service on the phone. Maybe that would be the right 
place to plug different location algorithms to try them? What do you think?

  Other geolocation APIs let you send in those details to work
> out the predicted position and error radius, but perhaps OM developers 
> would want to use the openness of the data to develop their own 
> prediction method on the local device.
>  

Again, that has always been on the ToDo list of the project. And I am 
currently working on such a service.

> 
>     If you really need the KML of the cells, then we can see how to provide
>     this.
> 
>  
> I just saw that there were already KML files referenced in the map, so 
> if that was the easiest way to share the data for now, so be it. But a 
> local sqlite database or dbus service will be even better when it's ready.
> 

sqlite database is available.
And for the D-Bus service, please see my comments above.

Onen