Re: What about Reverse Geocoding?

I wouldn't argue that machines are the only "people" who think lat/lon 
coordinates are useful in their raw form.

On the other hand we (Flickr) have also spent the last two years working 
out what to actually show users in their place without also poring fuel 
on the fire(s) of interpretation.

There's lot of interesting work left to be done here but I also think 
that it's sufficiently complex that it is really an entirely other 
problem than just defining an API that allows machine a (browser) to 
talk to machine b (location/input device) and figure out who's on first, 
in machine-speak.

Meanwhile, in the FYI department:

http://www.flickr.com/services/api/flickr.places.findByLatLon.htm

Cheers,

Greg Bolsinga wrote:
> On Nov 9, 2008, at 10:16 PM, Thomson, Martin wrote:
> 
>> That's an larger and more interesting question.  Standardization is 
>> the only hope here.  I think that they have Austria sorted out:
>>
>>  <http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations> 
>>
>>
>> (aside: The word "locality" seems to be an convenience label used here 
>> to refer to different things.  The IETF decided to avoid any 
>> preconceptions with names and go with numbers: A1, A2, ...A6.  For 
>> places like the US, Canada and Australia: A1 == state, A2 == county, 
>> A3 == city, A4 == suburb, A5 == neighbourhood, and A6 is rarely used.  
>> However, in Japan, this might be entirely different, although largely 
>> parallel.)
> 
> I've seen another discussion about this issue (what to name the address 
> parts). My feeling (and it is subjective) is that whatever we name them, 
> there's going to need to be documentation as to what is what. As the 
> names picked for each will be generic enough that no one really knows 
> what they mean (and the example of A1 ... A6 guarantees that! ;) Since 
> the developer is already going to have to look these things up, we might 
> as well go with something common and something already out there. This 
> is why I personally like the Google Gears implementation.
> 
> Sorry I misunderstood w/r/t the blob issue. I saw some tag soup, and 
> assumed the worst.
> 
> I think that lat/long, while eminently precise and meaningful, means 
> very little to the large majority of people. Since this is in the UA, 
> the location result will be displayed to a person. I'm thinking of small 
> low CPU power devices that also want to transmit and receive as little 
> information as possible. Having the address in the API will help these 
> types of devices. It's too bad it didn't make the first draft.
> 
> Thanks,
> -- Greg
> 
>

Received on Monday, 10 November 2008 17:31:10 UTC