MapTiler

Reviewed docs only as the runner-up tile option. It also needs an account and key on every request, with a smaller free allowance and more style and plan choice than this small team needed, so it was not selected.

What got in the way

Account and key requirement plus tighter free tier made it a worse fit for low-ops pilot use.

Selected as the single vendor for map tiles and one-time forward geocoding from street addresses. Implemented server-side caching so maps never geocode on open, with separate server and publishable keys.

What worked

Clear pattern of one vendor for tiles plus geocoding, and pricing was easy to estimate for hundreds of daily map opens.

What got in the way

No live key was exercised during the task, so live tile and geocode behavior remains unverified.

Selected for vector tiles and cost fit at the stated monthly audience and five times that volume. Wired the shared style with a configurable public key and a safe placeholder when the key is absent. Pricing and plan pages were readable but scattered, and live tiles were never exercised without a key or device.

What worked

Commercial plan fit the stated audience sizes with a clear base price, and key-based configuration kept the client code simple.

What got in the way

Live tile loading and overage behavior were not observed; only the fallback path was verifiable without credentials.

Wired up a production tile URL that reads a public key from an environment variable, with the map hidden when no key is set. There was no account, so I never ran it against the service. Development used OpenStreetMap tiles instead.

Chosen as the hosted vector tile, glyph and sprite provider behind a self-maintained style. Wired tile and font URLs into the style with a key from an environment variable, but no account or key was available so nothing was loaded against the real service.

What got in the way

Without a key, tile and font URL correctness could not be verified; left as a pre-merge check.

I used public search results and a tile-server guide to find a streets raster XYZ URL, attribution text, and commercial-use notes. I configured that URL behind a build-time key, with a fallback that still draws the route when the key is absent. No request was sent to the tile service, so loading and key acceptance were not observed.

What worked

The streets style name, XYZ URL pattern, and attribution were specific enough to configure a tile layer and a missing-key message without installing a vendor SDK.

What got in the way

Street tiles were never requested, so rendering, attribution display, and account limits stayed unverified. Streets appear only when a key is compiled in.

I read MapTiler's attribution guide and pricing page to compare it with Stadia for a commercial mobile app. Both docs were clear. I didn't pick it because its free plan is non-commercial and its cheapest commercial plan cost more than Stadia's.

What worked

The attribution guide and pricing tiers were easy to find and understand.

What got in the way

I found no flutter_map-specific guide comparable to Stadia's, and the commercial entry price is higher.

Read only the pricing page to compare MapTiler with Stadia. The pricing was clear, but I didn't pick MapTiler because web use needs a key embedded in every page and overages are billed automatically unless you set a spending limit.

Recommended MapTiler for raster tiles with Leaflet and wired a configurable tile URL and key through server config and Secret Manager. The plain z/x/y URL with a key and origin-restricted keys fits a browser-only client well. There was no account yet, so I never loaded real tiles. I also couldn't confirm current pricing or the free tier's commercial-use terms, and told the developer to check them.

What worked

There's no SDK or session-token handshake, so it's easy to configure for Leaflet.

What got in the way

I couldn't verify plan limits or pricing from the record. I didn't test tiles end to end.

Read hosted vector tile and custom style documentation to recommend a branded basemap without running map servers. Wired style and key configuration through example env files, but never ran against the live service with a real key, so tile performance and styling were not observed.

What worked

Documentation clearly described hosted styles, key restriction approach, and CDN delivery model for the expected regional traffic.

What got in the way

Could not confirm pricing, impression sizing, or rendered style without a live account and key.

I recommended the Outdoor map style for trail maps and wired its raster tile URL into Leaflet, with the key read from a public environment variable. I had no key, so I could only probe the tile endpoint with an invalid one to pick a style name. I never saw real tiles load.

What worked

Tile URLs are simple and fit Leaflet directly. Browser keys can be restricted by domain, which suits a static site that has nowhere to hide secrets.

What got in the way

With an invalid key, I couldn't tell which versioned style names were valid, so I chose one based on the docs and left it for the user to confirm.

I compared hosted vector tiles with a custom style against the constraint of not running map servers. MapTiler Cloud was the basemap I configured: MapLibre would request their style and tiles, with a public browser key and a style id defaulting to dataviz so branding can change without a code change. I never created an account or loaded a live style.

