Wifi positioning backends

[Stephen Wing]

Jussi Kukkonen wrote:
 > Unfortunately they offer no information on the database size or
 > coverage, so comparisons are not going to be meaningful (except very
 > locally).
Agreed - although looking at, say GSMLoc - they only had a couple of 
routes in the UK, and Manhattan looked like it had had 1 person travel 
in on one route only - a lack of info in London and New York make me 
nervous.

Having said that, and based on some testing of the Navizon client last 
night, I think an open, free solution is better - if we choose the right 
one, we can help them build a decent database even if it's not there now.

The worst thing about Navizon, is that they limit the area they will 
report on - I work further away from home than I can select as "my 
area", which means I can't even see where to concentrate any effort for 
them... :(

 >> I especially see integrating Geoclue (Maemo version) with Maemo 
Mapper would be useful for those without GPS units, especially with 
Mobile Phone support to provide more functionality than currently 
available within Maemo Mapper.  Without mobile phone support, the end 
user might as well use the functions with Maemo Mapper already.
 >
 > cell tower positioning would be nice, but if I had to prioritize I'd say
 > Access Point positioning is more important:
 >  * it will be easier to implement (except maybe on OpenMoko :)
 >  * it will be useful to more people
 >  * it has potential to be (a lot) more accurate
 >  Of course, I'm assuming the databases are available...

I guess I'm coming from a mindset of what applications are going to 
benefit the most with this form of data...

In terms of web 2.0 things - eg blogging, I can see the usefulness of AP 
positioning, but equally, without it, the users can still use the manual 
(civic) option.  Plus, does having an exact precise position for a blog 
entry really benefit the user / reader...?

In terms of other apps - eg Maemo Mapper - if it's being used in the 
street or in the car, then it's unlikely to be being accessed via an AP 
- it's more likely to be either offline or using the phone for it's 
internet connection.  To save these users needing a GPS working as well 
as the phone, the phone support would seem to offer a rough position. 
But then, if using it for navigation, will it be accurate enough, or 
will they still need a GPS anyway....

For location search info, either are equally valid, and it will depend 
on which is in use as to which would be more useful, so for this case, 
supporting both might be ideal.

What other apps / application types are being considered for wanting / 
needing Geoclue support, and which options would best suit each...?

Having said all that, I think AP positioning will be easier to 
implement, and should come before mobile phone positioning - maybe 
mobile phone positioning (along the lines of Navizon) should be added to 
the roadmap, whilst more thought goes into how to actually achieve it, 
and which database to use / support / concentrate on...

Either way, the key point is that a Geoclue backend makes the most sense 
for implementing mobile phone based positioning - it fits into the model 
(somehow - maybe better than AP positioning for the OpenMoko) and would 
offer a variety of solutions.  Does the current design of Geoclue 
support a hierarchy - ie the ability to put the backend in order of 
accuracy, and then provide the most accurate to each app (allowing for 
the permissions settings, which may limit the level being used)? Ah, 
reading your RFC: How to decide which backend(s) to use - you seem to be 
suggesting there should be an order, and I think I agree, eg something like:

GPS -> AP -> Mobile Phone -> Plazes -> Hostip -> Civic location

If this is linked with the permissions stuff - ie app 1 can only get 
location info level 3 or below, whereas app 2 can get level 1 or below, 
then I think this can be a great help.

With no direct access to the cell ID function on the phone via 
Bluetooth, it has to rely on something on the phone / web, which has the 
potential to really limit who can use it.  Having said that, the Java 
Navizon / MGMaps clients worked fine on my phone last night (no native 
client available), which is partly why I keep coming back to Navizon - 
they seem to have the largest device support pool right now.

I hope this all helps, and I look forward to more Geoclue work coming 
out in the near future!  As with all things, getting the basics working 
and released, and some apps integrating into it (eg Maemo Mapper) will 
encourage end users to submit their requests for backends...

Steve