27

This question has been asked in a few places on SO, but I've found the answers to be either slightly contradictory or "thin"... so I'm not sure if asking again will help but here goes.

The google "help" page says that the google team maintains a "presence" on SO, so if you are a google chap, please could you make this clear, and if you are not please also make this clear, thank you :)

So, what I want to do... User searches for a set of locations. These will be used to form a travel itinerary. I want to take the lat/lng and the address components and store them in my own database so that when another uses search for trips in some country, some place etc etc I can go about finding them.

The big question, does the terms of conditions allow this? The relevant bit that worries me is...

10.1.3 Restrictions against Data Export or Copying.

... snip ...

(b) No Pre-Fetching, Caching, or Storage of Content. You must not pre-fetch, cache, or store any Content, except that you may store: (i) limited amounts of Content for the purpose of improving the performance of your Maps API Implementation if you do so temporarily (and in no event for more than 30 calendar days), ...snip... For example, you must not use the Content to create an independent database of "places" or other local listings information.

Would what I want to do violate this. It sounds to me like it might, but then that renders the question, why would I use google maps for this kind of application? Other travel sites appear to?!

Community
  • 1
  • 1
Jimbo
  • 4,352
  • 3
  • 27
  • 44
  • 3
    Curiously Google gives an example of storing lat/lngs in a database here: https://developers.google.com/maps/documentation/javascript/mysql-to-maps – Matthew Jun 06 '19 at 03:50

6 Answers6

24

There is no problem if you store

  • latitude and longitude
  • addresses

As those would be "user preferences" in your app.

The restrictions on data export refer to the tiles and photos used to display the maps. In general people want this feature to have a cache mechanism or provide offline functionality. This is not allowed* and only the official mobile app has this features.

*Google actually allows it, but you have to read the finer print, more on that below.

Longer answer, analyzing the ToC:

No Pre-Fetching, Caching, or Storage of Content. You must not pre-fetch, cache, or store any Content...

What does content mean? This is map tiles, terrain tiles, photos of places, satellite photos etc. The content, in the ToC, is anything that has been created by Google and provided as part of the Google map service. But, not everything provided in the service has been created nor is owned by Google.

  • Addresses are not created or owned by Google, this is public information. What Google has done is to gather them and put them in a presentable, easy to search, interface. But it is not part of "the content".
  • GPS locations are not created or owned by Google, this is public information as well. In fact, GPS was created by the department of defense (DoD) in the US. They are the ones who control its use.

...For example, you must not use the Content to create an independent database of "places" or other local listings information.

It wouldn't be fair to Google if you downloaded a subset of the content, lets say all the tiles and photos for your home town. Once you have your copy of the files, you do a little processing on them, maybe add trivia or fun facts that only you know because you grew up there. And then use that to provide a re-branded service. Something called JimboMaps perhaps. That is the type of thing that is prohibited.

you may store: (i) limited amounts of Content for the purpose of improving the performance of your Maps API Implementation if you do so temporarily

Guess what, you are actually allowed to store content in you database. Any of it, photos, tiles etc. The catch is:

  • You can store limited amounts. A few blocks, probably a small region is ok. But don't store a whole town or suburb.
  • You can't store anything for more than 30 days.
  • The only valid reason to do this is performance improvement of your application. See this: Google Maps v3 - Map tile caching on client?

...you must not use the Content to create an independent database of "places" or other local listings information.

It is just saying that you are not allowed to create JimboMaps.

Community
  • 1
  • 1
