Hubbry Logo
Tile Map ServiceTile Map ServiceMain
Open search
Tile Map Service
Community hub
Tile Map Service
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Tile Map Service
Tile Map Service
Tile Map Service
View on Wikipedia
from Wikipedia
TMS
Developed byOSGeo
Initial release2006[1]
Type of formatContainer format
Container forXML, JPEG, PNG
Open format?Yes: GNU LGPL

Tile Map Service or TMS, is a specification for tiled web maps, developed by the Open Source Geospatial Foundation. The definition generally requires a URI structure which attempts to fulfill REST principles. The TMS protocol fills a gap between the very simple standard used by OpenStreetMap and the complexity of the Web Map Service standard, providing simple urls to tiles while also supporting alternate spatial referencing system.

Support

[edit]

TMS is most widely supported by web mapping clients and servers; although there is some desktop support, the Web Map Service protocol is more widespread for enterprise mapping applications. The OpenLayers JavaScript library supports TMS natively, while the Google Maps API allows URL templating, which makes support possible for developers. TileCache is one of the most popular supporting servers, while other servers like mod tile and TileLite focus on the de facto OpenStreetMap standard.

WMTS

[edit]

TMS served as the basis for the OpenGIS Web Map Tile Service OGC standard. [2]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Tile Map Service

View on Grokipedia
from Grokipedia
A Tile Map Service (TMS) is a lightweight protocol for serving cartographic maps of geo-referenced data as pre-rendered image tiles organized in multi-resolution pyramids, accessed via simple HTTP requests without direct data manipulation. It enables efficient delivery of scalable map visuals for web and desktop applications by standardizing tile requests and server metadata descriptions. Developed collaboratively by the open-source geospatial community under the (OSGeo), the TMS 1.0 specification emerged in the mid-2000s as a community-driven effort to simplify map tiling, distinct from more formal standards like the Open Geospatial Consortium's (WMTS). First documented around 2007, it remains at version 1.0 with no official updates planned, though implementations continue to support it for its RESTful simplicity and compatibility with caching mechanisms defined in HTTP standards. Notable adopters include early tools and various GIS software libraries, highlighting its role in fostering accessible, tiled mapping before widespread use of XYZ tile schemes. Technically, TMS organizes maps into tilesets grouped by spatial reference systems (SRS) and zoom levels, where each tile is a 256x256 pixel image in formats such as JPEG or PNG, requested via predictable URLs like http://example.com/tms/1.0.0/layer/z/x/y.ext. It supports three profiles for coordinate handling: global-geodetic (using EPSG:4326 with units-per-pixel scaling as 0.703125 / 2^z), global-mercator (OSGEO:41001 with 78271.516 / 2^z), and local (arbitrary SRS with 2^z scaling), allowing flexibility for worldwide or regional projections. Servers describe capabilities through XML documents listing available layers, bounding boxes, and origins, while clients handle tiling math for rendering; error responses follow HTTP conventions, such as 404 for missing tiles. This structure promotes interoperability in geospatial web services, though it lacks advanced features like dynamic styling found in successors.

Introduction

Definition

Tile Map Service (TMS) is an open specification developed by the OSGeo community for serving georeferenced map tiles over the web via a simple HTTP-based protocol. It standardizes how clients request cartographic maps composed of pre-rendered image tiles and how servers describe their available tile holdings, providing access to visual representations of geospatial data rather than the raw data itself. In the TMS framework, web maps are structured as tiled representations, where the entire map is divided into small, square image tiles arranged in a multi-resolution across various zoom levels. This pyramid organization allows for efficient rendering by enabling clients to fetch only the necessary tiles for a given view, supporting scalable display from global overviews to detailed local views while minimizing data transfer and enabling caching. The core operation of TMS involves clients issuing HTTP requests for individual tiles using predefined URL patterns, to which the server responds with the corresponding image files, commonly in or formats for compatibility and compression. Servers may also provide metadata in XML format describing the tile sets, including their spatial extent, resolution, and format, ensuring across diverse mapping applications and tools.

Purpose and Benefits

