Wasn't it argv01 who 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?
That's what the source code does. >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(). But the getLatLng() location is always the location if the first Placemark. >(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' ?) No. Some non-Google geocoding services work like that, but then you *always* have to provide all the fields separately, which is a pain if you happen to be working from a datastream where the address is not held as separate fields. > >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. No, it's just you. Nobody else has a problem with using function closure. If you don't like the way .getLocations works, write your own .getLocationsWithName that uses Function Closure to hold the name and passes whatever values you like to it callback function. > >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". No it doesn't. GClientGeocoder treats "Scotland" as "Scotland, UK" unless you choose to bias the country to USA. > 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. Absolutely not. The geocode server totally ignores punctuation. >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. Not the daily geocoding quota. The requests-per-second speed limit. > >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. maps.google.com uses a completely different geocoding database, uses extra data that Google don't have a redistribution licence for, and can also switch from geocoding to business search or web search or search user created content whenever it feels that it is appropriate. -- Mike Williams http://econym.org.uk/gmap -- 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.
