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

• From: Shyam Habarakada <shyamh@microsoft.com>
• Date: Mon, 23 Jun 2008 20:21:28 -0700
• To: "public-geolocation@w3.org" <public-geolocation@w3.org>
• CC: Alec Berntson <alecb@windows.microsoft.com>
• Message-ID: <F2726D43C21D084F81F9C887BE881BD15513A2F942@NA-EXMSG-C105.redmond.corp.microsoft>

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.

Received on Tuesday, 24 June 2008 03:22:10 UTC