givanse
  • 14,503
  • 8
  • 51
  • 75
  • Thanks for your help. Could you point to that in the TOC pls? I'm still a little confused as to why storing that doesn't clash with the bit that says ...independent database of "places" .... Cheers :) – Jimbo Dec 29 '13 at 16:57
  • I have expanded on my answer. If you want to get precise details of how much you can store or how you can validate your app against the ToC, you'll have to talk to a Google representative. – givanse Dec 29 '13 at 19:02
  • Thanks that's really clear. One of the best answers on the subject I've read so far on SO. Cheers! – Jimbo Dec 30 '13 at 13:42
  • I have been searching everywhere for a solid answer on this and this is the most complete, understandable answer I have come across. Thank you Givanse! – PaulP1975 Jan 22 '14 at 00:20
  • 3
    I don't think that this answer is correct, when the data have been obtained via a google-service(geocoding, directions, etc.) it's content in the meaning of the TOS. – Dr.Molle Jul 09 '15 at 10:29
  • 4
    You ask "What does content mean?" and then answer it yourself, but you do not cite the actual clause in the TOS. Note that "Content" is capitalized, which in contracts usually implies that it has a specific definition which is being referenced. It's under 8.1.b: '(b) "Content" means any content provided through the Service (whether created by Google or its third party licensors), including map and terrain data, photographic imagery, traffic data, places data (including business listings), or any other content.' Note the broad definition, which specifically includes content they did not create. – Hugh Guiney Aug 18 '15 at 06:46
  • 2
    Sorry to Raise this question again....but I have the same dilemma, looking at @givanse 's answer it seems relevant and correct, but Dr. Molle and Hugh Guiney have raised concerns for me. Jimbo what did you do? are you storing the location data or not – Paul Sep 10 '15 at 15:32
  • **lat/lang** and **addresses** are not provided by Google, that is user input that you can perfectly store in your app. And, what I wouldn't store is whatever the API sends me back **after** I send the **user input** that I gathered. – givanse Sep 10 '15 at 17:47
  • 2
    thanks for the update givanse...my situation is that I have a list of addresses and I want to get the lat/long of these addresses using the API - so it means that I would not be allowed to store the lat/long in a data store....mmm not good for me then...will have to use another tool to access the lat and long then – Paul Sep 11 '15 at 08:54
  • Can anyone prove that the relationship between your addresses and their GPS coordinates were **not** made by hand or another piece of software? – givanse Sep 11 '15 at 18:08
  • just because they can't prove that you didn't "steal" the data from Google, doesn't make it any less of a violation of the TOS. – dangel Jun 10 '18 at 03:30
4

The newest Google Maps Platform Terms of Service (which takes effect July 16, 2018) is a bit more explicit about this.

3.2.4 Restrictions Against Misusing the Services.

(a) No Scraping. Customer will not extract, export, or scrape Google Maps Content for use outside the Services. For example, Customer will not:(i) pre-fetch, cache, index, or store Google Maps Content for more than 30 days; (ii) bulk download geocodes; or (iii) copy business names, addresses, or user reviews.

Yes, the address might be public knowledge, but the process to obtain it is subject to the terms of the service you use...

dangel
  • 7,238
  • 7
  • 48
  • 74
  • IMO (and that is what it is), a latitude and longitude is not a part of an address. It is part of a construct for describing the globe. Then again, I'm not sure how Google can restrict use of an address since that would seem to be owned by the person who has the legal authority over the property. Did Google get permission from them? Or pay them for use of the address? – tim.rohrer Feb 16 '19 at 16:04
  • @tim.rohrer I interpret what Google is saying more or less as "you cannot store anything that you get from us". The information is very much public domain, but the method to retrieve it from Google is what's being restricted. – dangel Feb 17 '19 at 02:51
  • @dangel, more specifically I, as a developer, cannot take the `results` object and save portions (or the entire contents) to my database (except `placeId`). However, if the user enters a lat/lng in an app that is then displayed, Google doesn't get to claim control of that. I think we're effectively saying the same thing; I just don't want to give more ground to Google than is necessary. Bottom line, we are paying Google for the service, not for a license of the information the that is actually owned by someone else. In that sense, a lat/lng is not part of an address. – tim.rohrer Feb 17 '19 at 20:38
  • A part I'm still researching has to do with `autocomplete` search results. If the user gets an address from that, can that be stored in the app's database? – tim.rohrer Feb 17 '19 at 20:39
  • 3
    @tim.rohrer AutoComplete still uses places api. So, same restrictions apply. But I completely get you. How can Google restrict this? It's the same as me saying "Hey Google you cannot save any data you get from my house. My house's lat/lng or image taken from space". I would actually make more sense if I did. – Cüneyt Aliustaoğlu Jun 20 '19 at 02:53
  • yes this is so wrong, i agree we could pay them but please let us use the content for us to work on. – Mikey Oct 21 '19 at 11:00
3

This is from Google's Developer pages:

https://developers.google.com/maps/articles/geocodestrat

