W3C home > Mailing lists > Public > public-geolocation@w3.org > October 2008

Re: Location providers and competition

From: Erik Wilde <dret@berkeley.edu>
Date: Mon, 20 Oct 2008 23:37:06 -0700
Message-ID: <48FD7892.2000701@berkeley.edu>
To: public-geolocation@w3.org
CC: "Thomson, Martin" <Martin.Thomson@andrew.com>

thanks, martin.

time to get the geolocation API to the point where it's not just a GPS 
API. if it should just be a GPS API (and right now it is just this), it 
should be called GPS API. if it shall be a geolocation API, it should 
not just focus on GPS.

one thing i'd like to add to martin's very good list:

Thomson, Martin wrote:
>  - manual entry (user types lat/long or picks a point on a map)
>  - SkyHook (as seen in Mozilla Labs Geode)
>  - autonomous GPS on the device (slow, but effective)
>  - SUPL SET-initiated positioning (an open mobile alliance standard)
>  - HELD (network-based location using the model developed by the IETF; disclaimer: I am one of the authors of this document)
>  - DHCP (host configuration with the option from RFC 3825; I'd recommend against this, but it's an option nonetheless)
>  - 3GPP mobile originated location request using control plane positioning (see ETSI TS 123.271)
>  - methods based on public cell-tower location databases (there are plenty of these on the 'net)
>  - QR code or RFID scans (with location by value or reference)

i am still rooting for the fact that location is a much richer concept 
than the current API design reflects. so why would i even have to enter 
lat/long or pick a point on a map? i want to be able to say i am "at 
home" or "in the office" or "on the road" or just "away", and for those 
who i care about that makes sense, for others it doesn't, but i don't 
care. which would be one of the points of the whole exercise: if i can 
use geolocation in a way that matches human categories, i have better 
privacy, but can also much better make sense of location on a social level.

anyway, i am glad to see the discussion being brought back to a level 
beyond attribute naming, i think there are still many questions to be 
discussed for a true geolocation API.

cheers,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret@berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)
Received on Tuesday, 21 October 2008 06:37:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:51 UTC