Awesome. We need bulk requests (one or more lat/lng), and reverse geocoding with locale components (state, county, city, neighborhood) Extending tzaman's localization request, a globally unique identifier, e.g. ISO code, for every piece of locale when reverse geocoding is critical for us. When storing reverse geocoded points in our own database I want to key off the unique values but lookup the locale specific versions later on client devices (ideally via REST or an offline API if possible).
Can I dig a little deeper into this as your example has me indulging in some furious head scratching.
Providing language synonyms makes perfect sense where these exist (cf: London in English, Londra in Italian, Londres in French).
But your example implies translation of place names into their language specific equivalent. Kings County in Washington state is, unless I'm mistaken, Kings County in all other languages. Although the local residents may disagree, this county isn't blessed with a language synonym as it doesn't fall into the (ill defined) category of "well known place with a language variant".
Unless you're suggesting that if, say, French is requested as a language, a geocoder should translate place names so "Kings County" would (maybe) be "Comté Roi" in French. Although this approach sounds odd to me as (AFAIK) no one else refers to this place in this way?
Sorry for the confusion, let's see if I can clear this up. We'd like to see these locales translated to the same names that the native map program on a device would show (which is what I rely on now). For example, on my iPhone, when I switch to French and I'm in the Mission District of SF it says "Etats-Unis" / "Quartier de la Mission". Actually, that's a bad/rare example, a better one is a multi-lingual country like Switzerland where you can have 3 languages at once for some cities/neighborhoods. I want to pass the locale of the speaker to the API and get back what they'd expect in their local dialect.
I do have to ask how realistic this is. It makes sense for places that do have multi language versions. So "Etats-Unis" for the US, when in French, makes total sense.
But does translating the Mission to "Quartier de la Mission" make sense? It makes me go "errrr?".
To put it another way, taking the ever present UK "High Street" as an example. I'd expect to see this as "High Street" regardess of language and not as "Grande Rue" because no one ever says this of uses it.
So yes, I think passing the locale to the service makes a lot of sense. Supporting those places which have multi language versions makes a lot of sense too. Translating all place names to a specific language makes less sense.
/geocode?latlng=47.639548,-122.356957&language=en,fr
{ "ISO":{ Country:"US", Administrative:"WA", SubAdministrative:"King", Locality:"Seattle", SubLocality:"Queen Anne" }, "fr":{ Country:"Etas-Unis", Administrative:"Washington", SubAdministrative:"Roi County", Locality:"Seattle", SubLocality:"Renne Anne" } "en":{ Country:"US", Administrative:"Washington", SubAdministrative:"King County", Locality:"Seattle", SubLocality:"Queen Anne" } }