Google Maps API Terms of Service interrogations

[Drix]

We are planning to develop a website displaying locally based information and using geolocation to identify user's geographical position. In order to do so, we would like to use the Google Maps API. We are currently investigating to double-check if our concept fits with the Google Maps API Terms of Service. After reading those terms we still have a few interrogations, which we would like to ask you directly, in order to get the confirmation that our application matches those terms. Could you please confirm that the following points are complying with the Google Maps API Terms of Service?

• We want to use a Google Map as an easy way for users to give us addresses by pointing a location on the map. That means that we would like to use on our website the addresses retrieved by reverse geocoding from Google Maps and display them on pages as plain text without the Google Maps included.
• We would like to cache the coordinates of those addresses in our database in order to display them faster on our maps as suggested in the FAQ. We would also like to use those coordinates to retrieve the user timezone or to display the distance between two different points through the website possibly on pages having no Google Maps included. Any display of the positions themselves will be done with Google Maps API on several maps on the website.

Could you please confirm that those developments would meet the Google Maps API Terms of Service standards?

[Nathan Raley]

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.

Use of the Google Geocoding API is subject to a query limit of 2,500 geolocation requests per day. (User of Google Maps API Premier may perform up to 100,000 requests per day.) This limit is enforced to prevent abuse and/or repurposing of the Geocoding API, and this limit may be changed in the future without notice. Additionally, we enforce a request rate limit to prevent abuse of the service. If you exceed the 24-hour limit or otherwise abuse the service, the Geocoding API may stop working for you temporarily. If you continue to exceed this limit, your access to the Geocoding API may be blocked.

Note: the Geocoding API may only be used in conjunction with a Google map; geocoding results without displaying them on a map is prohibited. For complete details on allowed usage, consult the Maps API Terms of Service License Restrictions.

Also take note of these:

10.1 access or use the Service or any Content through any technology or means other than those provided in the Service, or through other explicitly authorized means Google may designate;

10.3 pre-fetch, cache, or store any Content, except that you may store limited amounts of Content for the purpose of improving the performance of your Maps API Implementation if you do so temporarily, securely, and in a manner that does not permit use of the Content outside of the Service;

--
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 google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

[Andrew Leach]

On 16 February 2011 16:58, Nathan Raley <nlra...@gmail.com> 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.

[Nathan Raley]

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 and the Maps Flash API documentation.
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.

 

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.

[Nathan Raley]

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.

[Andrew Leach]

On 16 February 2011 17:28, Nathan Raley <nlra...@gmail.com> 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.

[Drix]

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 <andrew.leac...@gmail.com> wrote:

[Rossko]

> 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.

[Nathan Raley]

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...

[Drix]

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.

[Nathan Raley]

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.

[Drix]

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?

[Nathan Raley]

Storing a lat/lng that the user entered is fine, as well as storing the address they used..  Using the Geocoding service to do so would not be.  Therein lies the issue with needing to have the user move the marker that was placed by Geocoding their address and then pulling the lat/lng from the marker, not pulling the lat/lng directly from the Geocoding response.  Also storing the address returned from the Geocoding is a no-no.  Just store user derived information and you should be fine.

That make sense?

[Andrew Leach]

On 17 February 2011 16:18, Drix <drix...@gmail.com> wrote:
> 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?

No: you can store anything you like as long as it doesn't come from Google.

So, you can store an address the user has given you; and you can store
some coordinates the user has given you. If you want to link those two
data items, that's up to you.

You can geocode the user's address, thus getting some data from
Google; but then you can't store that data, because that's Google's.

You can geocode the user's address and display that location on a
Google Map, because if you use the geocoder then the Terms of Service
require you to show the location on a map.

In your use-case, the user experience is actually improved by
following the rules. They give you an address (so you can be sure it's
accurate); you geocode it and display a map (so you comply with the
rules); then they give you some coordinates (so you can be sure they
are accurate too). You get accurate data, the user controls what you
are given, and you comply with the Terms. Everyone wins.

[Nathan Raley]

Yep, exactly as Andrew stated.  However, notice the step where the user gives you the coordinates.  That is done by the user moving the marker, therefore the coordinates are not the same as those returned from Geocoding the address they provided.  If you skip that step you are saving the information retrieved from Google and thus breaking the ToS.

--

[ora726]

Hi All,

Sorry for coming late into this tread but I think there are still a few things to be said and asked :

1) Google specify that a geocoded address has to be used in conjunction with a google map, not that it has to be displayed on the map. Which bring me to the next 'Grey area', what is exactly in conjunction ? For example if I display a map and write the result of the geocoding on the side of the map am I ok ? Pushing this a little further can I display geocoded address and have a button to show it on a map if the user want it ? After all strictly speaking that would still be in conjunction with the map, they are simply not on the same page, as long a I generate the map and the geolocation info at the same time I have at least a temporal conjunction. I know I am splitting hairs in half but as you see interpretation can be "Elastic", anybody ever got more precise definitions of conjunction in the sense of the terms and conditions of google ?

2) Somebody proposed to move around the marker on the map and get the lat/lng from it, well I am not sure that would allow the storage of the location info, the reason I say this is that if you move around a marker and then use the API to pinpoint the lat/lng of the Marker then you are getting the result from Google API, which mean that you can't store it.

The only thing that could be stored is the lat/lng returned by your GPS or location service, nothing else.

3) Please add also tot he equation that you must most likely be living in areas of the world where the Google geolocation info are pretty good.I recently moved to Serbia and found that when doing a geolocation of my address, the returned coordinate is 2 blocks down the road from where I live. It's all good and nice because I know the place and I have already explored it on the map before, but if you are providing a service relying on geolocation services in countries where the info are less than precise, you can't assume that the user will know how to provide a more precise location by moving a curseur, a lot of people are totally lost on a map, so again the only real info you can count on are lat/lng returned from a gps and I think it is critical to provide as well a good understanding of the precision of the info, 100m precision when on foot in narrow streets is plenty enough never to find your location.

Would love to hear more and hope this tread is not gone cold.

Raymond