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

Received on Monday, 10 November 2008 17:23:03 UTC