The Tile Map Service (TMS) primarily enables the scalable and cacheable delivery of map imagery in interactive web applications by dividing maps into pre-generated, fixed-size image tiles organized in a multi-resolution structure. This approach allows servers to serve only the specific tiles needed for a user's view, significantly reducing bandwidth usage and server load compared to rendering entire maps on demand. Key benefits include faster rendering times, as clients can quickly load and display small, standardized tiles—typically 256x256 pixels—leading to smoother zooming and panning experiences in web-based mapping interfaces. Additionally, TMS aligns with RESTful principles through simple HTTP GET requests, promoting ease of implementation and among clients and servers without requiring complex session management. Caching mechanisms, supported by HTTP headers such as Cache-Control, further enhance performance by allowing tiles to be stored at client, proxy, or ISP levels, minimizing repeated requests for static base layers that update infrequently. In practice, TMS is widely used in applications resembling , where dynamic, on-the-fly generation of large-scale maps would be inefficient due to high computational demands; instead, pre-rendered tiles support real-time interaction for global or regional datasets like vector maps or . Unlike non-tiled services that generate complete images per request—resulting in higher latency and resource intensity for frequent user interactions—TMS addresses these limitations by leveraging tile-based caching to deliver responsive, high-volume map services efficiently.

History

Origins and Development

The Tile Map Service (TMS) specification emerged in 2006 within the (OSGeo) community, driven by the increasing demand for efficient, scalable solutions as online mapping gained popularity. Developers sought a simple protocol for serving pre-rendered map tiles in multi-resolution image pyramids, addressing limitations in existing systems like the (WMS) for dynamic, high-performance client-server interactions. This effort responded to the rapid growth of web-based geographic applications, where tiled maps enabled faster rendering and smoother user experiences compared to on-the-fly image generation. Key contributors included OSGeo members such as Paul Ramsey of Refractions Research, Paul Spencer, and Chris Schmidt, who collaborated through informal channels like the OSGeo Tiling mailing list. Their work drew inspiration from early tiled mapping projects, notably OpenStreetMap's slippy map implementation and Google's tiled web maps, which demonstrated the practicality of RESTful tile requests over HTTP. These influences shaped TMS's focus on straightforward, cache-friendly tile access without requiring complex query parameters. The initial version 1.0 of the TMS specification was released in late 2006 as a community document on the OSGeo Wiki, standardizing tile requests via simple URI patterns and server capabilities descriptions in or . Development occurred from March to November 2006, involving testing and iteration among OSGeo participants, but proceeded as a loose, wiki-based without formal involvement from the Open Geospatial Consortium (OGC). This approach emphasized RESTful simplicity, prioritizing ease of implementation for open-source tools over rigid standardization processes.

Influence on Standardization

The Tile Map Service (TMS), introduced by the (OSGeo) in 2006, served as a foundational model for the Open Geospatial Consortium's (OGC) (WMTS) standard, particularly in establishing a RESTful approach to delivering pre-rendered map tiles over the web. TMS's simple, HTTP-based protocol for accessing tiles via standardized coordinates influenced WMTS by providing a lightweight, cache-efficient framework that addressed limitations in earlier services like (WMS), which generated maps dynamically on demand. This RESTful tile delivery model in TMS emphasized direct access to fixed tiles, reducing server load and enabling faster client-side rendering, elements that were directly incorporated into WMTS to support scalable geospatial data distribution. A key milestone in this influence occurred with the OGC's adoption of WMTS 1.0.0 as a standard in late 2009, with public release in April 2010, which integrated core concepts from TMS such as tile matrix sets—hierarchical grids defining tile scales and positions—while extending them with enterprise-oriented features like Keyhole Markup Language (KML) support, SOAP bindings, and standardized service metadata for better interoperability in complex environments. WMTS retained TMS's emphasis on rectangular tiles organized in matrices but adjusted the y-axis orientation to align with WMS conventions and allowed variable tile sizes per scale, building on TMS's foundational structure to create a more robust, OGC-compliant protocol. This adoption marked a shift toward formal standardization of tiled services, with TMS's innovations enabling WMTS to become the preferred method for high-performance map delivery in professional applications. TMS's impact extended beyond WMTS to inspire non-standard variants like XYZ tiles, a common extension that flips the y-axis origin from TMS's bottom-left to top-left, facilitating compatibility with web mapping libraries such as Leaflet and for slippy maps. This adaptation, often termed "XYZ scheme" or "slippy map tiles," maintained TMS's {z}/{x}/{y} URL pattern but adjusted row numbering to start from the top, promoting widespread informal adoption in open-source communities. Additionally, TMS concepts informed the OGC's 2019 Two Dimensional Tile Matrix Set standard, which formalized tile matrix definitions for both raster and , enabling efficient indexing and metadata for modern APIs like OGC API - Tiles. As of 2025, despite WMTS's dominance in enterprise and standardized systems, TMS continues to underpin implementations in , particularly for custom or open-source mapping projects where simplicity and minimal overhead are prioritized over full OGC compliance. Its enduring relevance stems from seamless integration with RESTful web architectures and broad library support, ensuring TMS remains a practical choice for non-enterprise scenarios.

