On Dec 28, 11:48 pm, argv01 <[email protected]> wrote: > 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().
http://www.geocodezip.com/example_geo2.asp?addr1=London,%20England&geocode=1 That query only returns one result for me. You must be doing something different. If I put the "addresses" in your sample page into an xml file and run it through a tight loop geocoding the addresses (which is effectively what you are doing on your page), I get lots of "querying too fast" errors: http://www.geocodezip.com/example_geomulti_bad3_xml.asp?filename=danheller.xml recommended reading (from Mike Williams' tutorial): Part 17 Geocoding multiple addresses http://econym.org.uk/gmap/geomulti.htm -- Larry > > (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.
