On Dec 28, 4:56 pm, Mike Williams <[email protected]> wrote:
> getLatLng() doesn't have its own interface to the server. It simply
> makes a .getLocations() call and extracts a GLatLng from the
> Point.coordinates of the first Placemark.

It'd have been nice if the reference doc said that. Is this defined
somewhere else that I'm not aware of? this is important because
nowhere in any of the doc I've been able to dig up says that. Is this
verified?

This is important because I get *different* results from getLatLng()
and getLocations(), and (as I will get into more detail below), the
reason seems to be that my query string has commas: "London, England"
will return the correct location from getLatLng(), but it will return
two distinct locations if I pass that same string to getLocations().

(Is there anywhere that defines the syntax accepted by query strings
provided to these functions to avoid ambiguity in some contexts? For
example, to say 'city:London, country:england' ?)

Much of my confusion stems from problems I'm finding in the
documentation, so I'll get back to this soon. First, the doc:

In the main reference doc page, the description for getLocations()
says:
"you must also pass a callback method to handle the response. This
response will contain a Status code, and if successful, one or more
Placemark objects."

(Google documentation people: I would be so helpful if those
references actually contained links to the pages where they're
defined. Because they weren't, I had to google them separately.) This
brings me to:

http://code.google.com/apis/maps/documentation/services.html

The function and its object params are defined in the section,
"Extracting Structured Addresses" (This is also where the prior
references to these objects could/should have linked to for
convenience.)

Here, getLocations() is used as an example showing that it receives a
*single* callback parameter (not two, as "suggested" by the doc on the
reference.html page), although that single param does contain both the
Status and Placemark objects. Yet, the box directly below is preceded
by the text,

"we show the JSON object returned by the geocoder..."

And the *first* field of the response is "name", which shows the query
string passed to getLocations() in the first place. The second field
is Status, and the third is Placemark.  But in my tests, "name" is
always undefined,. Since it's not used in the examples or mentioned in
the doc, I gather it isn't supported. But then, why is it mentioned
here in the JSON object? This is either confusing or ambiguous to me
(and potentially other readers).

This brings me full circle to getLocations() -- if the geocode lookup
fails, then Placemarks is empty, and without the "name" field, I have
no way to know what query string failed. While "function closure" may
be one way to workaround that, it just seems like a simple oversight
in the API design ... one that appears to generate a lot of questions
from readers as well. And, yes, while function closure *can* work
around this problem, there are plenty of contexts in which that one
method is undesirable--hence, inelegant. I needn't have to list them,
and there are plenty of other precedents used in other APIs for async
communications wherethis isn't a problem. XMLHttpRequest() being one
such example. I don't think it's unreasonable for getLocations() to
either use the "name" field in the JSON object, or allow the caller to
pass client data that would be passed back to his callback.

Now with that background, we get to my concern about lookup syntax as
alluded to earlier.

Your response to my next posting suggests you misead it, so I'll quote
myself again:

> >...when passing information for each image, I have to pass country 
> >information
> >as well as others to reduce ambiguity of the geocoder.  I often have
> >to actually include the continent name as well to keep names like
> >"Scotland" being confused with "Scotland, Ohio", which is what the map
> >will show me because MY browser happens to be in the US.
>
> I don't believe that.

You misunderstood -- I had to ADD "UK" in order for the geocoder to
know that I meant "scotland, england". Otherwise, it returns
"scotland, ohio".  Fair enough--that's reasonable. But the problem is
the comma: it's causing getLocations() to think these are two SEPARATE
lookups, where getLatLng() does NOT have this problem. It's not that
simple to just remove the commas; many places *need* commas to avoid
other kinds of ambiguity. But before we get bogged down in this point,
the underlying question is 'what are the syntax rules?' I see none
documented, and if the comma is an issue, what else is out there that
I could use to my benefit, or that I should know to avoid?

This experiment also verifies that getLatLng() is doing a bit more
than merely calling getLocations(). It must be doing something to the
query string in order to preserve the intended, *singular* location.

Next:

> > ... geocoder fails to parse arbitrary names like "buenos aires, 
> > argentina"...
>
> Using getLocations() will also reveal the fact that many of your
> requests are failing with error 620, because you're exceeding the
> geocoding speed limit. ...Geocode each photo once and store the
> coordinates in your database.

I'm more than happy to eventually add these codes to my database and
move on, but we're not there yet. My reading of the specs are that
it'd be highly unlikely that I've run into the geocoding speed limit.
During my tests, *I* was the only person using these params -- I only
opened it up to the public in order to allow readers of this
discussion group to see and understand the context that I'm talking
about. If I'm personally running into geocoding limits with my own
personal tests, something else is going wrong.

Supporting my suspicions here, I can further verify that the geocoder
is not returning results consistently; in many cases, not the same
results I get if I typed the same string into maps.google.com (e.g.).
getLocations() is returning incorrect Long/Lat settings for towns in
my own neighborhood, whereas the same searches on google maps does not
yield these same (incorrect) coordinates.

Now, this could once again be due to some sort of parsing error due to
the syntax that I'm passing to getLocations(), which once again leads
me to the desire for more detail there.

dan

--

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