osm2cdr.com

WMTS — OGC Tiled Web Map Service Standard for INSPIRE and Government Open Data

2026-07-0518 min read
WMTSOGCINSPIREtile serviceGeoServerMapProxygovernment GIS
Export formats: WMTS

WMTS (Web Map Tile Service) is a 2010 OGC standard for publishing pre-rendered raster tiles through a web service with a formal Capabilities document and predictable TileMatrixSets. Unlike its older sibling WMS, which generates an image on demand for an arbitrary bbox and image size, WMTS serves pre-cut tiles on a fixed grid — giving linear scaling under load, simple CDN caching, and predictable per-request latency. The standard was adopted by the Open Geospatial Consortium in 2010 as OGC 07-057r7 after several years of discussion-paper iteration on 06-187r1, and has since become the backbone of EU INSPIRE infrastructure — Directive 2007/2/EC requires member states to provide view services specifically through WMS/WMTS. Today WMTS is the format of choice for most national geo-portals: USGS (basemap.nationalmap.gov), BKG Germany (sgx.geodatenzentrum.de/wmts_basemapde), IGN France (wxs.ign.fr/wmts), Ordnance Survey UK (api.os.uk/maps/raster/v1/wmts), GSI Japan (cyberjapandata.gsi.go.jp). On osm2cdr.ru we ship an export of a WMTS-compatible tile pyramid from OSM PostGIS together with a ready Capabilities XML that can be dropped onto any static hosting — S3, Cloudflare R2, Nginx — and consumed as a fully functional WMTS endpoint.

Map generation of Berlin city center

History: OGC 06-187r1 → WMTS 1.0.0 (2010) → 1.0.1 cleanup (2020)

By the mid-2000s it was clear WMS (a 1999 standard) couldn't scale to mass web-map traffic. Google Maps in 2005 popularized XYZ tiling — a trivial convention /{z}/{x}/{y}.png without any formal spec — and the web world adopted it instantly. But enterprise GIS and government portals needed a formal OGC-compliant standard with metadata discovery, because their workflows were built around Capabilities XML parsing, federated catalogs (CSW), and compliance with national geo-strategies.

In 2006 OGC published discussion paper 06-187r1 «Web Map Tiling Service», which first formalized the TileMatrixSet concept — an ordered pyramid with concrete scale denominators, a top-left origin, tile size, and matrix dimensions at each level. The document was developed over four years with participation from USGS, ESA, ESRI, Lat/Lon GmbH, Cubewerx, Compusult, and on 6 April 2010 was finalized as OGC 07-057r7 — WMTS Implementation Standard version 1.0.0.

In April 2020 version 1.0.1 was released as a pure errata patch without functional changes: XML schema corrections, typo fixes in Annex E (standard TileMatrixSets), clarifications on dimension handling. In parallel OGC began work on WMTS 2.0 as part of OGC API — Tiles, which reframes the spec into a modern JSON+REST approach; but classic WMTS 1.0 continues to dominate production deployments simply because billions of tile requests per day already flow through it.

INSPIRE Technical Guidelines for View Services formally allow both WMS and WMTS, but for static basemaps and orthophoto WMTS became member states' preferred choice — it's cheaper on compute, scales better through CDN, and is easier to audit for compliance. By 2025 all 27 EU countries provide at least one WMTS service from their national mapping agency.

Inside WMTS: TileMatrixSet, KVP, REST, Capabilities

WMTS defines three bindings — three ways to transport requests: KVP (Key-Value Pairs via HTTP GET), RESTful (URL templates), and SOAP (XML-based, practically unused). Any compliant WMTS server must support at least one, and most production servers implement KVP + RESTful simultaneously.

KVP binding. A request looks like GET /wmts?service=WMTS&request=GetTile&version=1.0.0&layer=basemap&style=default&format=image/png&tilematrixset=GoogleMapsCompatible&tilematrix=10&tilerow=327&tilecol=586. This is the most traditional and universal binding — works with any HTTP client, easy to log, transparent to proxies. The downside is long URLs, which can frustrate CDN caching at providers with query-string-length limits.

