Re: What about Reverse Geocoding?

On Mon, Nov 10, 2008 at 5:11 PM, Greg Bolsinga <bolsinga@apple.com> 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.
>

Yep, I think we need to keep in mind the audience of this API. I am
very well aware of the problems involved in designing an address
format that is suitable for every country, but I also think we need to
be realistic and keep this API simple and clear. Asking developers to
read and understand standards like those proposed earlier in this
thread (e.g. rfc5139) probably won't be a very popular decision.

Andrei

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