RE: Location providers and competition

Hi Eric,

I have been intending to post on civic addresses, and what you are describing below is a specific use for civic addresses.  For the case where you just want to say "work" or "home" (and have people interpret this based on their understanding of the meaning of those words) the civic address formats in RFC 5139 and RFC 4776 define the "LOC" element.

To be fair, this isn't addition to the list of location providers, I'd imagine that you'd use manual entry to do this.  Unless of course you managed to teach a location provider to produce this level of information based on more precise information.

Ta,
Martin

> -----Original Message-----
> From: Erik Wilde [mailto:dret@berkeley.edu]
> Sent: Tuesday, 21 October 2008 5:37 PM
> To: public-geolocation@w3.org
> Cc: Thomson, Martin
> Subject: Re: Location providers and competition
> 
> 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)

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

Received on Friday, 24 October 2008 05:28:43 UTC