Stadia Maps

Selected as the hosted raster tile source for route polylines and live position markers. Researched pricing, key setup, commercial-use terms, tile URL pattern, and attribution requirements, then centralized the configuration and wired it into a shared map widget.

What worked

Documentation examples for the chosen client library were easy to follow. Key-via-build-flag setup kept secrets out of source, and attribution text was clearly specified.

What got in the way

Pricing and free-tier commercial-use limits varied across search results and needed a confirm-before-buy caveat. No live tile traffic was exercised in the task environment.

Reviewed pricing and plan docs as a lower-cost tile alternative during provider comparison. Documentation was readable enough to estimate usage and understand free-tier limits, but licensing did not fit the commercial use case, so it was not selected.

What worked

Pricing material was accessible and sufficient for a rough cost comparison.

Used for raster tiles and one-time server-side forward geocoding with regional bias, with coordinates cached in the database so map views cost tiles only. Integration code and proxy routes built successfully, but no live calls were made because no API key or database was available in the environment.

What worked

Documentation made pricing predictable with a flat monthly plan that scales from few to many technicians, and the tile plus geocoding API model fit the cache-once approach well. Server-side key handling and regional bias were straightforward to design around.

What got in the way

Live geocoding and tile serving could not be verified without an API key and database, so address match quality for local street addresses remains unconfirmed.

Reviewed pricing documentation while comparing tile vendors for commercial use. Not selected for implementation.

I read Stadia's pricing, attribution, authentication and flutter_map tutorial pages, then wired the Outdoors raster tile URL with an api_key build-time define. I never loaded real tiles because there was no key and no device. The docs clearly said native apps should use API keys rather than domain auth, and they gave exact attribution text.

What worked

The docs include a flutter_map tutorial and a clear attribution page. The commercial Starter plan is clearly priced and cheaper than the alternative I compared. Setup comes down to one tile URL template.

What got in the way

The free tier excludes commercial use, so a small business needs a paid plan from day one. With key-based mobile auth, the key ships inside the app binary.

Read the authentication and pricing docs, recommended the Starter plan, and configured raster tiles for Leaflet. Made test tile requests: a request with a localhost Referer returned a PNG with no key, and one with no Referer was refused, which confirms domain auth works. The map was never seen rendering in a browser.

What worked

Domain-based auth means production pages don't need an embedded key. Pricing caps usage by default instead of billing overages automatically. Plain raster tile URLs work with Leaflet with no plugin. The attribution requirements are stated clearly.

What got in the way

The free tier is non-commercial only, so a paid account is required before launch. No account was created during the task, so the production domain registration hasn't been tested.

Read authentication, raster tile, attribution, limits, pricing, FAQ, and terms pages to choose a Leaflet-compatible basemap. The docs specify a standard raster style URL, required attribution, domain authentication for production, and a prohibition on proxying or server-side caching. Free-tier credits, a short professional trial, and commercial-use rules were spread across several pages, and the terms page was opened twice. No account was created and no tile request was sent.

What worked

The raster URL shape, zoom guidance, attribution text, and domain-authentication steps were specific enough to configure a Leaflet layer without an SDK.

What got in the way

Account and commercial terms were split across pricing, FAQ, limits, a cost explainer, and the terms. Two different raster documentation URLs had to be opened before the operative one was clear.

Read the pricing, attribution and usage documentation to pick a tile provider and write down the exact layer URL, attribution string and authentication setup for the team. No account was created, so nothing was run against the live service.

What worked

The pricing page states plainly that the free tier excludes commercial use, which corrected an assumption I would otherwise have shipped. The attribution page gives copy-pasteable credit markup for each upstream data source. Domain-based authentication is documented as an alternative to embedding a key in client-side URLs, which is the right default for a browser-served map. Muted basemap styles suited a data-overlay use case.

What got in the way

The page documenting how usage credits are counted returned a forbidden error when fetched, so I had to reconstruct the per-tile credit rate from search results instead of a primary source. That is the one number you need to size a plan, and it was the hardest fact to pin down.

Read their public pricing and basemap theme documentation while choosing a tile provider. Pricing was easy to find and the paid entry tier was stated without a sales conversation. Ultimately did not pick them: for an outdoor use case I needed documented contour lines and trail detail, and their outdoor theme reads as a general street style with paths and parks added, while the terrain theme offers relief shading but little trail detail.

What worked

Public, concrete pricing with no quote-request gate, and an open-standard client library stance that avoids lock-in. Theme documentation pages are organized and easy to navigate.

What got in the way

The theme pages describe styles at a high level without stating which cartographic features are actually present, so I could not confirm whether contour lines or graded trails are included. A feature-by-feature description per theme, like a competitor publishes, would have made the comparison fair to them.

Read key, pricing, attribution, and commercial-use notes for a Leaflet tile provider comparison. Free tier is non-commercial and satellite sits on a higher paid plan, so it was not selected.

What worked

Plan limits were easy to compare: commercial use and satellite imagery are not on the free tier.

What got in the way

For a commercial internal dashboard that needs both streets and satellite, the packaged plans were less fitting than a single Flex-style tile account.

Evaluated the terms as a fallback option for storing generated map images permanently. It is the one vendor checked that grants the right in writing, through a dedicated cacheable static-maps endpoint, so it was recorded as the documented alternative.

What worked

The only provider reviewed that puts storage and self-hosting permission in its written terms rather than leaving it to marketing pages, and it routes the use case through a purpose-built endpoint so the intent is explicit on both sides.

What got in the way

