On 16 February 2011 16:58, Nathan Raley <[email protected]> wrote: > Here is some information regarding your questions. Reverse geocoding is > fine, but storing the information in the manner you describe would be > against the TOS. You are limited to 2,500 requests per day for your site, > so if you are planning on being within that limit then you should be fine.
It's 2500/day per *client*, isn't it? If the geocoding is done server-side, then that's 2500 for the site; if each client does it, it's likely to be more than enough. My issue about the proposal is with getting the user's address from the map. Reverse-geocoding is notoriously inaccurate! Why not get them to enter their address (which can then be structured for your database), and then get them to show it correctly on a map? Geocode the address, which will put a marker in approximately the right place, and then ask them to move it to exactly where it should be. See http://maps.huge.info/pinpointaddress.htm for an example of this functionality (Version 2, but it illustrates the user interface nicely). The user has control of his data throughout the process: what address he enters and where he is. Doing this also means you are not storing reverse-geocode data; in fact you're not even storing "forward-geocoded" data, because the user is positioning the marker himself. And you comply with the requirement to show the geocoder results on a map because that's how the user gets a marker to move to his correct location. -- 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.
