On Dec 30, 1:58 am, argv01 <[email protected]> wrote:
>
> I know it may strike people as odd to hear this, but nowhere does it
> say that the geocoder is specifically for *postal addresses*.

We do not wish to imply that postal addresses are absolitely the only
thing the geocoder supports. We make a best effort attempt to handle
other queries. However dealing with postal addresses is the highest
priority, because it is both the largest use case, and the most
'exact'. ie. the one in which there is the closest thing to an
unambiguious right and wrong answer (as defined by the postal service
in the country concerned). Given that geocoding is something of a
black art anyway, and guidelines we can apply that lend some degree of
consistency are valuable.

This prioritisation of postal address handling is reflected in the
following FAQ:

http://code.google.com/apis/maps/faq.html#geocoder_queryformat

> True,
> support for postal addresses is probably the main, key selling point
> for people, but I also figured that the mapping engine (and subsequent
> parser) was far more generalized and multi-purpose than that. that it
> would at least "intelligent" in that it would realize when it isn't
> getting a specific street address if all it gets is "london, england".

Note that in the v3 geocoder we introduce the concept of a 'partial
match' which is a result in which an exact address could not be found,
so we backed off until some subset of the address matched something.
eg. if you do a query for an non existed street number on a street in
london, we may return the centroid of the street itself if that does
exist, or even just london. In each case we include a type
specification for the result so yoiu know what you have got.

In many ways you can look at the v3 geocoder as an attempt to address
many of the issues in the v2 geocoder that have been recognised over
it's lifetime, some of which you have raised. For example we no longer
have both getLatLng() and getLocations(), but instead consolidate on a
single method that returns a status coe and an array of results only.

> the gmap2 api is a bit too narrowly focused in its purpose: 1) postal
> addresses 2) in the browser's locale.

It's also not true that you are restricted to the browsers locale. You
can change the country code biasing programmatically. In v3 we
explicitly break out the region and language as separate parameters.

> If I don't want an actual street address, but merely the location of
> generalized places, like cities and countries and oceans and lakes,
> that would reduce their resource utilization considerably.  And again,
> one only needs to look at the query string to assess that.

If you give is a query for just a city name, we should give you back
just a city. However even that is not necessarily simple because there
are many city names shared by multiple cities, and some of those
cities, such as Paris and London, are so well recognised worldwide
that a majority of users would expect the highest profile example to
always be the one returned regardless of their locale.

> This then leads to the issue of allowing for a more structured input
> mechanism. Either by using syntax (such as "City:London
> Country:England", or by just providing a structured object as an input
> parameter. Say, the same JSON object that we're passed back in the
> callback for getLocations().

This is a common request, and I suggest you indicate your interest in
it by staring this feature on the Maps API Issue Tracker:

http://code.google.com/p/gmaps-api-issues/issues/detail?id=838

> Do we really need to have that level of
> unhappiness just so getLocations()'s callback function passes back the
> address that was used to invoke it? (Especially since at least "one"
> portion of the doc seems to suggest it'd be there?)

If the 'name' property of the callback response does not contain the
original query then this is a bug that you should log on the Issue
Tracker with a supporting code sample and we will fix it. However I've
just tried to reproduce it and it works for me.

Thor.

--

You received this message because you are subscribed to the Google Groups 
"Google Maps API" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-maps-api?hl=en.


Reply via email to