Specification

Tile Coordinate System

The Tile Map Service (TMS) employs a hierarchical coordinate system to organize and address map tiles across multiple zoom levels, with support for different spatial reference systems (SRS) via three defined profiles: global-geodetic (EPSG:4326), global-mercator (OSGEO:41001), and local (arbitrary SRS). Tiles are square images of fixed size, 256×256 pixels, forming a pyramid where each zoom level (denoted as order nn, starting from 0) refines resolution by halving the units-per-pixel value. The number of tiles depends on the profile and bounding box; for global profiles at order n=0n = 0, there are 2×2 tiles covering the Earth, increasing to approximately 2n+1×2n+12^{n+1} \times 2^{n+1} at higher orders. Tiles are identified by integer coordinates: column xx ranging from 0 to the number of columns minus 1 (increasing eastward) and row yy ranging from 0 to the number of rows minus 1 (increasing northward from the southern edge). The origin is at the lower-left corner of the tile set, ensuring efficient caching and rendering in web mapping applications. TMS uses profile-specific units-per-pixel scaling and coordinate computation. For the global-geodetic profile (EPSG:4326, plate carrée projection with ), units-per-pixel = 0.703125 / 2n2^n degrees per pixel, with origin at (-180, -90). To convert geographic coordinates ( \lat\lat in degrees, \lon\lon in degrees) to tile coordinates at order nn, where the number of tiles m=2n+1m = 2^{n+1}: x=\floor∗\lon+180360×mx = \floor*{\frac{\lon + 180}{360} \times m} y=\floor∗\lat+90180×my = \floor*{\frac{\lat + 90}{180} \times m} These linear equations map longitudes across the 360-degree range and latitudes from -90° to 90°, with coordinates clipped to the defined bounding box. For the global-mercator profile (OSGEO:41001, cylindrical projection approximating the sphere), units-per-pixel = 78271.516 / 2n2^n meters per pixel, with origin at (-20037508.34, -20037508.34) and extent to (20037508.34, 20037508.34). Conversion involves projecting to mercator coordinates first: x\proj=\lon×20037508.34180x_\proj = \lon \times \frac{20037508.34}{180} y\proj=20037508.34×ln⁡(tan⁡(π4+\lat\rad2))/πy_\proj = 20037508.34 \times \ln\left(\tan\left(\frac{\pi}{4} + \frac{\lat_\rad}{2}\right)\right) / \pi where \lat\rad=\lat×π/180\lat_\rad = \lat \times \pi / 180, and latitude clipped to approximately ±85.0511° to fit the square grid. Then, with tile scale s=256×s = 256 \times units-per-pixel and m=2n+1m = 2^{n+1}: x=\floor∗x\proj+20037508.34sx = \floor*{\frac{x_\proj + 20037508.34}{s}} y=\floor∗y\proj+20037508.34sy = \floor*{\frac{y_\proj + 20037508.34}{s}} These map projected coordinates linearly across the extent, accounting for mercator distortion. For local profiles, computation uses the SRS-specific projection relative to the defined origin and bounding box, with units-per-pixel = 2n2^n. Each tile's geographic bounds can be calculated inversely from its coordinates. For global profiles, the number of tiles m=2n+1m = 2^{n+1}. For global-geodetic: \lon_\min = \frac{x}{m} \times 360 - 180, \quad \lon_\max = \frac{x+1}{m} \times 360 - 180 \lat_\min = \frac{y}{m} \times 180 - 90, \quad \lat_\max = \frac{y+1}{m} \times 180 - 90 For global-mercator, longitude as above (replacing 360 with full extent 40075016.68 m, scaled), and latitude via inverse mercator: y_\proj_\min = \frac{y}{m} \times 40075016.68 - 20037508.34, \quad y_\proj_\max = \frac{y+1}{m} \times 40075016.68 - 20037508.34 \lat_\min = \frac{360}{\pi} \times \atantanh\left( \frac{y_\proj_\min}{20037508.34} \right), \quad \lat_\max = \frac{360}{\pi} \times \atantanh\left( \frac{y_\proj_\max}{20037508.34} \right) This yields southern (min) to northern (max) extents, with \lat_\max at the upper edge and \lat_\min at the lower, ensuring seamless tile adjacency. These bounds aid precise client rendering. For local SRS, inverse uses the projection parameters.

