Skip to content
Branch: master
Go to file


Failed to load latest commit information.
Latest commit message
Commit time


This GitHub repository contains the new revision of the OGC's Web Map Service for requesting maps of geospatial information on the web. It is a complete rewrite of previous versions, focusing on a simple RESTful core specified as reusable OpenAPI components.

This is the CURRENT working version of this initiative (Old version work has been moved to the deliverables in Testbed-15 that contain the LAST VERSION of the materials. See:

IMPORTANT: Many examples of OpenAPI documents that are used as inspiration and test of this work is here:

The OGC API - Maps and the OGC API - Tiles are deaply related and should be considered together.


After a while getting familiar and playing with the OpenAPI definition files (explained just below in the "Examples section"), we have finally started to write the standard. We have decided an aggressive path to modularization having 2 cores, one for tiles and another for maps that can be combined as needed. Several extension for tiles and maps will emerge in the process.

The standard is written using asciidoc using many files that might be dificult to trace. Please see the standard document as a long HTML page EASY TO READ FORMAT here:


We have received several recomendations to separate the specifications into a core and some extensions. In March 2020 we decided to reestructure the GitHub repository to separate the core and the extensions in different documents that might be elaborated at different speads.

At this moment in time we are working on doing this separation by moving files around.


The definition of the maps core is the immediate next step that will be done here: clause_8_map_core.

The maps core would be something that allows to create a map that cannot be necessarily retrievable (yet). The reason: We need to support /maps/{styleID}/tiles/…

  • It has no resolution ** No parameters related with width, height, bbox, crs… etc.
  • Actually, it is map that can only be retrieved by extending it to (one of): ** a tile ** a map+resolution
  • It will not have styles (because this forces a dependency to the styles API that I would like to avoid): {styleID}=“default”.


We foresee the following extensions (some of them can end into OGC standards and some might not). None of them has been started yet.

  • StyleIds (Pending. In collaboration with the styles API. The only one necessary for the delta updates use cases)
  • Map+resolution
  • Info
  • Collections (more than one)
  • Collections-info
  • Maps with styles on the fly (involving collections)


WARNING: This section need to be updated.

Until mid July 2019, the work was focused on providing OpenAPI services description examples and domains (libraries). Now we believe this work is finalized, but each time that we take a look we still find gaps, mistakes and things that can be improved. We expect that during the effort of extracting the knowledge accumulated (hopefully) in these files to create the standard, we will keep fixing, perfecting and evolving things.

IMPORTANT NOTE: We are now using the Swagger HUB again and should be considered the "gold copy". The Swagger account is:

The material in the standards folder takes precedence to the text of the standard and the Swagger HUB takes precedence to the material in GitHub. The standards folder examples are intended to be identical to the Swagger HUB ones except for the path names. To go from Swagger HUB to GitHub do the following substitutions:

The files in the standards folder are structured in several parts that can be combined together.

Diagram of the examples and domains

A OGC API maps and tiles OPF FULL example in Swagger or in GitHub that contains full example of server with some features and coverages that are served as maps and/or tiles.

The latter is normally too long to be analyzed. The following are easier to understand.




IMPORTANT NOTE: The description in this can be older than the one in the standard draft. In case of discrepancy the standard draft takes precedence.


A "OGC API - Maps" is a standard API that provides maps representing geospatial data.

GET /.../.../map/{styleId}

The identifier of the "layer" is replaced by "{collectionId}" or "coverage"...

Maps can be requested in any available CRS and can be subset by bbox width and height (and eventually other parameters such as time and elevation)

GET /.../.../map/{styleId}?crs=CRS84&bbox=160.6,-55.95,-170,-25.89&width=600&height=400

Returns a map - a representation of real-world elements at a given resolution. {styleId} is optional.

Using the standard

Those who want to just see the endpoints and responses can explore generic OpenAPI definitions in this folder (please paste one of them in the Swagger Editor):

Several implementations of the draft standard exist:

Implementations of the draft specification / demo services


Join the WMS mailing list

Most work on the specification takes place in GitHub issues, so browse there to get a good idea of what is happening, as well as past decisions.


The contributor understands that any contributions, if accepted by the OGC Membership (and eventually the ISO/TC 211), shall be incorporated into OGC and ISO/TC 211 Web Map Service and Web Map Tile Service standards documents and that all copyright and intellectual property shall be vested to the OGC.

The WMS Standards Working Group (SWG) is the group at OGC responsible for the stewardship of the standard, but is working to do as much work in public as possible.

You can’t perform that action at this time.