Thor -- Thanks greatly for your responses. You've addressed each of the points I raised, and I will pursue the two specific items you mentioned without mention here.
The last one being important, but currently out of scope of my work at this point. For context: > On Dec 30, 1:58 am, argv01 <[email protected]> wrote: > > 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?) First, I should note that the doc is inconsistent on this--the specs on the callback function say: "This response will contain a Status code, and if successful, one or more Placemark objects. " It should also include the fact that the originally-passed text string will be passed back as well. For even better clarity, I think the doc should say that "the callback will receive one parameter, consisting of a JSON object that contains three fields: name, Status and Placemark objects." (Have the latter two link to their corresponding pages and locations where those objects are defined. When I was a newcomer to the API, it took forever to discover these.) Now to the bug: On Dec 30 2009, 4:31 pm, "Thor (Google Employee)" <[email protected]> wrote: > 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. For better or worse, I've spent the past 5 days (since my last post) reworking my entire website to use an entirely different architecture to deal with geotagging. Therefore, none of my original code is around that demonstrated this "bug." Suffice to say it isn't worth my time to go back and figure out what might have happened, especially if you can confirm yourself that "it works." But I can confirm that what I got definitely "didn't work," and I can give you context for how it came about: I was also having major problems with 620 errors that I wasn't checking for at the time. It might be that the name field wasn't being properly filled when 620 was happening. Even though I wasn't checking the error status, I was checking "name" and found it to be empty. And I didn't notice this right away either. It wasn't until I made the feature live on my site that I noticed it. and given that I get about 15,000 visitors a day, that's a lot of instant geo requests that thrashed your server. (Sorry.) I've since changed everything from the inside out, as per Mike's recommendation (and which I later found to be duly recommended): I've written a pretty cool perl wrapper that gets coordinates for all the locations embedded in my photos and places them in an internal DB, which my web pages now query directly, rather than doing live via the geotagging methods that started this thread. but, even this process was excruciatingly complex because of the ambiguous nature of a single query string that prunes punctuation. When markers can be placed *anywhere* on a world map, there is no "locale" to use for look-ups--they're all interspersed. And it was already difficult enough to require modifying country names like "scotland" to have "UK" after it, so it wouldn't be confused with 'Scotland, Ohio" (to cite my prior example). And this took quite a long time to construct rules for look-up strings that seemed to work well. Sadly, this required brute-force trial-and-error. And yet, there are still many other very difficult ambiguities that I can't get around: cases where city and province names are identical, for example. Or, where the province name is somehow "unknown" to google maps (such as "hakone, kanto, japan"). All of this could have been alleviated if I were able to just fill in fields of a data structure, copied directly from my EXIF/IPTC data structures. No funky parsing would have been necessary, and your internals can make better guesses about the intentions. E.g., it would know that "hakone" is a city, and "japan" is the country--that it doesn't know "kanto" would be easier to resolve. Otherwise, in the current single-query-string model, that same string just plain "isn't found." I've got a ton of these. So, I will file the feature request for that, as you suggested. The next question is whether life would be easier for me going to v3? -- 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.