URI Scheme and Protocol

The Tile Map Service (TMS) employs a straightforward URI scheme for requesting map tiles via HTTP, following a RESTful architecture that simplifies access to geospatial imagery. The URI pattern for tile requests is determined by the href in the service's XML metadata, typically structured as /n/x/y.format appended to a base path like /1.0.0/layer/, where n is the order (zoom level), x the column index, and y the row index, with the origin at the lower-left corner and y values increasing upward (northward). For example, a request for a tile at order 0, column 0, row 0 in JPEG format might be /1.0.0/vmap0/0/0.jpg. This pattern allows clients to construct URLs deterministically from metadata, enabling efficient caching and rendering of map pyramids without complex query parameters. The protocol relies exclusively on HTTP GET requests to retrieve tiles directly as image responses, eschewing more elaborate mechanisms like or key-value pair (KVP) encoding found in other standards. Servers respond with the requested image data in formats such as or , using appropriate Content-Type headers (e.g., image/png). At the service root, an optional XML capabilities document may be available, often versioned as /tms/1.0.0/, which lists available tile maps and provides entry points for further discovery. This document adheres to the , facilitating service without mandating it for basic tile access. Error handling in TMS follows standard HTTP conventions, with servers returning status codes such as 404 for nonexistent tiles or resources, and 500 for internal server errors. In cases of XML responses for errors, a structured <TileMapServerError> element may include a <Message> detailing the issue, ensuring clients can gracefully handle failures. No additional error-specific protocols are defined, emphasizing the service's lightweight design. For metadata, TMS servers can expose TileMap XML documents at paths like /tms/1.0.0/tilemap, describing available layers with elements such as <Title>, <SRS> for the , <BoundingBox> defining the coverage extent (e.g., minx/miny/maxx/maxy), <Origin> (typically lower-left), and <TileSets> listing orders with attributes like units-per-pixel and order. These documents enable clients to understand the service's offerings, including supported projections, tile hierarchies, and formats, prior to issuing tile requests.

Comparison with Web Map Tile Service

Architectural Differences

The Tile Map Service (TMS) architecture prioritizes simplicity through its exclusive use of a RESTful HTTP binding, enabling direct access to pre-rendered map tiles without requiring complex negotiation. Servers optionally expose metadata via an XML document at the service root, but no formal capabilities document is mandatory, allowing lightweight implementations focused on tile retrieval through predictable URI patterns. This streamlined approach contrasts with more elaborate service-oriented architectures by avoiding mandatory discovery mechanisms, making TMS suitable for straightforward web-based mapping applications. In comparison, the Web Map Tile Service (WMTS) introduces greater structural complexity by supporting multiple bindings, including Key-Value Pair (KVP) encoding for query strings and for XML messaging, in addition to RESTful HTTP. WMTS mandates specific operations such as GetCapabilities, which returns an XML document detailing service metadata, available layers, and supported formats, and GetTile for fetching individual tiles based on those descriptions. These requirements facilitate automated and integration in heterogeneous environments, extending beyond TMS's direct-access model to include procedural and resource-oriented styles. TMS organizes tiles within pyramid schemes defined by predefined profiles, such as global-mercator (OSGEO:41001, equivalent to EPSG:3857) or global-geodetic (EPSG:4326), utilizing 256x256 squares in a hierarchical structure where each zoom level doubles the resolution, assuming consistent coverage for global profiles. This rigid setup limits customization to predefined profiles like global Mercator or geodetic. WMTS, by contrast, permits multiple tile matrix sets per layer, allowing servers to define varied projections, resolutions, and bounding boxes, alongside support for multiple styles (e.g., symbology variants) and formats (e.g., , ) within the same service, enhancing adaptability for specialized datasets. Due to its status as an (OSGeo) specification rather than an OGC standard, TMS interoperability is hampered by the absence of formal compliance testing, resulting in common variants such as the XYZ scheme, which inverts the y-axis (origin at top-left with y increasing downward, versus TMS's bottom-left origin). This divergence, often implemented in libraries like via y-flip parameters, stems from alignment with popular conventions like those of . WMTS addresses these issues through OGC-defined profiles that enforce uniform behaviors, mandatory conformance classes, and explicit support for tile matrix linkages, ensuring reliable cross-vendor compatibility in enterprise and standardized deployments.

Standardization and Adoption