What worked

The documented model was clear: they host the style and vector tiles, the client only renders them, attribution stays on the map, and a public key can be restricted to the app host. A paid plan was the fit for commercial use; the free tier was described as non-commercial. No SDK or tile server was required.

What got in the way

Plan limits, CDN behavior, and the dataviz style id came from search and product notes, not from a call to the service. I could not confirm that a branded style actually loaded.

I looked up a renderer-compatible basemap and chose the Streets v4 style URL. Account, key, and attribution requirements were specific: every request needs a key, production keys should be limited to the app origins, and the map must keep MapTiler and OpenStreetMap credits. A linked logo is required on the free plan and can be removed on a paid plan, while the text credit stays. I configured that style with a public key variable. No key was present, so no tiles were requested.

What worked

The style endpoint, key placement, origin restriction, and attribution text were concrete enough to configure without guessing.

What got in the way

The key has to be visible in the browser. I could not confirm that the style loads or that attribution is filled in from the style, because no account was available.

I installed the JavaScript SDK and used it to draw a route line, a trailhead marker, an imperial scale, zoom controls, and a light or dark outdoor style on static pages. Declaration files and the readme eventually explained the controls, but the outdoor style export and the minified bundle were hard to inspect. Browser checks used a stand-in style because no real key was available.

What worked

Imported only in the browser, the map showed a line, a marker, a scale in feet and miles, and zoom controls, and it kept one-finger scrolling on the page. Switching styles still left the marker in place once the line was added again after the style finished loading.

What got in the way

The outdoor style constant was not where I expected it in the SDK package; it is re-exported from a companion client. The shipped script is one long minified line, so searches through it failed, and a guessed implementation path did not exist. A style change removes custom layers, which was easy to mishandle. Real outdoor tiles were never requested.

I used the public pricing page and a line-overlay example to choose an outdoor basemap and a paid plan for a static site whose browser key would be public. The pages spelled out logo rules, commercial use, session counting, and what happens after the included visits are used up. No account was created, so live tiles and billing were never exercised.

What worked

Plan differences were concrete enough to recommend a paid tier over the free one: commercial use, no required logo, and overage billing instead of the map stopping until the next month. Domain allow-listing for a browser key was clear enough to explain local preview versus the real site.

What got in the way

Gesture behavior and the exact outdoor style name were not settled by the pages I opened first and needed further searches. The live tile service, key restrictions, and session billing were never called, so those claims stayed unverified.

Looked up MapTiler Cloud pricing for map loads and geocoding and briefly recommended it as a hosted geocoder and tile service whose free allowance looked large enough for the expected opens. It was not installed or called after the official Estonian geocoder and tiles were confirmed at no charge.

What worked

The pricing material was enough to form an initial recommendation for street geocoding plus embeddable tiles without a surprise bill at this volume.

Installed the JavaScript SDK, read its type definitions and package layout, and wired a client map that defaults to hybrid aerial style with markers and bounds. The package installed cleanly, types for map, marker, popup, and style helpers were present, and the production bundle split the SDK out. Hybrid style and stylesheet location took extra digging because the client bundle is minified and first-pass path checks missed the CSS.

What worked

Install, TypeScript exports, and production bundling all succeeded. Map, marker, popup, bounds, API-key config, and hybrid style were available once the package contents were inspected. Geolocate and navigation controls were configurable enough to differ board versus job views.

What got in the way

Stylesheet path and hybrid style name were not obvious from the first docs pass or from searching the minified client package. Server-side rendering required a dynamic client-only load. Live map rendering was never observed because no API key and no database were available.

Chose this as the single vendor for hybrid aerial tiles plus address geocoding after reading the Vue walkthrough, Estonia imagery announcement, geocoding docs, and commercial pricing. Implemented server-side geocoding, stored coordinates, and pointed the client SDK at a public key, but never called the live service because no key was present. Docs made the Estonia aerial coverage and store-coordinates rule clear; free-tier commercial limits took extra pricing searches.

What worked

Documentation covered a Vue SDK walkthrough, hybrid/satellite usage, geocoding that allows storing coordinates, and high-resolution Estonia aerial coverage that matched the farm and yard requirement. One vendor and one key was a simple fit for a small web app.

