On Dec 29, 1:18 am, Mike Williams <[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? > > That's what the source code does.
Is the source available? I don't see any references to it. Do you have access to info that we mere mortals don't? Either way, I still think it's a failure of the doc to not say this. anyway, the entire confusion has been cleared up with this statement from Andrew: > The geocoder > geocodes postal addresses -- it makes a guess if it can't recognise a > postal address -- and "London, England, Europe" isn't a postal > address. I know it may strike people as odd to hear this, but nowhere does it say that the geocoder is specifically for *postal addresses*. 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". Such heuristics isn't hard, and it could serve itself and end-users mutually to do so. It's like having a calculator that can do square root calculations, but refuses to do simple addition. the gmap2 api is a bit too narrowly focused in its purpose: 1) postal addresses 2) in the browser's locale. Full stop. And while it can do that function very, very well, it needs to realize that such a narrow view of the application of this api is causing problems for those looking to use it for broader purposes. This engine has the potential to provide maps for all sorts of world-wide uses, where the "context" is based on the data, not the end-user. And when data gets robust, the api should reflect that by providing more robust access methods. 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. 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(). To that, you say: > 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. Right -- so now there's mutual exclusion: you can use one service if you have structured fields, or the google service if you don't, but neither service is flexible enough to support both. While I do understand that when all you have is a single text stream, getLocations() is great. but there are plenty of <form>'s on the web (not to mention internal data structures that web apps use), that happen to have fields all ready and filled out. Re: Function Closure > >... while function closure *can* work > >around this problem, there are plenty of contexts in which that one > >method is undesirable > Nobody else has a problem with using function closure. My reading of the discussion forum seems to yield a lot of questions (and frustrations) from people on this point. We may disagree on the degree in which people have a problem with it, but I don't think this is the main point anyway. People didn't have a problem with all sorts of things till new innovations came along and produce newer and more useful ways to do tasks. I can list things from smart phones to medical treatment to instruction sets on microchips as examples: people use what they're given, and only the most egregious mis-designs stir considerable discontent. 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?) Function closure is an interesting artifact from a time when development tools made it possible for programmers of languages like perl to come up with clever code parsing and nesting, but don't let the tail wag the dog. It's a shortcut that should be used for conveniences sake when brevity is critical. It should not be used to drive what the parameters for a callback function should be. (Yes, there are always workarounds, but things would be far easier for everyone if the param simply existed.) 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.
