Skip to content
Branch: master
Find file Copy path
Find file Copy path
13 contributors

Users who have contributed to this file

@cportele @pvretano @tomkralidis @bermud @sampov2 @aaime @ThomasG77 @ischneider @m-mohr @jratike80 @jampukka @elpaso @armin11
240 lines (179 sloc) 15.6 KB



This page points to servers implementing drafts of the OGC API Features series. For now this is limited to implementations of the current draft of Part 1. Core.





The following server has been set up in OGC Testbeds and Pilots. It includes extensions for other resources like vector tiles and styles:

The server has been certified as compliant by the OGC CITE tests.

Another server is implementing an older draft of part 1 (the server will be updated to version 1.0.0 soon). The APIs provide German data and therefore the language in general is German, including in the HTML.

The first endpoint is for cadastral parcels, buildings and administrative areas in North-Rhine Westphalia (Germany). The second endpoint for topographic data in that region, the third provides administrative units.

For more details about the implementation and a discussion about how this implements the Spatial Data on the Web Best Practies see the Implementation Report.

OpenAPI documents:

HTML landing pages:

The implementations are proxy services that sit on top of WFS 2.0 instances.

Here are some example requests for features using GeoJSON output (for HTML output simply change f=json to f=html, for GML to f=xml):

CubeWerx Inc.

The following server implements a good portion of the current draft part 1 standard. Just to illustrate that GML may still be used, and to contrast the interactive instruments examples, these queries will return GML rather than JSON (although GeoJSON can be returned by requesting the appropriate MIME type).

Like the interactive instruments server, this 3.0 alpha implementation is a facade sitting on top of our previous WFS 2.X implementation.

HTML landing page:

Here are some example requests for features using GML v3.2 output.


An ccomplete implementation of the Features API specification is available at At the time of writing, it supports core, HTML, GML and GeoJSON (as well as other output formats), queriables and CQL extensions.


pygeoapi implements the majority of the current draft. pygeoapi is implemented in Python, and supports JSON and HTML responses.

Example requests:

  • OpenAPI 3 document: (JSON) (HTML)
  • All feature collections: (JSON) (HTML)
  • Single feature collection: (JSON) (HTML)
  • Feature collection items: (JSON) (HTML)
  • Feature collection single item: (JSON (HTML)
  • Feature collection: bbox query: (JSON) (HTML)

The Meteorological Service of Canada uses pygeoapi in production at


jivan implements the majority of the current draft. jivan is implemented in Go, and supports JSON and HTML responses.

Example requests:


SOFP is an acronym for Simple Observation Features Project. The server carrying the same name is being developed as a part of a joint venture between Vaisala, Finnish Meteorological Institute and Spatineo. The goal is to test WFS 3.0 and a simple feature encoding for observations and measurements (

The server is implemented in TypeScript and runs in NodeJS. The architecture allows plugging in any backend or backends, also written in TypeScript. This makes it possible to integrate into existing infrastructure. The open source server includes only an example backend that serves features from a local GeoJSON file. The core server and the example backend are available on dockerhub:

SOFP focuses also on usability and browseability. Using content-negotiation, the server is easy to browse using a typical browser. The server also produces map previews of data returned by the server when data is retrieved as HTML.

Code is available on GitHub:

Finnish Meteorological Institute hosts a demo server at

Example requests:


The SpatioTemporal Asset Catalog (STAC) specification, more precisely the STAC API specification, is based on WFS 3 API. Thus STAC API is a superset of the core WFS3 API, in that WFS 3 defines many of the endpoints that STAC uses. A STAC API should be compatible and usable with WFS3 clients and a STAC server should also be a valid WFS3 server. However, WFS 3 is still under development and while STAC tries to stay in sync with WFS3 developments, there may be discrepencies prior to final versions of both specifications.


See the STAC implementations page for more implementations.


Topographical database of National Land Survey of Finland as an OGC API - Features with some 130 collections. Powered by a server called hakuna-wfs3, implemented in Java at the NLS-Finland. Currently supporting JSON/GeoJSON (and also MVT for /tiles). Pagination via primary keys, fully streaming approach.

Example requests:


SDI Rhineland-Palatinate - mapbender2

The SDIs of the three German Federal States Rhineland-Palatinate, Hesse and Saarland use the mapbender2 ows registry as backend for their geoportal solutions. In the SDIs there are registered many OpenData classified WFS 2.0 resources and it was straightforward to develop a proxy solution, that implements the OGC API - Features interface at one central location. Most of the core functions are implemented. The WFS behind the proxy are either based on mapserver or geoserver. The proxy does also create service metadata in form of iso19139 records. One extension is the usage of json-schema to define human readable attribute titles and descriptions at WFS level. The next extension will be the usage of json-ld to give semantical information for the attributes and allow the dynamical creation of rdf-a and other formats. The code of the current productional solution is available on the OSGEO GIT and OSGEO SVN.

Productive list of available Interfaces

Example requests:

Transport network (classified roads)

UNESCO world heritage of the city of Trier (point objects)

You can’t perform that action at this time.