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

Hi Shyam,

I think this is a great suggestion. As you point out not all location  
providers can easily provide reverse geocoding.

Nick.

On Jun 23, 2008, at 11:21 PM, Shyam Habarakada 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( .. ).
>
> We can discuss details of this method* later, but how does the WG  
> feel about the general idea?
>
>
> shyam habarakada
> Microsoft Corporation
>
>
> *  Should it be async? would we specify a reverse geo-coding URL in  
> the method call? what if the reverse geo-coding is not a free  
> service? etc.
>
>
>
>

Nick Brachet (nick@skyhookwireless.com)

Received on Wednesday, 25 June 2008 02:54:03 UTC