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.
On Wed, Feb 16, 2011 at 11:25 AM, Nathan Raley <[email protected]> wrote: > Andrew is correct as long as you implement it client and not server side. > See http://code.google.com/apis/maps/articles/geocodestrat.html where it > defines the following: > > Geocoding is the process of converting addresses (like "1600 Amphitheatre > Parkway, Mountain View, CA") into geographic coordinates (like latitude > 37.423021 and longitude -122.083739), which you can use to place markers or > position the map. The Google Maps API Family provides two approaches to > geocoding: > > 1. Client-side geocoding, which is executed in the browser, generally > in response to user action. The Google Maps JavaScript API V3 provides > classes that make the requests for you. This approach is described in the > Maps API for JavaScript > documentation<http://code.google.com/apis/maps/documentation/javascript/services.html> > and > the Maps Flash API > documentation<http://code.google.com/apis/maps/documentation/flash/services.html#Geocoding> > . > 2. HTTP server-side geocoding, which allows your server to directly > query Google's servers for geocodes. Typically, this is integrated with > other code. that is running server-side, and then used to generate a map. > Server-side geocoding is described in the Geocoding API > documentation<http://code.google.com/apis/maps/documentation/geocoding/index.html> > . > > > So if you implement it client side as this link explains, then you would be > okay as long as a single client isn't using more than the limited requests > per day. It really depends on your client in that case. However, if you > need your clients to have access to more a premier license is always an > option for you. > > Yea, there are many different ways to implement a work around for this. > Not sure what Google's stance would be on having the user entering the > information and you storing that into your database, using Google's > geocoding to find a "nearby" address, then having the user move the point to > a much closer location. The problem with this would be that I'd consider > storing the final lat/lng as still storing the geocoded results to an > extent, as the geocoded response was used to obtain the location. Without > storing the lat/lng there isn't a lot use storing the user information in > the database at all. At least, that is my take on it. It is all a play on > words, maybe someone from Google could give you more insight. -- 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.
