Skip to content

Latest commit

 

History

History
205 lines (151 loc) · 12.8 KB

implementations.md

File metadata and controls

205 lines (151 loc) · 12.8 KB

Implementations

Overview

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.

Implementations:

Servers:

Clients:

interactive instruments

The following are two servers implementing most of the current draft of part 1. They are using 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.

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):

Another server is from the OGC Vector Tiles Pilot and it includes extensions for vector tile and style resources:

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.

GeoServer

An incomplete implementation of the WFS3 specification is available at http://cloudsdi.geo-solutions.it/geoserver/wfs3/ It is a community module developed from scratch during the WFS 3 hackaton. At the time of writing, still misses HTML outputs, conformance call, paging links (supports random paging with startIndex), single feature outputs and attribute filtering.

pygeoapi

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 https://geo.weather.gc.ca/geomet/features

jivan

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

Example requests:

sofp

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 (https://github.com/opengeospatial/omsf-profile).

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: https://hub.docker.com/u/sofp

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 http://beta.fmi.fi/data/3/wfs/sofp

Example requests:

STAC

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.

Implementations

See the STAC implementations page for more implementations.

nls-fi

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: