First of all thanks for your answer! Let me clarify some points: We are actually planning to use only the client-side geocoding, so we shouldn't have problems with the quotas.
For storing the data it should be OK as far as I understand the TOS and this page confirm my thoughts: http://code.google.com/intl/fr/apis/maps/articles/geocodestrat.html It says under the "When to Use Client-Side Geocoding" part: "Run the geocode in the browser and then send it to the server. For instance, the user enters an address. Your application geocodes it, in the browser. The app then sends the data to your server. The server responds with some data, such as nearby points of interest. This allows you to customize a response based on your own data, and also to cache the geocode if want. This cache allows you to optimize even more. You can even query the server with the address, see if you have a recently cached geocode for it, and if you do, use that. If you don't, then return no result to the browser, and let it geocode the result and send it back to the server to for caching." The point is that we can store the coordinates to cache the results, as the users enter the data, but I don't know about the reverse geocoded addresses. The website you pointed Andrew is more or less what we want to do. Leaving the users only the map for pointing their location is not good enough, we consider offering a field where they can write the address, geocode it and display it on the map. The two ways should be possible and they could use one or the other way the refine the position. But then we want to reverse the geocoding in order to have a readable address formated by Google and store it. This address will be used just as a short version of addresses on a list pointing to a page describing the location and displaying the Google Map. I haven't found anything in the TOS about reverse geocoded data... For my second point, that means that we couldn't use the latitude and longitude to retrieve the user's timezone? Except if Google propose this service which is not the case, right? And what about displaying the distance from the current user with displayed location? That would be calculated from the coordinates and displayed also on those list I was speaking above (e.g. 500m from your position). On Feb 16, 6:41 pm, Andrew Leach <[email protected]> wrote: > On 16 February 2011 17:28, Nathan Raley <[email protected]> wrote: > > > And that wasn't meant to be directed towards you Andrew. I get what you > > were saying. Store the address the user entered and then have the user > > provide a more accurate lat/lng by dragging the marker displayed by the > > Geocoded response to the exact location. You aren't "technically" using the > > direct results from the Geocoding but it is pretty close. > > Not a problem -- a discussion is a discussion. There have been some > remarkably robust discussions about the ToS in the Version 2 Group in > the past; and the same Terms apply to V3. So far, I think, the > consensus has been that the Terms say what they say. Comply with them > and all should be well: if you're not storing Google's data, you're > not storing it. > > However: no-one in either Group has offered legal opinion, just a > personal interpretation. Even Google won't comment on the Terms in any > way which might bind the company. -- You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" 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-js-api-v3?hl=en.
