RE: What about Reverse Geocoding?

Hi Andrei,

I think that you've got it, but rather than could, I'm saying "should".  The API shouldn't assume that the two have the same source, but it doesn't need to be.  

Rather than saying that we should revisit reverse geocoding in version 2, you should be saying that we should revisit _civic addresses_ in version 2.  Reverse geocoding is just one way of acquiring civic address information.  My concern is that there is an undue emphasis on mobile devices, where the acquisition of accurate geodetic information is easier than acquiring civic addresses.  Naturally, in this environment, reverse geocoding makes the most sense.

Your interpretation of the example only shows one potential outcome (i.e. 'tis a strawman).  The civic address could be reverse-geocoded if that is how the "location provider" on the browser is set; it could come from a network-based location server (and I've already suggested that for wireline devices, civic addresses are quite likely as the product of such a service).  User input is only one possibility.

As for current location vs the intended delivery destination, that same argument applies for geodetic location information.  A pizza delivery site might attempt to acquire location information through the API as an assist to users (on the assumption that this is most likely correct), but still offer a user the opportunity to pick an alternative destination.  That's a decision for the particular service.  They will have to make this decision in light of the particular interfaces that browsers present users to avoid any such confusing doubling up.

Cheers,
Martin

> -----Original Message-----
> From: Andrei Popescu [mailto:andreip@google.com]
> Sent: Tuesday, 11 November 2008 4:22 AM
> To: Thomson, Martin
> Cc: Doug Turner; Greg Bolsinga; public-geolocation; Richard Barnes
> Subject: Re: What about Reverse Geocoding?
> 
> Hi,
> 
> On Mon, Nov 10, 2008 at 4:20 AM, Thomson, Martin
> <Martin.Thomson@andrew.com> wrote:
> > Hi Doug,
> >
> > Sure, you don't need anything in the DOM, and indeed, our original
> prototype didn't use the "DOM" when filling forms [1].  Of course, that
> relies on standardization from the sites, not the browser - you need to
> be able to rely on the form field named 'country' being a country
> field.  Going the other way around - standardization of the object
> exposed to the site through the scripting language - is a much easier
> prospect because that means standardizing fewer piece of code.
> >
> 
> If I understand you right, you suggest that in the Geolocation API we
> could decouple the handling of 'civic' addresses from a (potential)
> reverse geocoding functionality by providing a separate
> 'getCivicAddress()' function. So if a pizza site needs a civic address
> for delivery, it can ask the Geo API to provide an address object with
> standard fields. It would then be up to the implementation (UA) to
> figure out a way to provide this address object, manual entry being
> one such way. So instead of the pizza Web site presenting the user
> with a form, it's now the UA that shows the user a form that allows
> manual entry of the address details.
> 
> To me, this functionality doesn't seem very well suited to the
> Geolocation API. Our API aims to provide the current position of the
> user, whereas 'getCivicAddress()' seems to be different: it provides
> some address, not necessarily the current one (e.g. the user could
> still be at work when he orders the pizza to be delivered at his home
> address in x hours time). I understand the reasoning (providing web
> sites with a standard address object, instead of having each of them
> write an HTML form) but it seems to me that it's out of the scope of
> this API.
> 
> However, I do think that reverse geocoding is a relevant topic for our
> API and we should revisit it for version 2.
> 
> Andrei

------------------------------------------------------------------------------------------------
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 Monday, 10 November 2008 21:51:49 UTC