- From: Greg Bolsinga <bolsinga@apple.com>
- Date: Thu, 6 Nov 2008 11:20:34 -0800
- To: Andrei Popescu <andreip@google.com>
- Cc: public-geolocation <public-geolocation@w3.org>
Hi Andrei, On Nov 6, 2008, at 11:03 AM, Andrei Popescu wrote: > FYI, here's the story so far: > > http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0057.html > http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0079.html > http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0094.html Aha! Thanks. Why I didn't think to search the archives, I don't know. My take is that once the page has a lat/long, it needs to 'do something' with this raw data. Logic leads to wanting the address. But perhaps in the vein of keeping the API simple, I may be convinced it is best to not require the reverse lookup. But I can see that many web developers using Geolocation would want to display something to the user, and lat/long, while perfectly accurate, isn't what a typical user would care to see. So then the developer would need to send the lat/long to a server, and then do the address lookup there. Currently, without any reverse lookup, all that I can see the Geolocation API being useful for is tracking someone's movements (via watchPosition) while they have a Geolocation using page open. > Gears' implementation of Geolocation API has an extension that > provides reverse-geocoding: > > http://code.google.com/apis/gears/api_geolocation.html#positionoptions > http://code.google.com/apis/gears/api_geolocation.html#address This looks interesting. Those seem to map the to keys in the Google Maps JSON quite nicely! ;) If a UA should decide to 'extend' the API as Google Gears does above, does it still adhere to the specification? Thanks, -- Greg
Received on Thursday, 6 November 2008 19:21:47 UTC