RESTful binding. The URL template is defined by the server and published in the Capabilities document via a <ResourceURL> element. Typical pattern: /wmts/basemap/default/GoogleMapsCompatible/{TileMatrix}/{TileRow}/{TileCol}.png — looks like XYZ but with explicit TileMatrixSet in the path. This binding is preferred for production: short URLs, trivial CDN caching, friendly to browser SDKs like OpenLayers and Leaflet.

SOAP binding. XML envelope with POST request. Technically part of the spec, in practice found only in legacy enterprise integrations and OGC CITE certification tests — real-world 2026 deployments don't use it.

Capabilities document. The root XML, usually at GET /wmts?service=WMTS&request=GetCapabilities. This is the central WMTS artifact — it lists all layers, supported formats (image/png, image/jpeg, image/webp), full TileMatrixSet definitions (CRS, scale denominators, top-left corner, tile size, matrix width × height), ResourceURL templates, optional dimensions (time, elevation, band), and identification metadata. A client must first fetch Capabilities, parse it, and only then build tile requests. A real BKG basemap.de Capabilities is about 1.2 MB of XML; IGN France with several dozen layers — up to 5 MB.

TileMatrixSet. The key concept of the standard. This is a formal pyramid definition: CRS (EPSG code), top-left corner in CRS coordinates, sequence of TileMatrix entries each with a unique identifier, scale denominator, tile size in pixels (typically 256×256), and tile counts along X/Y. The spec's Annex E describes several standard TileMatrixSets: GoogleMapsCompatible (EPSG:3857 Web Mercator, identical to the Google/OSM tile scheme — the lingua franca of web maps), WorldCRS84Quad (EPSG:4326 plate carrée, two root tiles), EuropeanETRS89_LAEAQuad (EPSG:3035 for pan-European INSPIRE services), and dozens of national ones — British OSGB36 (EPSG:27700), German AdV ETRS89/UTM32, Japanese JGD2011 (EPSG:6668). Supporting multiple TileMatrixSets in one layer is a common pattern: the same map is served both in Web Mercator for web clients and in a national projection for desktop GIS.

Dimensions. An optional extension for temporal or multi-band data. The time dimension lets you request tiles for a specific date/time (&time=2024-06-15) — used for weather radar, satellite imagery time series, cadastral snapshots. Elevation — for atmospheric and oceanographic data. Band dimension — for multispectral satellite layers. In practice dimensions are used in specialized services (NASA GIBS — daily MODIS imagery); for basemaps they are always absent.

Use cases: INSPIRE, government open data, enterprise basemaps

EU INSPIRE View Services. The primary use case in Europe. Directive 2007/2/EC requires every EU member state to publish spatial data through standardized services — discovery (CSW), view (WMS/WMTS), download (WFS/WCS), transformation (WPS). For basemaps and orthophoto, practically all national mapping agencies chose WMTS for scalability. Germany — BKG basemap.de and dop20 orthophoto via WMTS; France — IGN Plan IGN, Scan 25, BD ORTHO via WMTS; Italy — Geoportale Nazionale with thousands of WMTS layers; Netherlands — PDOK with dozens of WMTS at data.pdok.nl; Spain — IGN Spain WMTS at idee.es. These services are free, without API key, with reasonable limits (tens of thousands of requests/hour from one IP), and available under open licenses.

United States government data. USGS publishes the national topographic map via WMTS at basemap.nationalmap.gov/arcgis/rest/services/USGSTopo/MapServer/WMTS, imagery via basemap.nationalmap.gov/.../USGSImageryOnly/MapServer/WMTS. NASA GIBS (Global Imagery Browse Services) provides daily satellite imagery from MODIS, VIIRS, Landsat via WMTS with time dimension — one of the most prominent examples of dimension-feature use in production. NOAA, USDA, FEMA have their own WMTS endpoints for specialized layers.

