But in both cases we will still be storing a latitude and longitude... Is storing the lat/lng plus the address the problem? Meaning that we could make the link between both?
On Feb 17, 4:56 pm, Nathan Raley <[email protected]> wrote: > I think what he was suggesting is storing the user entered address is fine. > Storing the lat/lng from the direct results of the Geocoding from that > address is not. However, having the user adjust the position by moving the > marker afterwards should be okay as it is then entirely user entered. > Storing the lat/lng without doing so would be storing the Geocoded > information, even though you are only storing a part of it. > > The ToS is up to interpretation, but I believe that is the general consensus > with regards to this. > > > > On Thu, Feb 17, 2011 at 9:54 AM, Drix <[email protected]> wrote: > > Thanks for your answer Rossko. But I'm not sure to get the point here. > > To clarify a bit the things for me, what can we actually store on the > > database from the data collected through a Google Maps and how can we > > use this data? In our case, it's always the user giving us the data, > > but through a map or an input field linked to a map. Is there any > > difference storing coordinates (latitude, longitude) from storing > > textual addresses? Or is it storing both together the problem? As I > > mentioned before Google suggests that we can store the coordinates for > > a faster display of a location on map on next requests. > > > On Feb 16, 7:31 pm, Nathan Raley <[email protected]> wrote: > > > Yep, as Rossko pointed out. If you straight up use the lat/lng that was > > > provided from the geocoded data would be directly storing the > > information... > > > > On Wed, Feb 16, 2011 at 12:27 PM, Rossko <[email protected]> > > wrote: > > > > > For my second point, that means that we couldn't use the latitude and > > > > > longitude to retrieve the user's timezone? ... > > > > > And what about displaying > > > > > the distance from the current user with displayed location? > > > > > That would arguably be storing and using Google's data for some other > > > > purpose than improving map display i.e. against the terms. > > > > > The get-round would be the same ; not to store Google's data, but > > > > instead store what the user provides via some suggest-and-drag > > > > interface. There's nothing to stop the 'suggest' interface from > > > > placing an arrow or marker some random distance away from the > > > > suggested geocoded location to (a) encourage the user to fix it > > > > properly (b) demonstrate you are not storing Google's data as-is. > > > > > -- > > > > 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. > > > -- > > 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. -- 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.
