Civic addresses: (was RE: What about Reverse Geocoding?)

I didn't get much from the referenced discussion.

There's still the open item on civic addresses.  There seems to be an implicit assumption that the location information that is available is geodetic.  Sourced from GPS or some type of radio-based determination technology.  Given the current proportion of wired devices for internet access and the nature of the arrangements with ISPs, this might limit the potential applicability of the API.  

My home machine has no knowledge of its own location, no GPS and no radio interfaces.  Based on my current experience, the likely method that my machine gets its location is my retrieving this from my ISP.  And all that they have is my billing address - a civic address.  Given this, where does the API stand?

Geocoding is still an option, but with the current API, this would have to be done on the client.  This is pretty good where I am, but it's not universally consistent.

I'd like to encourage the group to consider civic addresses and how they fit the geolocation API.

Civic addresses are pretty damned awkward for a computer system, but they are still useful to people.  For manual entry, a civic address is far more reliable than lat/long.  Based on the current rate of progress of technology, manual entry is still going to be a significant proportion of users.  Civic addresses include information that simply cannot be encoded in a geodetic position, such as data relating to the human environment: buildings, roads, signs, and landmarks.

So here's a possibility:

  navigator.geolocation.getCivicAddress(function(address) { alert(address.country);});

Selection of fields for civic addresses is a complex challenge.  A free-form line based format is possible, but it doesn't offer much to the recipient.  Free-form data is inconsistent.  The alternative is to try to structure the data.  Even the most carefully constructed format has its drawbacks and compromises need to be made.  The format in RFC 4776/5139 (yes, I have a horse in this race) takes the structured approach and has been widely adopted already.  This is the format that is most likely to be available in standard form from an ISP.

Cheers,
Martin

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Greg Bolsinga
> Sent: Friday, 7 November 2008 6:21 AM
> To: Andrei Popescu
> Cc: public-geolocation
> Subject: Re: What about Reverse Geocoding?
> 
> 
> Hi Andrei,
> 
> On Nov 6, 2008, at 11:03 AM, Andrei Popescu wrote:
> 
> > FYI, here's the story so far:
> >
> > http://lists.w3.org/Archives/Public/public-

> geolocation/2008Jun/0057.html
> > http://lists.w3.org/Archives/Public/public-

> geolocation/2008Jun/0079.html
> > http://lists.w3.org/Archives/Public/public-

> geolocation/2008Jun/0094.html
> 
> Aha! Thanks. Why I didn't think to search the archives, I don't know.
> 
> My take is that once the page has a lat/long, it needs to 'do
> something' with this raw data. Logic leads to wanting the address.
> 
> But perhaps in the vein of keeping the API simple, I may be convinced
> it is best to not require the reverse lookup.
> 
> But I can see that many web developers using Geolocation would want to
> display something to the user, and lat/long, while perfectly accurate,
> isn't what a typical user would care to see. So then the developer
> would need to send the lat/long to a server, and then do the address
> lookup there.
> 
> Currently, without any reverse lookup, all that I can see the
> Geolocation API being useful for is tracking someone's movements (via
> watchPosition) while they have a Geolocation using page open.
> 
> > Gears' implementation of Geolocation API has an extension that
> > provides reverse-geocoding:
> >
> >
> http://code.google.com/apis/gears/api_geolocation.html#positionoptions

> > http://code.google.com/apis/gears/api_geolocation.html#address

> 
> This looks interesting. Those seem to map the to keys in the Google
> Maps JSON quite nicely! ;)
> 
> If a UA should decide to 'extend' the API as Google Gears does above,
> does it still adhere to the specification?
> 
> Thanks,
> -- Greg
> 
> 

------------------------------------------------------------------------------------------------
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 Thursday, 6 November 2008 23:28:23 UTC