Government open data in Asia and Oceania. GSI Japan (Geospatial Information Authority of Japan) provides the most comprehensive Japanese basemap via WMTS at cyberjapandata.gsi.go.jp — relief, ortho, historical maps, hazard maps. LINZ New Zealand, Land Information Singapore, Geoscience Australia — all use WMTS for public data distribution. China NASG restricts WMTS access through API keys and geofencing, but technically uses the same standard.

Enterprise and industry basemaps. Esri ArcGIS Online publishes its premium basemaps (World Imagery, World Topographic Map) through a WMTS endpoint for non-Esri clients. Maxar, Airbus Intelligence, Planet Labs provide access to commercial satellite imagery via WMTS with auth headers. Microsoft Bing Maps technically supports a WMTS-like endpoint, though prefers its own quadkey convention. Mapbox and MapTiler — predominantly XYZ, but occasionally publish a WMTS façade for enterprise customers.

Browser SDK basemap layers. OpenLayers — native WMTS support via the ol/source/WMTS source class with auto-discovery through Capabilities. Leaflet — through the leaflet.wmts plugin or vanilla L.TileLayer with manual TileMatrixSet wiring. MapLibre GL JS / Mapbox GL JS — no native WMTS support (they render vector tiles from MVT), but WMTS can be wired through a raster source with a RESTful URL template. QGIS desktop — excellent native support with a GUI for browsing Capabilities and previewing layers.

Map generation of London city center

Software and tools: GeoServer, MapServer, MapProxy, ArcGIS

GeoServer (Java). The most popular open-source OGC server. Supports WMTS through the integrated GeoWebCache extension — meaning one GeoServer can simultaneously serve WMS (on-demand), WMTS (cached), WFS, WCS from a single admin UI. GeoWebCache stores tiles either in the filesystem, in S3/Azure Blob, or in SQLite/MBTiles, supports seed (mass pre-generation), truncate (selective invalidation), and custom TileMatrixSet definitions. A GeoServer + GeoWebCache production deployment is the standard architecture for INSPIRE national portals.

MapServer (C). The oldest open-source OGC server (UMN, ~1996), still relevant for high-performance use cases. WMTS support through the MapCache extension (a separate C project). MapServer + MapCache is renowned for low memory footprint and high throughput — typically 5-10x faster than GeoServer on the same hardware for tile serving, but less user-friendly in admin (mapfile configuration vs web UI). The USGS National Map runs on a MapServer stack.

MapProxy (Python). Not a rendering server — it's a WMTS façade and tile-caching layer on top of existing WMS/WMTS/TMS sources. Use case: you have a slow WMS server (say, an organization's ArcGIS Server with peak-load issues), you put MapProxy in front of it, and it automatically caches tile requests, optionally performs on-the-fly reprojection between CRSs, aggregates multiple sources into a single WMTS endpoint. Also used as a proxy for commercial sources with API keys — MapProxy hides credentials and rate-limits requests. Configuration is YAML. Actively maintained by Omniscale.

ArcGIS Server (Esri). Native WMTS support via a REST endpoint of the form /arcgis/rest/services/{folder}/{service}/MapServer/WMTS. ESRI publishes a WMTS endpoint automatically when you create a Map Service with pre-generated cache. Enterprise feature, Esri license.

QGIS Server (Python/Qt). Open-source alternative to GeoServer with better integration with QGIS desktop styling. WMTS support is built-in. Uses the QGIS rendering engine, providing pixel-identity between desktop preview and server output — a big plus for cartographic workflows.

MapCache (standalone, C). A separate C project for tile caching/seeding, installable as Apache module or FastCGI. Often combined with MapServer.

Client libraries. GeoTools (Java) and GDAL (the WMTS driver reads Capabilities and treats the source as a multi-layer raster) — server side. For web: OpenLayers (best-in-class WMTS support), Leaflet (through plugin), MapLibre (through raster source with manual URL template), Cesium (for 3D globe rendering).

WMTS vs XYZ vs TileJSON vs WMS

