Wifi positioning backends
stephen at wintoncourt.co.uk
Wed Jul 25 09:34:50 PDT 2007
Jussi Kukkonen wrote:
> Unfortunately they offer no information on the database size or
> coverage, so comparisons are not going to be meaningful (except very
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
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
>> 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...
More information about the GeoClue