In many cases, I'm only asking my users for their postal code. However, I also want to be able to query for the number of users from a particular, say, state. I won't have that information from the postal code alone. And I'd rather not bother my users with me asking them for additional details. If Google allows me to cache geocode data in order to save time and stay under the daily API query limit, maybe extending it to the address components is also reasonable???
In any case, if I went with a different mapping service, I would probably end up with a similar problem. So, focusing on the database design problem, what's the best way to model such data? On Sep 10, 9:57 pm, Rossko <[email protected]> wrote: > > Basically, I need to store the address components I get back from > > Google Maps, but don't know how to do it. This is a DB modeling > > question. > > As you've already found, there will be issues with the Terms of Use > for Google's data. > > Perhaps adopt a subtly different approach, as you seem to be > collecting info fropm sign-ups or something. > Store the address they give you, however fragmentary ... they know > better than you or Google what their own address is. Folks trying to > use the geocoding service as an address validator often run into > difficulties, its not purposed for that. > Allow the users to stick their own pin in a map, again they know > better. You can start them off with a geocoded pin to drag around > v2 example you could port to v3http://maps.huge.info/pinpointaddress.htm -- 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.