WMTS lives in an ecological niche with several related technologies, and the choice between them locks in your architecture for years.

  • WMTS — formal OGC standard with Capabilities document, explicit TileMatrixSets (multi-CRS support), dimensions, multiple bindings. Strengths: discoverability, OGC compliance, enterprise/government adoption, multi-CRS out of the box. Weaknesses: verbose Capabilities XML, overhead for simple web use cases, perceived complexity. Choose for: government portals, INSPIRE compliance, enterprise GIS, multi-CRS basemaps.

  • XYZ tiles — simple URL convention /{z}/{x}/{y}.png without formal spec. Strengths: triviality, native support in all web map libraries, clean CDN-friendly. Weaknesses: no metadata discovery, effectively only EPSG:3857 (Web Mercator) hard-coded in clients, ad-hoc convention without validation. Choose for: web basemaps, simple deployments, mobile apps.

  • TileJSON — Mapbox-proposed JSON spec for metadata of XYZ-style tile sources. Strengths: lightweight alternative to WMTS Capabilities, web-friendly format, supports attribution / bounds / minzoom / maxzoom / vector tiles. Weaknesses: only Web Mercator, no dimensions, not OGC. Choose for: web-native stacks (Mapbox/MapLibre), vector-tile workflows.

  • WMS — older OGC standard (1999), dynamic on-demand rendering for arbitrary bbox/width/height. Strengths: arbitrary bbox/size (not tied to a tile grid), parametric styling via SLD, GetFeatureInfo for interactive query. Weaknesses: doesn't scale (each request is render compute), poor CDN cacheability, variable latency. Choose for: situations needing dynamic styling or GetFeatureInfo; otherwise WMTS.

  • MBTiles / PMTiles — single-file archive formats for tile bundles. WMTS-orthogonal: your WMTS server can store tiles in an MBTiles/PMTiles file as the backend and serve them through a WMTS endpoint. Strengths: portable, offline-friendly. Weaknesses: requires a server for production delivery (PMTiles can be served via range requests from a CDN).

For government / enterprise / multi-CRS / INSPIRE workflow — WMTS. For web-only basemaps — XYZ or TileJSON. For on-demand parametric rendering — WMS. For file-based bundle distribution — MBTiles / PMTiles.

Strengths and weaknesses

Strengths. Formal OGC specification — stability, predictability, vendor-neutral, foundation for compliance / audit / federation. Multi-CRS out of the box via TileMatrixSets — a single endpoint can serve Web Mercator for web and a national projection for desktop GIS simultaneously. Pre-rendered tiles — linear scaling under load, trivial CDN caching, predictable per-request latency. Capabilities discovery — a client can automatically discover all layers, formats, TileMatrixSets without out-of-band documentation. Dimensions — support for temporal/elevation/multi-band layers. Industrial adoption — all major OGC servers (GeoServer, MapServer, QGIS Server, ArcGIS) support WMTS natively. INSPIRE-ready — formal compliance path for EU member states.

Weaknesses. Verbose Capabilities XML — typically 1-5 MB on a realistic deployment, parsing overhead, fragile to namespace handling in some clients. Not web-native — modern web stacks (Mapbox/MapLibre, React-Leaflet) prefer XYZ + TileJSON; WMTS-only deployment requires glue code. Perceived complexity — newcomers are intimidated by TileMatrixSet abstractions vs the triviality of XYZ. KVP binding URLs are long — interferes with CDN cache key normalization. Limited vector-tile support in practice — the spec theoretically allows PBF via ResourceURL, but 99% of deployments are raster (for vector tiles industry uses OGC API — Tiles or the Mapbox Vector Tiles spec directly). Multiple bindings — theoretically a feature, in practice a source of confusion (KVP vs RESTful — which to use?). SOAP binding — dead.

OSM2CDR integration: pre-rendered pyramid → WMTS-ready bundle

Our wmts_exporter.py accepts an OSM bbox and parameters (min/max zoom, TileMatrixSet, format image/png or image/jpeg or image/webp) and generates a complete WMTS-ready bundle — a directory with tiles on the RESTful convention plus a ready Capabilities XML, deployable to any static hosting for immediate use as a WMTS endpoint.