*Caching Considerations

The Google Maps API allows you to cache geocodes (i.e. store them on your server for a limited period). Caching can be useful if you have to repeatedly look up the same address. However, there are two important things to keep in mind. 1.The Google Maps API Terms of Service allow you to use geocodes derived from the service on Google Maps or Google Earth only. You may not sell or distribute them in other fashion. 2.Geocoding changes often as our data gets more and more accurate. So even if you have cached data, you should refresh it periodically, to make sure you are getting the best geocodes for your locations.

The Google Maps API for Flash requires the use of API keys. Many people mistakenly think quotas are tied to keys. However, keys don't affect your geocoding quota at all. Registering for a new key won't help. Quota is solely tied to IP addresses. Therefore a new key won't give you any more quota at a particular IP address.*

Andrew - OpenGeoCode
  • 2,299
  • 18
  • 15
  • Thanks for your answer Andrew. I'm not looking to cache data... I'm looking to store it permanently though. – Jimbo Dec 29 '13 at 16:58
3

This quote from their website (https://developers.google.com/maps/documentation/geocoding/geocoding-strategies) says you can save data for your use if you know you will need it many times, but recommends you update periodically.

Caching considerations

The Google Maps Platform Terms of Service allow you to cache geocodes (that is, store them on your server for a limited period). Caching can be useful if you have to repeatedly look up the same address. However, keep in mind that geocoding results change as our data gets more and more accurate. So even if you have cached data, you should refresh it periodically, to make sure you are getting the best geocodes for your locations.

Community
  • 1
  • 1
John Halsey
  • 1,930
  • 3
  • 19
  • 41
0

TL;DR: I think storing lat/long from services provided by Google is not allowed

Google Maps Platforms terms (21.11.2019)

3.2.4 Restrictions Against Misusing the Services.

(a) No Scraping. Customer will not extract, export, or otherwise scrape Google Maps Content for use outside the Services. For example, Customer will not: (i) pre-fetch, index, store, reshare, or rehost Google Maps Content outside the services; (ii) bulk download Google Maps tiles, Street View images, geocodes, directions, distance matrix results, roads information, places information, elevation values, and time zone details; (iii) copy and save business names, addresses, or user reviews; or (iv) use Google Maps Content with text-to-speech services.

To me it looks like storing lat/long is (even explicitly) prohibited.

"Google Maps Content" is actually defined in the terms & conditions.

"Google Maps Content" means any content provided through the Services (whether created by Google or its third-party licensors), including map and terrain data, imagery, traffic data, and places data (including business listings).

Also the remark about it being ok to cache data for some time and periodically refresh it is no longer there, see Geocoding API Policies.

Pre-Fetching, Caching, or Storage of Content Applications using the Geocoding API are bound by the Google Maps Platform Terms of Service. Section 3.2.4(a) and (b) of the terms states that you must not pre-fetch, index, store, or cache any Content except under the limited conditions stated in the terms.

Note that the place ID, used to uniquely identify a place, is exempt from the caching restriction. You can therefore store place ID values indefinitely. Place ID values are returned in the place_id field in Geocoding API responses.

For what it's worth you can store Place IDs instead of lat/long ;-) You may want to use another service for lat/long geocoding.

Community
  • 1
  • 1
lapsus
  • 2,915
  • 2
  • 32
  • 61
0

Like others have said, the updated terms https://cloud.google.com/maps-platform/terms/#3.-license. section 3.2.3 (b) explicitly states (May 6, 2020)

(b) No Caching. Customer will not cache Google Maps Content except as expressly permitted under the Maps Service Specific Terms.

BUT

The specific terms (handily not linked in the terms, that I could easily see) mention this

(hopefully this is the specific terms https://cloud.google.com/maps-platform/terms/maps-service-terms updated June 14, 2020)

1.4 Caching. Customer can temporarily cache latitude (lat) and longitude (lng) values from the Directions API for up to 30 consecutive calendar days, after which Customer must delete the cached latitude and longitude values. Customer can cache Directions API Place ID (place_id) values, in accordance with the Directions API Policies.

Section 1.4 is for the directions API, but most of the other API's have the same exception. Unfortunately it doesn't mention address data.

Jarrod McGuire
  • 523
  • 5
  • 11