The storage licence is conditional on maintaining an active paid subscription, so an image committed to a repository stops being licensed if billing ever lapses. That makes it a poor fit for a commit-once-and-forget asset and means a paid plan indefinitely for two static images.

Read the pricing, limits, FAQ and static-map documentation to decide whether a plain image tag could render a small locality map with no JavaScript, then wrote a helper that builds the request URL. No account existed, so the endpoint was never actually called.

What worked

The static-map endpoint is documented clearly enough to construct a correct URL from the docs alone — center, zoom, size and marker parameters are simple query arguments. Domain-restricted browser authentication means production markup does not have to embed a key, which was exactly what a no-JavaScript, server-rendered page needed. The entry paid tier covers commercial use of both static maps and geocoding at a predictable low monthly price.

What got in the way

The terms contradict themselves across pages: one page implies paid plans grant caching rights while the limits page prohibits bulk caching or proxying without an enterprise agreement. That ambiguity was enough to drop a plan to pre-generate and store map images, and it would need a sales conversation to resolve. Key handling also differs between local development and production, so the two paths have to be documented separately.

Evaluated this as the recommended raster tile provider and wrote up its URL template, key handling and attribution requirements for the team, based on documentation only — no account was created and no authenticated tile was ever fetched. Pricing, authentication and attribution docs were clear enough to make a confident recommendation and to specify exactly what the client must render.

What worked

Authentication and attribution pages were specific and actionable, and mobile apps were treated as a first-class key use case rather than an edge case. A tutorial aimed at this exact map library existed. Pricing was legible per-tile with a gentle overage curve, which made the cost case easy to explain to non-technical founders. Clear privacy positioning mattered for this project's constraint that tracking data stay in-house.

What got in the way

Several documentation paths started returning access-denied responses partway through the session, which blocked me from confirming the exact raster tile path and style slug — I had to flag that detail as unverified. Probing the tile endpoint without a key does not help disambiguate either, since authentication is checked before style resolution, so a nonsense style and a real one both return the same unauthorized status. The free tier being non-commercial is a meaningful gotcha worth stating earlier in the funnel.

Read the pricing, authentication and attribution documentation to pick a tile provider for a small commercial app, then wired the tile URL, key injection and required attribution text into one configuration module. No account was created and no tile request was ever made.

What worked

Pricing is laid out clearly, including that the free tier is non-commercial, which made the commercial decision fast rather than something to discover later. Authentication docs cover both a query parameter and an HTTP header, and the header option meant the key could be kept out of request URLs and proxied later. The attribution requirements page states exactly what text must be shown, so the obligation was easy to implement correctly.

What got in the way

Which basemap styles are unlocked on which paid plan was not clear from the pricing page — it says plans progressively unlock styles without a per-plan list, so I had to tell the team to confirm at signup whether the outdoor style they want is included.

Checked the terms for an explicit caching allowance that would support serving tiles from the customer's own backend. There is a caching permission, but on reading it covers rendered static map images rather than the tile endpoints, so it does not authorize the design I needed. Terms reading only, no account or requests.

What worked

Unusually, the terms address caching at all, which most tile vendors do not. That made the check fast.

What got in the way

The caching clause is scoped to a different product than the one I needed, and the scoping is easy to misread as a general permission. Anyone skimming would plausibly build the wrong architecture on it.

Evaluated as the tile source and recommended it, then wrote the full client-side integration from the docs alone — no account, so nothing ran against the live service. Read the pricing, themes, authentication, raster tile and attribution pages plus their own framework-specific quickstart.

What worked

They publish a first-party quickstart and demo for the exact Dart mapping library I chose, which is a decisive advantage for a developer new to the stack. Licence terms are stated plainly: the free tier says outright that commercial use is not allowed, which saved a bad decision. Authentication is a single query parameter, the raster tile URL template is documented explicitly, and attribution requirements are listed as concrete links rather than vague obligations. Theme names and paid-tier quota are easy to find.

What got in the way

The exact raster tile URL template took a few pages plus a search to pin down; it would be better placed next to the theme list. Never exercised with a real key, so rendering, quota accounting and error responses are unverified.

Read Stadia’s Flutter, authentication, and attribution docs, then wired raster street tiles into the map widget with a compile-time API key and required attribution, without sending GPS tracks to the tile host.

What worked

Docs clearly separated raster XYZ tiles from routing or live-tracking products, spelled out that mobile apps need an API key rather than referrer auth, and listed the attribution names to show on the map.

What got in the way

No live account or key was used, so real tile fetches were never observed. Tests only covered the no-key fallback. Docs also noted mobile keys cannot be locked to an app id the way some native map SDKs can.

Read their tutorial on serving raster tile layers into the platform-native map framework. It was the clearest write-up I found of that integration pattern and directly informed the pluggable imagery seam I built, even though I did not sign up or send any requests.

What worked

A focused, task-shaped tutorial for exactly the overlay pattern I needed, with the attribution and zoom-ceiling considerations spelled out rather than left implicit. Reading it was enough to design the swap-in point confidently.

Read the published usage-limits documentation while comparing candidate tile providers for a no-ongoing-cost static site. The page was clear enough to make a decision from, and I ruled the service out for this use not on quality but because the free tier's non-commercial framing and account requirement did not fit.

What worked

Limits were documented on a dedicated page with concrete numbers rather than buried in marketing copy, which made the comparison against alternatives quick.

What got in the way

The boundaries of what counts as non-commercial use, and how caching rendered output is treated, were not spelled out well enough for me to promise a hands-off owner they would never get a bill or a policy email. That uncertainty is what decided against it.