Step 1: Load OSM and render. Through local_osm_loader.py we fetch PostGIS WKB for the bbox with the chosen style (default OSM Carto, or one of 20 built-in osm2cdr styles). For each zoom level in the specified range (typically 8-16) we generate a tile matrix via QGIS headless rendering. Tiles are written to the filesystem in the structure {TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}.png — exact match to the WMTS RESTful URL template, giving zero-config compatibility.

Step 2: TileMatrixSet selection. By default we use GoogleMapsCompatible (EPSG:3857, Annex E standard) — the lingua franca for compatibility with OpenLayers, Leaflet, MapLibre, QGIS, ArcGIS clients. For EU/INSPIRE deployments we optionally generate EuropeanETRS89_LAEAQuad (EPSG:3035). Custom TileMatrixSet definitions for national projections — available on request for enterprise customers.

Step 3: Capabilities XML generation. We generate a valid WMTSCapabilities.xml (OGC 07-057r7 schema-compliant) with populated metadata: ServiceIdentification (title, abstract, keywords), ServiceProvider (osm2cdr.ru contact info by default, customizable), Contents with one Layer entry containing the chosen style, supported formats, used TileMatrixSetLinks with TileMatrixSetLimits (exact ranges of TileRow/TileCol for the bbox — preventing clients from requesting out-of-bounds tiles). The ResourceURL element points to the RESTful template. A complete Capabilities is usually 5-15 KB for a single-layer export.

Step 4: Optional ZIP packaging. By default the output is a directory tree. Optionally we package everything into a ZIP archive for download — inside is WMTSCapabilities.xml plus the tile pyramid. ZIP size for an average-city bbox (10×10 km) at zooms 8-16 is typically 50-500 MB depending on style complexity and format (PNG larger than JPEG larger than WebP).

Step 5: Deployment guide. The bundle deploys to any static hosting: AWS S3 + CloudFront (static website + CDN caching), Cloudflare R2 + Workers, Nginx with a simple try_files config, GitHub Pages for prototyping, Netlify/Vercel. The only requirement is the server must serve .xml with the proper application/xml Content-Type and support CORS if WMTS will be consumed from another origin (Access-Control-Allow-Origin: * for public, restricted origin for private). No backend, no database, no compute — this is static WMTS, radically reducing hosting costs vs traditional GeoServer deployment.

What is NOT generated automatically. Live updating tile pyramid — our export captures an OSM snapshot at generation time, doesn't subscribe to minutely updates. Multiple styles in one bundle — each style requires a separate export run. Dimensions (time/elevation) — not applicable for a static OSM bbox. KVP binding — we only generate RESTful, since for static hosting KVP makes no sense (no server-side request processing). Authentication — bundle is public by default; for access control use the hosting platform (CloudFront signed URLs, Nginx basic auth, etc.).

Recommended workflow. Use osm2cdr WMTS export for: prototyping and testing WMTS-consuming applications without deploying GeoServer; running offline workshops needing a basemap without internet; creating an archived OSM snapshot for a specific date with the ability for reuse; embedding into AWS/Cloudflare workflow where you want to avoid managed GIS infrastructure costs.

Map generation of Tokyo city center

FAQ

What's the difference between WMTS and WMS? WMS (1999) — dynamic on-demand rendering: client requests an image for an arbitrary bbox/width/height, server renders on the fly and returns it. WMTS (2010) — pre-rendered tiles on a fixed grid: the server has pre-cut a tile pyramid per TileMatrixSet, client requests a specific tile by (matrix, row, col). WMTS scales linearly (static file serving + CDN), WMS doesn't (each request is compute). WMTS is faster, cheaper, simpler, but doesn't support arbitrary bbox or dynamic styling. Modern best practice: WMTS for basemaps, WMS for interactive thematic layers needing GetFeatureInfo or client-controlled styling.

