Maximum 6,000 queries per day, calculated as the sum of all requests for all applications using the credentials of the same project.
---
Photorealistic 3D Tiles
Maximum 300 root tileset queries ["map-loads"] per day. This is calculated as the sum of all requests for all applications using the credentials of the same project.
Maximum 250,000 renderer’s tile requests per day. This is calculated as the sum of all requests for all applications using the credentials of the same project.
Rate limit is 12,000 queries per minute for the tile renderer.
---
The Map Tiles API documentation does not contain a "Usage and Billing" section, which seems to imply that it is free to use, bound to the above mentioned limits.
So the only thing to worry about is how Google showed us couple of years ago how relentless it starts to charge for a previously free service -- the Google Maps Javascript API -- after it sees that enough developers got technically invested into Google Maps.
If you open the inspector on any of the examples [1] you'll see how many tile fetches it triggers per second.
While my comment contains some criticism, I'm really excited for this new offering.
In some cases making users supply their own API key is the best solution - although it does put a fairly high bar on both commitment and technical understanding. (the latter mainly because the Google API UI is so damn complex!)
I kinda wish Google supported this better - they should make a new flow for opensource/free software where an oauth dialog is shown where the user is asked if the application can do billable things - and obviously the consent dialog would allow you to choose how much, if anything, you want to spend on API requests.
This lets opensource and free/hobby projects use all google API's with the actual users footing the bill directly. And obviously most uses are only a cent or two, so will normally fall in free allowances.
That would be awesome, but it would also make it way harder for Google to offer a free tier in the first place. 300 free queries per user per day is a lot more than 300 free queries per developer per day, so it might be a mistake to make that usage pattern even easier.
Though maybe they could just place way stricter limits on requests placed via API tokens obtained this way? That would probably work. But it would also sort of defeat the purpose of having users use their own API tokens. If everyone's going to need to pay to use your app anyway, you can just have them pay you to use your API token and gain an easy source of monetization in the process.
For FLOSS use cases, the author may not want to deal with everything that comes from collecting money from people. So it's still useful to let users pay Google directly for their usage.
---
2D Tiles and Street View tiles
Maximum 6,000 queries per day, calculated as the sum of all requests for all applications using the credentials of the same project.
---
Photorealistic 3D Tiles
Maximum 300 root tileset queries ["map-loads"] per day. This is calculated as the sum of all requests for all applications using the credentials of the same project.
Maximum 250,000 renderer’s tile requests per day. This is calculated as the sum of all requests for all applications using the credentials of the same project.
Rate limit is 12,000 queries per minute for the tile renderer.
---
The Map Tiles API documentation does not contain a "Usage and Billing" section, which seems to imply that it is free to use, bound to the above mentioned limits.
So the only thing to worry about is how Google showed us couple of years ago how relentless it starts to charge for a previously free service -- the Google Maps Javascript API -- after it sees that enough developers got technically invested into Google Maps.
If you open the inspector on any of the examples [1] you'll see how many tile fetches it triggers per second.
While my comment contains some criticism, I'm really excited for this new offering.
[0] https://developers.google.com/maps/documentation/tile/usage_...
[1] https://storage.googleapis.com/gmp-maps-demos/3d-tiles/index...