Future of location services on OM

[Nick]

Hello,

Joel,  I think Onen and I agree with you !

My view is the following:
*** on server side (database generation), I plan to provide GPS 
coordinates of cells. (in fact that's what openbmap.org do now;)

Today, the GPS coordinates comes from GPS/GSM loggers that can log only 
GSM cells the user are connected to.

In the future, we plan that GPS/GSM loggers will be able to log not only 
the GSM cells we are connected to but also neighbour
GSM cells seen by the mobile.

The openbmap mapping manager could use these extra information to 
calculate the GPS coordinates of cells.

The point previously mentioned by Onen was that we do not plan (at this 
time!..) to include the neighbor cells to calculate
the GPS coordinates of cells because it "brings a risk of enlarging ... 
a lot the cells diameter"

Nevertheless
*** on client side (about using openbmap database to get user location), 
we think that your
proposals are good. Using neighbor cells or previously seen cells 
(connected cell or neighbor cells) will help us define the current
user location with a better accuracy.
Please also note that if a mcc/mnc/lac/cell is not in database, we can 
use the mcc/mnc/lac coordinates also provided by  the openbmap API.


On my side, now I think I will wait for a logger first version to come out.
It will be probably possible to enhance it in later versions...
After that (or in parallel ) I think it will be necessary to design and 
make available "the geoclue api" (or equivalent...)
mentioned by Sascha. (I like your proposal !)

Another point is about the temporary import of opencellid database I made.

It made me realize that I must change the current database design and 
have a schema for each operator (or at least for each country...)
I will also provide a 'density' information about the surrounding of a 
cell. (number of near cells for each cell, cells contained in the 1 km2 
area around each cell..) I plan to do this during the next 4 weeks

If new APIs are needed at openbmap side, please let me know !

best regards,
Nick


Joel Newkirk a écrit :
> On Thu, 15 Jan 2009 22:36:39 +0100, Onen <onen.om at free.fr> wrote:
>   
>> Hi,
>>
>> these are interesting ideas. At the moment I imagine building something
>> really simple. Give cell id to location system, gets position.
>>
>> I then would like to test the use of neighbour cells to increase
>> accuracy, by identifying the smallest common area. Give cell idS to
>> location system, gets position.
>>
>> As Nick pointed to me, use neighbour cells to build the database brings
>> a risk of enlarging quite a lot the cells diameter, thus nullifying the
>> benefit from using more cells at a time.
>>
>> Onen
>>     
>
> I don't see that.  If we look at the current and neighboring cells and the
> current cell is NOT in the DB with coords, but two neighboring cells ARE,
> then we can feed the APGS with the midpoint between those two known
> neighbor cells, and an accuracy radius of perhaps 30km*.  This has quite
> limited usefulness for informing the user of location, but is sufficient
> for a significant improvement in GPS time-to-first-fix.  (of course that
> presumes ability to retrieve AGPS assistance data via GPRS or some other
> on-demand connection)
>
> Lots of processing /could/ be performed to narrow it down, IE if we see two
> known (in-DB) neighbor cells and already have known data stored on cells
> surrounding those two on two or three sides, but I don't know if the extra
> processing (and coding) required would be worth it.  
>
> But simply saying "OK, I don't know /THIS/ cell, but two neighbors are each
> within 10km* of xx yy so I'm sure to be within 30km* of that point too"
> seems useful to me.  Take it a small step further and say "OK, I know
> neighbor X and it's strong enough that I could be using it even though Y is
> what I'm using since it's stronger, so I must be close to X".
>
> j
>
> * I'm making these numbers up.  In actual practice the range is dependant
> on terrain, power capability of the cell site, frequency involved, etc. 
> IE, 850mhz is much better at penetrating obstructions like trees and walls
> than 1900Mhz, so as a result higher-frequency cells tend to be located more
> closely together - particularly where terrain or development present
> obstructions.  A reasonable model of what tower density and ranges are
> actually utilized on various freqs would be critical to properly massage
> this data and get useful results.
>
>  
>   
>> Joel Newkirk wrote:
>>     
>>> I was contenplating (and proposed via ML, IIRC) some time ago utilizing
>>>       
>> a
>>     
>>> local DB to store correlations between GSM towers, visible wifi APs and
>>>       
>> GPS
>>     
>>> coords when GPS /was/ on, and later retrieving those coordinates
>>>       
>> (rounded
>>     
>>> and noting error) on demand by simply requesting 'current location'.  If
>>> GPS is on that can of course supply precise data from the GPS, but if
>>>       
>> it's
>>     
>>> off and the DB includes reference to a visible GSM tower or wifi AP it
>>>       
>> can
>>     
>>> return the stored coords with accuracy represented as a separate value.
>>> (eg '5' indicating +-5km)
>>>
>>> So this would entail the DB itself, a daemon stuffing newly-discovered
>>> correlations into it, and a dbus interface that both provides current
>>>       
>> GPS
>>     
>>> coords if available (with error noted as '0' meaning "presumed
>>>       
>> accurate"),
>>     
>>> and provides DB-retrieved approximations when necessary and available.
>>> Presuming a daemon in use, it could also calculate rougher
>>>       
>> approximations
>>     
>>> based on understanding that even though it has no GPS data stored for
>>>       
>> the
>>     
>>> current GSM towers visible, that 10 minutes ago it saw a GSM tower it
>>>       
>> DID
>>     
>>> have in the DB, and return coords with a larger error factor noted.
>>>
>>> j
>>>
>>>
>>>
>>>       
>> _______________________________________________
>> devel mailing list
>> devel at lists.openmoko.org
>> https://lists.openmoko.org/mailman/listinfo/devel
>>