Can I use WMTS as a vector tile source? Technically yes — the ResourceURL can reference application/vnd.mapbox-vector-tile (PBF) or JSON. In practice, 99% of production WMTS is raster. For vector tiles industry uses either OGC API — Tiles (a new REST/JSON-based standard) or the Mapbox Vector Tile spec directly via XYZ-style URLs. WMTS as a vector tile source is rare and usually causes interop issues.

WMTS vs XYZ tiles — which to choose? XYZ — for web-native deployments needing maximum simplicity and performance, no OGC compliance requirement, and Web Mercator is sufficient. WMTS — for government/enterprise/INSPIRE workflow requiring formal OGC compliance, multi-CRS support, Capabilities discovery for federated catalogs. Web Mercator basemap for a tourism app — XYZ. National mapping agency portal — WMTS.

Is WMTS supported in MapLibre GL JS / Mapbox GL JS? Natively — no, these libraries are built around vector-tile rendering. Workaround: wire WMTS through a raster source with a RESTful URL template — this works but requires manual extraction of parameters from Capabilities. For seamless WMTS support in a modern web stack use OpenLayers (native WMTS class) or Leaflet (via leaflet.wmts plugin). Cesium supports WMTS for 3D globe rendering.

Can WMTS be hosted on static hosting without a backend? Yes, and it's a popular architecture. The WMTS RESTful binding is just HTTP GET with a predictable URL pattern (/path/{Matrix}/{Row}/{Col}.png plus one .xml for Capabilities). Any static hosting (S3 + CloudFront, Cloudflare R2, Nginx, GitHub Pages) serves it. Our osm2cdr wmts_exporter is for exactly this workflow. Caveat: KVP binding doesn't work on static hosting (it needs server-side request parsing), but RESTful works perfectly.

How do I validate WMTS deployment correctness? Through OGC TEAM Engine (CITE — Compliance & Interoperability Testing Engine) — official OGC validator at cite.opengeospatial.org. Submit the URL of your Capabilities endpoint, the validator checks compliance with OGC 07-057r7 schemas, presence of mandatory elements, correctness of TileMatrixSet definitions, accessibility of declared tiles. Alternative tools: QGIS desktop (just add a layer via WMTS connection — if it works, basic compatibility is there), MapProxy mapproxy-util check, GDAL gdalinfo "WMTS:https://...?service=WMTS&request=GetCapabilities".

Conclusion

WMTS is a formal OGC standard that won the enterprise and government GIS niche not through technical innovation (XYZ tiling is simpler) but through formality, Capabilities discovery, and multi-CRS support — all critical for federated geospatial infrastructure. EU INSPIRE Directive de-facto made WMTS a mandatory part of national geo-strategies in 27 countries; USGS, IGN, BKG, OS, GSI maintain petabytes of tiles via this standard. Its strength is predictability, scalability through pre-rendering, multi-CRS support, OGC compliance path. Its weakness is verbose Capabilities, perceived complexity vs the triviality of XYZ, and weak integration with modern web-native vector stacks (Mapbox/MapLibre).

On osm2cdr.ru we provide /api/render with format wmts — the bundle contains a pre-rendered tile pyramid from OSM PostGIS plus a ready Capabilities XML, deployable to any static hosting (S3, Cloudflare R2, Nginx) without the need to spin up GeoServer. This is the right choice when you need a WMTS endpoint for prototyping, offline workshops, an archived OSM snapshot, or a CDN-deployed basemap without managed GIS infrastructure costs.

Try the OSM-to-WMTS export for your city and deploy the bundle to S3 or Cloudflare R2 — in 10 minutes you'll have a fully OGC-compliant WMTS endpoint with zero recurring compute cost.

Sources

Related articles

XYZ Tiles — Slippy Map: URL schema for tile-based maps in web and mobileMBTiles — SQLite Tile Container for Offline Map Apps (Mapbox)PMTiles — Single-File Cloud Tile Archive for Serverless Maps (Protomaps)TileJSON — JSON tileset metadata: descriptor for modern web cartography
← All articles