The Web Map Tile Service (WMTS) was formally standardized by the (OGC) as version 1.0.0, published on April 6, 2010, under document OGC 07-057r7, representing an evolution of the earlier non-standardized Tile Map Service (TMS) by incorporating multiple encoding options (RESTful, KVP, and ) for enhanced in geospatial data delivery. This standard addressed limitations in TMS by defining a comprehensive protocol for serving pre-rendered map tiles, including detailed specifications for tile matrices, layers, and styles, while maintaining compatibility with existing tiling schemes. Subsequent refinements included the WMTS Simple Profile (version 1.0, approved in 2015), which streamlined implementations for common use cases like Web Mercator projections, and engineering reports exploring vector tile extensions, such as the 2018 WMTS Vector Tiles Extension that proposed support for formats like Vector Tiles to complement raster tiles. Adoption of WMTS has been driven by OGC's emphasis on within Spatial Data Infrastructures (SDIs), enabling seamless integration across heterogeneous geospatial systems for applications like and . Government entities have prominently implemented WMTS to support public data access; for instance, provides WMTS endpoints for national geospatial datasets, including topographic and hydrographic layers, to facilitate efficient tiled map rendering in web-based tools. As of 2025, WMTS remains a key standard for formal and regulated applications requiring standardized compliance, such as those under the European Union's INSPIRE Directive, which endorses WMTS as a high-performance option for view services to deliver tiled geospatial across member states, though newer OGC - Tiles is increasingly adopted as its successor for modern implementations. In contrast, the simpler, RESTful TMS continues to dominate open-source ecosystems, such as those powered by and libraries like Leaflet, due to its lightweight implementation without the overhead of multiple protocols. Building on concepts from both TMS and WMTS, the OGC - Tiles standard (adopted 2022) provides a contemporary framework for serving tiled data, including support for , and is seeing growing adoption in 2025 for its alignment with modern web . The OGC's Two Dimensional Tile Matrix Set and Tile Set Metadata standard (OGC 17-083r4, approved February 20, 2022) further advances this landscape by formalizing tiling schemes derived from both TMS and WMTS concepts, supporting modern like OGC - Tiles for vector and coverage data. However, WMTS's broader feature set has contributed to relatively slower uptake in informal or resource-constrained environments compared to TMS's ease of deployment, as noted in OGC interoperability initiatives.

Implementations

Server Software

Several open-source server implementations provide robust support for the Tile Map Service (TMS) protocol, enabling efficient distribution of map tiles from geospatial data sources. GeoServer, a popular Java-based server from the Open Source Geospatial Foundation (OSGeo), implements TMS via its community-developed extension, which integrates seamlessly with its core Web Map Service (WMS) capabilities while also supporting Web Map Tile Service (WMTS). This extension allows for dynamic tile rendering from vector and raster data, with built-in support for custom spatial reference systems (SRS) through GeoServer's projection handling. Additionally, GeoServer leverages GeoWebCache for tile caching, reducing server load by storing frequently requested tiles on disk or in memory. MapTiler Server offers a self-hosted solution for generating and serving both raster and using protocols like XYZ and WMTS, particularly suited for OpenStreetMap-derived data. It supports on-the-fly rendering as well as pre-generation of pyramids, which creates static sets in advance for faster access and offline use. The server handles multiple formats, including MBTiles and , and includes caching mechanisms to optimize delivery over HTTP. mod_tile, an module, is widely used for serving XYZ-format tiles in (OSM) environments, focusing on high-performance rendering and distribution. It integrates with renderd for metatile generation and employs disk-based caching to manage large-scale tile requests efficiently, making it ideal for public-facing map services. Other notable implementations include TileCache, an early Python-based server that pioneered TMS compliance with pluggable backends for rendering and caching, though it is now considered legacy and largely superseded by more modern tools. TerraLens Server, developed by Geospatial, provides optimized tile delivery via WMTS, offering dynamic caching and support for custom SRS in military and UAV contexts. For .NET platforms, the open-source Tile Map Service library delivers a lightweight TMS endpoint, supporting tile access from local files, MBTiles databases, or remote sources with basic caching. Key features across these servers include pre-generation of tiles to build complete zoom-level pyramids, which minimizes runtime computation and enables deployment without internet dependency for private maps, such as internal corporate GIS systems. Caching strategies, often multi-layered (memory, disk, or distributed), ensure scalability, while custom SRS support allows adaptation to non-standard projections like those used in regional mapping. For instance, mod_tile and MapTiler Server can be deployed on-premises to serve datasets securely, avoiding reliance on external providers. Other tools like TileServer-GL provide additional TMS support for serving vector and raster tiles. As of 2025, recent developments emphasize cloud integration, with servers like MapTiler and custom .NET implementations deployable on AWS services such as EC2 or S3 for scalable tile serving.

