Re: Address object on the Position object

Hi Doug,

Thanks for the email!

On Mon, Jun 27, 2011 at 8:33 PM, Doug Turner <doug.turner@gmail.com> wrote:
> Firefox has basically implemented the Address attribute on the
> Position object.  This was done for a few reasons.
>
> What we have learned is that accurate geocoding is much more expensive
> than just geolocation.  Many system APIs (like Android), have separate
> APIs for discovering where you are, and converting that to something
> that looks like a mailing address.  I think we want to reflect this
> and have a new API that allows for geocoding - and leave the Address
> attribute on the position object not formally defined.
>
> Something like:
>
> interface GeoCoder {
>    void getAddress(in Position position, in AddressCallback
> successCallback, [Optional] in AddressErrorCallback errorCallback,
> [Optional] in AddressOptions options);
>  };
>
>  [Callback=FunctionOnly, NoInterfaceObject]
>  interface AddressCallback {
>    void handleEvent(in Address address);
>  };
>
> Where Address is what we currently have defined, but includes a timestamp.
>
> I am not sure if we need AddressOptions -- it might be interesting if
> one could specify accuracy desired, but I am tempted to just assert
> that the implementation should give the best available result.
>

This came up today in the Geolocation face-to-face meeting and we
filed Issue-96.

We completely agreed that the API should be designed so that an
implementation would avoid doing reverse-geocoding unless a Web
application explicitly requested it. However, I think there are a few
issues with the solution you propose:

1. The new method requires an extra-round trip to the
reverse-geocoding server, which adds latency and may therefore be
problematic for a class of use-cases where speed is essential. For the
rest of the use-cases that don't have a problem with the extra
latency, there are already a number of reverse-geocoding services
available on the Web today. So it's not entirely clear what advantages
your proposal has over using such an existing Web service.

2. Following from 1 above, this approach leaves it to the Web
application to decide how often to call the reverse-geocoding method.
We think it's safer to let the UA handle this as the UA is probably in
a better position to make sure it does not accidentally overwhelm the
reverse-geocoding backend with requests for Address objects. For
instance, a UA could implement a throttling mechanism such as
exponential backoff in order to protect the backend in critical cases.

3. The approach is prone to scraping: a rogue Web application can
crawl the lat/long space to scrape all the data in the
reverse-geocoding server. With your proposal, it would be hard to
defend against this.

Instead of this, we think the problem you described can be better
solved with the use of a new PositionOptions attribute:
"requestAddress". This would be a smaller API change while also not
suffering from the caveats explained above. Steve will follow-up with
an email about this.

Thanks,
Andrei

Received on Tuesday, 28 June 2011 13:22:57 UTC