OGC API
Please also see the official RFC for OGC API support at https://mapserver.org/development/rfc/ms-rfc-134.html
This page provides a high level overview of the emerging OGC API specifications and how they impact future development in MapServer of OGC standards.
OGC is undergoing a revolutionary effort around modernizing their API specifications to align with current technology and design patterns:
- REST
- JSON
- OpenAPI (and Swagger)
These updates also represent a clean break from the WxS specifications.
The new OGC API standards are actively being developed on the OGC GitHub along with chat capabilities on Gitter. In addition, OGC API sprints are being put forth to help develop the standards for early adopters.
The following presentation slides from pygeoapi also provide an overview of the efforts overall:
- https://pygeoapi.io/presentations/default/#/2 (arrow down)
- https://pygeoapi.io/presentations/default/#/3 (arrow down)
- https://pygeoapi.io/presentations/default/#/4 (arrow down)
The WxS specifications will continue to be supported for the forseeable future.
-
pygeoapi: OGC API - Features/Coverages (soon Records and Tiles) server
- pygeoapi is planning to support OGC API - Maps with a Python mapscript backend
- OWSLib: OGC API client
- GDAL: OGC API - Features client
-
QGIS
- OGC API - Features client
- MetaSearch: OGC API - Records client
- GeoServer: OGC API - Features/Tiles/Styles server
- Deegree: OGC API - Features server
- LDProxy: OGC API - Features server.
- others...
So what does this mean for MapServer?
- OGC OWS Common: OGC API - Common
- WMS server: OGC API - Maps
- WMS client: OGC API - Maps
- WFS server: OGC API - Features
- WFS client: OGC API - Features
- WCS server: OGC API - Coverages
- SOS server: TBD
- What about OGC API - Tiles ? MapServer or MapCache ?
- OGC API design patterns are more RESTful and less XML-RPC-ish
/ows?request=GetFeature&typename=roads&featureid=5/api/collections/roads/items/5- we would need to detect
PATH_INFO, determine the endpoint/path and dispatch accordingly
- JSON and HTML as response formats
- conformance classes (can pick and choose which functionality to support/advertise beyond 'core')
- OpenAPI capabilities
- How to properly handle the former deeply hidden "WARNING" messages in GetCapabilities response, that always cause errors downstream as almost all service admins do not remove the warning messages before publishing their services (https://github.com/MapServer/MapServer/issues/6170)
| Functionality | WFS1/2 | OAFeat | Notes |
|---|---|---|---|
| landing page | na | / | |
| conformance | GetCapabilities | /conformance | |
| layer listings | GetCapabilities | /collections | |
| single layer listing | na | /collections/{collectionId} | |
| layer description | DescribeFeatureType | /collections/{collectionId}/queryables | |
| layer query | GetFeature | /collections/{collectionId}/items | |
| layer query by id | GetFeature | /collections/{collectionId}/items/{itemId} |
| Keyword/Metadata | Level | OAFeat | OAFeat Attribute | Notes |
|---|---|---|---|---|
| wfs_title | web | / | title | |
| wfs_description | web | / | description | |
| NAME | layer | /collections | collection->id | |
| NAME | layer | /collections/{collectionId} | id | |
| wfs_title | layer | /collections | collection->title | |
| wfs_title | layer | /collections/{collectionId} | title | |
| wfs_description | layer | /collections | collection->description | |
| wfs_description | layer | /collections/{collectionId} | description | |
| wfs_extent | layer | /collections | collection->extent->spatial->bbox | Extent is derived otherwise. |
| wfs_extent | layer | /collections/{collectionId} | extent->spatial->bbox | Extent is derived otherwise. |
| layer | /collections | collection->extent->temporal->interval | ||
| layer | /collections/{collectionId} | extent->temporal->interval |
