Re: What about Reverse Geocoding?

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:13:12 UTC