Re: Position.address property vs. a ReverseGeoCode( .. ) method?

Hi Shyam,

On Tue, Jun 24, 2008 at 4:21 AM, Shyam Habarakada <shyamh@microsoft.com> wrote:
>
> Re: http://dev.w3.org/geo/api/spec-source.html
>
> The draft presently defines Position as,
>
>  interface Position {
>    readonly attribute double latitude;
>    readonly attribute double longitude;
>    readonly attribute double altitude;
>    readonly attribute double accuracy;
>    readonly attribute double altitudeAccuracy;
>    readonly attribute unsigned long long timestamp;
>    readonly attribute Address address;                         /* REPLACE WITH A METHOD */
>  };
>
> Looking more into this design, it looks like there is an assumption that reverse geocoding data is always easily available when ever position information is available. I assume this is because we started with triangulation as a popular method of obtaining lat/long and in this approach, it was cheap to get reverse geocoding information at the same time (i.e. in a single call to the cloud).
>
> However, many devices will soon have built in GPS and obtaining reverse geocoding data would incur a call to the cloud. To better reflect this, we should consider replacing the address property a method call like ReverseGeoCode( .. ).
>

You are right: when the position fix is obtained from the GPS device,
a network request would be required to reverse geocode that data.
However, this is an implementation detail and I am not sure it needs
to be reflected in the API. Currently,
PositionOptions interface has the "requestAddress" attribute which,
when set to true, causes the UA to try to do reverse geocoding. If the
UA is using a network provider that can also do geocoding, it can
request the provider to return the (lat, long) and the address
information in the same response. If we were to replace this property
with a separate ReverseGeoCode method, then we would lose this
optimization.

Anyway, I think we all agree that reverse geocoding should not be part
of the v1 version of this spec so you are right again in saying that
we should postpone this discussion for later.

Many thanks,
Andrei

Received on Wednesday, 25 June 2008 16:21:33 UTC