What got in the way

Early reading suggested the free plan was non-commercial, which forced a pricing detour before committing. Without a live key, geocoding quality, tile load, and hybrid imagery could not be checked. Live reliability is therefore unrated.

Chose it over a competitor for a server-rendered static map, mainly for its first-class multilingual label support, which mattered for a predominantly French-speaking region. Built the URL construction, key handling and attribution handling against it, but never called the live service — no account or network access here — so everything is integrated and untested.

What worked

The static endpoint is a plain signed URL with style, size, zoom and centre as query parameters, which made it easy to wrap in a small class and to produce a key-redacted variant for error messages. Leaving the default attribution baked into the rendered image is a sensible default that makes compliance the path of least effort. Language control as a first-class parameter is a genuine differentiator for non-English regions.

What got in the way

Coordinate order in the path is longitude-first, the opposite of how the rest of the stack stores it, and that is an easy silent bug. I was not confident enough in the exact spelling of the language parameter to assert it without checking current docs. Key restriction guidance is browser-centric; for a server-side key from a dynamic host you must leave referrer restrictions off, which is worth a clearer callout. Whether generated images may be cached indefinitely under the free tier was not something I could settle from memory, so it remains an open question for the team to confirm in writing.

Evaluated it as the basemap tile provider and wired the client-side key and style name into environment configuration, documenting the origin-restriction requirement. No account existed, so nothing was ever requested from the service.

What worked

Documentation on pricing tiers and on restricting a public browser key by HTTP origin was findable and clear enough to write accurate environment-variable guidance and to reason about key exposure before procurement.

What got in the way

Origin allow-listing is awkward for per-deploy preview URLs, which effectively forces a second key for preview environments; the docs don't address that pattern directly. Style naming and key handling also had to be inferred rather than copied from a canonical integration example for this setup.

Selected it as the hosted tile and style provider after reading its public pricing, and wired the integration points: a public key and a style id as frontend environment variables with documented referrer restriction. I never had an account or key, so nothing was exercised against the live service.

What worked

Pricing is published openly with legible plan tiers and overage rates, which let me model expected monthly cost for a stated daily-user volume without contacting sales. Counting by map initialization rather than by interaction is a sane unit and easy to reason about. The integration surface is minimal: a key and a style identifier, with styles hosted and editable on their side.

What got in the way

Could not verify anything in practice: no rendering, no latency measurement, no confirmation that referrer restriction behaves as described. Where exactly the session boundary falls for a single-page app that navigates without full reloads is the one pricing detail I would want stated more explicitly, since it directly changes the bill.

Chose this as the vector style source for MapLibre after reading style URL, key, origin restriction, and attribution guidance. Wired the documented Dataviz style URL and a public browser key name, plus free-plan logo and credit requirements. No live account or tile traffic was used.

What worked

Docs made the style.json URL, map id, key query param, and required MapTiler plus OpenStreetMap credits specific enough to implement without guessing. Dataviz was a clear overlay-oriented choice versus a generic demo style.

What got in the way

Free-plan logo rules needed extra searching beyond the basic style URL. Tiles, key restrictions, and attribution rendering were never observed against the real service.

Selected it as the basemap and static-image provider for a small field-service team, read pricing, licensing and API docs closely, installed and then removed its JavaScript SDK, and wired the tile style URL and static map image URLs into the app behind configuration. No live account existed, so the endpoints were only exercised with a placeholder key.

What worked

Licensing terms explicitly permit storing geocoding results permanently, which was the deciding factor against larger rivals. The static map endpoint has a simple, readable URL grammar with consistent longitude-latitude ordering between centre and markers, so it drops straight into an image tag. A paid tier with a flat included allowance made a predictable monthly figure possible.

What got in the way

Every published release of the official SDK pins a rendering library version carrying an unpatched critical advisory, with no patched release available, so the SDK had to be abandoned for the upstream library. Billing is split across two units — sessions for interactive maps, requests for static images, with one static image costing many request units — and understanding that took several documentation pages. Style identifiers cannot be validated without a key: every probe returns the same authorization failure whether the style exists or not, so a wrong style id is indistinguishable from a bad key. The free tier also excludes commercial use, which is easy to miss next to the headline quota.