Client Libraries and Tools

Client libraries and tools for Tile Map Service (TMS) primarily focus on web-based implementations, which handle tile fetching, coordinate transformations, and rendering in browser environments. provides native support for TMS through its XYZ source layer, allowing developers to configure tile URLs with the standard {z}/{x}/{y} format while accommodating TMS-specific y-axis flipping via projection options. Leaflet, another popular , lacks explicit TMS support but integrates it via the L.TileLayer class with the tms: true option, which reverses the y-coordinate to match TMS conventions and ensures compatibility with standard tile schemes. In desktop and enterprise environments, clients offer robust TMS connectors. supports adding TMS layers as XYZ tiles directly through the "Add Data From Path" functionality, enabling seamless integration of custom tile services into mapping projects since version 2.6. The Maps SDK for further extends this with the WebTileLayer class, which accepts TMS templates using {level}/{col}/{row} patterns for custom raster tile sources. provides limited direct TMS support through its XYZ Tiles browser panel, where users can input custom URLs, though it often defaults to WMS for broader in enterprise workflows. Other specialized tools include GL JS, which is compatible with TMS variants for custom layers via raster sources that can be configured to handle flipped coordinates, making it suitable for advanced 3D and vector-enhanced mappings. In hydrologic applications, the Mapper serves as a dedicated client for TMS, allowing users to overlay -based backgrounds on hydraulic models for visualization and of extents and riverine data. These libraries and tools generally manage tile requests over HTTP, stitch received tiles into interactive viewports using or rendering, and implement local caching to optimize performance and reduce bandwidth. As of 2025, updates in mapping libraries have enhanced vector tile integration, with browsers like Chrome and improving native support for efficient rendering of hybrid raster-vector TMS layers through advanced APIs. Despite these advancements, desktop support for TMS lags behind web counterparts, as enterprise tools like and prioritize WMS for its metadata richness and standardization, leading to occasional workarounds for pure TMS consumption.

References

  1. https://wiki.osgeo.org/wiki/Tile_Map_Service_Specification
  2. https://www.usgs.gov/faqs/what-difference-between-tiled-and-dynamic-services
  3. https://wiki.openstreetmap.org/wiki/TMS
  4. https://2010.foss4g.org/presentations/3653.pdf
  5. https://wiki.osgeo.org/wiki/WMS_Tile_Caching
  6. https://www.microimages.com/documentation/FeatureSummaries/73-2007/73CoverMemoMam.pdf
  7. https://portal.ogc.org/files/?artifact_id=35326
  8. https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames
  9. https://www.ogc.org/standards/tms/
  10. https://gist.github.com/tmcw/4954720
  11. https://www.ogc.org/standards/wmts/
  12. https://docs.ogc.org/is/13-082r2/13-082r2.html
  13. https://openlayers.org/en/latest/apidoc/module-ol_source_XYZ-XYZ.html
  14. https://docs.ogc.org/per/18-083.html
  15. https://natural-resources.canada.ca/science-data/data-analysis/geospatial-data-tools-services/web-map-tile-service-wmts
  16. https://inspire-mif.github.io/technical-guidelines/services/view-wms/ViewServices.html
  17. https://www.ogc.org/standards/ogcapi-tiles-1
  18. https://docs.ogc.org/is/17-083r4/17-083r4.html
  19. https://www.maptiler.com/server/
  20. https://tilecache.org/
  21. https://www.kongsberggeospatial.com/products/terralens-server
  22. https://github.com/apdevelop/tile-map-service
  23. https://github.com/maptiler/tileserver-gl
  24. https://leafletjs.com/reference.html#tilelayer-tms
  25. https://community.esri.com/t5/arcgis-pro-ideas/add-xyz-tiles-layer-tms/idi-p/940481
  26. https://developers.arcgis.com/javascript/latest/api-reference/esri-layers-WebTileLayer.html
  27. https://gis.stackexchange.com/questions/280408/displaying-opening-local-tms-with-qgis
  28. https://www.hec.usace.army.mil/confluence/rasdocs/rmum/latest/tile-map-server
  29. https://maplibre.org/news/2025-10-04-maplibre-newsletter-september-2025/
  30. https://pro.arcgis.com/en/pro-app/latest/help/data/services/use-tiled-web-layers.htm
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.