OGC API - Features¶
An OGC Features API publishing feature data using an OpenAPI web service.
Features Implementation status¶
Version |
Implementation status |
|
---|---|---|
Part 1: Core |
Passes compliance tests |
|
Part 2: Coordinate Systems by Reference |
Passes compliance tests |
|
Part 3: Filtering |
Implemented an earlier draft, being updated to final (no CITE tests yet) |
|
Common Query Language (CQL2) |
Implemented an earlier draft, being updated to final (no CITE tests yet) |
|
Part 4: Create, Replace, Update and Delete |
Not implemented (volunteers/sponsoring wanted) |
|
Part 5: search |
A search endpoint for complex queries is implemented at the single collection level (POST to immediately get a response, no support for stored queries). |
|
Part 6 - Schemas |
Not implemented (volunteers/sponsoring wanted) |
|
Part n: Query by IDs |
Proposal implemented, but syntax and semantic is subject to change in a future release. Thus said, usage should be carefully considered. |
|
Sorting |
Partial implementation borrowed by OGC API Records, using the sortby parameter. Sortables are not exposed. |
Installing the GeoServer OGC API Features module¶
Download the OGC API Features zip from the latest release (or nightly build) from geoserver-2.27.x-ogcapi-features-plugin.zip.
Warning
Verify that the version number in the filename corresponds to the version of GeoServer you are running (for example geoserver-2.27-SNAPSHOT-ogcapi-features-plugin.zip above).
Extract the contents of the archive into the
WEB-INF/lib
directory of the GeoServer installation.On restart the services are listed at http://localhost:8080/geoserver
Docker use of OGC API Features module¶
The nightly Docker image supports the use of OGC API Feature:
docker pull docker.osgeo.org/geoserver:2.27-SNAPSHOT
To run with OGC API Features:
docker run -it -p8080:8080 \ --env INSTALL_EXTENSIONS=true \ --env STABLE_EXTENSIONS="ogcapi-features" \ docker.osgeo.org/geoserver:2.27.x
The services are listed at http://localhost:8080/geoserver
Use of OGC API - Features service¶
The OGC API Features Service is accessed via the Features version 1.0.1 link on the home page.
Capabilities¶
The service is self described using:
html
: A collection of web pages, with links for navigation between content (and that can be indexed by search engines for discoverability).application/json: A collection of
json
documents, with reference between each document for programmatic access by web developers.{ "title": "GeoServer Features services", "description": "This services delivers vector data in raw form, including both geometries and attributes.", "links": [ { "href": "https://gs-main.geosolutionsgroup.com/geoserver/ogc/features/v1/?f=application%2Fjson", "rel": "self", "type": "application/json", "title": "This document" }, { "href": "https://gs-main.geosolutionsgroup.com/geoserver/ogc/features/v1/?f=application%2Fx-yaml", "rel": "alternate", "type": "application/x-yaml", "title": "This document as application/x-yaml" }, { "href": "https://gs-main.geosolutionsgroup.com/geoserver/ogc/features/v1/?f=text%2Fhtml", "rel": "alternate", "type": "text/html", "title": "This document as text/html" },
The service title and description are provided by the existing Web Feature Service (WFS) settings.
Open API¶
For programmatic access an OpenAPI description of the service is provided, that may be browsed as documentation, or used to generate a client to access the web services.
Collections¶
The collection of feature types being published by the service.
Each collection entry is described using the layer details of title, description, geographic extent.
Data can be browsed as web pages, or downloaded in a range of formats such as GeoJSON
and GML
documents.
Conformance¶
Lists the operations this service can perform, each “conformance class” documents supported functionality.
Contact information¶
Advertises contact information for the service.
Defined by defined in by Contact Information.
Configuration of OGC API - Features module¶
The service operates as an additional protocol for sharing vector data along side Web Feature Service.
The service is configured using:
The existing Web Feature Service (WFS) settings to define title, abstract, and output formats.
This is why the service page is titled
GeoServer Web Feature Service
by default.Feature Service conformances:
The OGC API Feature Service is modular, allowing you to enable/disable the functionality you wish to include.
By default stable Standards and Community Standards are enabled. If WFS is strict, only official Standards are enabled and community standards are disabled
The OpenAPI service description is manditory and may not be disabled.
The HTML and GeoJSON output formats are built-in and may not be disabled.
CQL2 Filter conformances.
Both the Text and JSON formats for CQL2 are available.
The built-in CQL2 functionality may not be disabled, and functionality that is not implemented yet may not be enabled.
Control of ECQL Filter conformances
Built-in templates used for html generation
Extra links can be added on a per-service or per-collection basis as indicated in Configuring the GeoServer OGC API module.
HTML Templates¶
To override an OGC API Features template:
Create a directory
ogc/features
in the location you wish to override:GEOSERVER_DATA_DIR/templates/ogc/features/v1
GEOSERVER_DATA_DIR/workspace/workspace/ogc/features/v1
GEOSERVER_DATA_DIR/workspace/workspace/datastore/ogc/features/v1
GEOSERVER_DATA_DIR/workspace/workspace/datastore/featuretype/ogc/features/v1
Create a file in this location, using the GeoServer 2.27-SNAPSHOT examples below:
The above built-in examples are for GeoServer 2.27-SNAPSHOT, please check for any changes when upgrading GeoServer.
To override a template used to list features:
Use the directory in the location you wish to override (can be general, specific to a workspace, datastore, or feature type):
GEOSERVER_DATA_DIR/templates
GEOSERVER_DATA_DIR/workspace/workspace
GEOSERVER_DATA_DIR/workspace/workspace/datastore
GEOSERVER_DATA_DIR/workspace/workspace/datastore/featuretype
Create a file in this location, using the GeoServer 2.27-SNAPSHOT examples below:
The above built-in examples are for GeoServer 2.27-SNAPSHOT, please check for any changes when upgrading GeoServer.
As an example customize how collections are listed:
The file
ogc/features/collections.ftl
lists published collection:<#global pagecrumbs> <li class='breadcrumb-item'><a href='${serviceLink("")}'>Home</a></li> <li class='breadcrumb-item active'>Collections</li> </#global> <#include "common-header.ftl"> <h1>GeoServer Feature Collections</h1> <p class="my-4"> This document lists all the collections available in the Features service.<br/> </p> <div class="row"> <#list model.collections as collection> <div class="col-xs-12 col-md-6 col-lg-4 pb-4"> <div class="card h-100"> <div class="card-header"> <h2><a href="${serviceLink("collections/${collection.id}")}">${collection.id}</a></h2> </div> <#include "collection_include.ftl"> </div> </div> </#list> </div> <script src="${resourceLink('webresources/ogcapi/features.js')}"></script> <input type="hidden" id="maxNumberOfFeaturesForPreview" value="${service.maxNumberOfFeaturesForPreview}"/> <#include "common-footer.ftl">
Save file to
GEOSERVER_DATA_DIR/workspace/templates/ogc/collections.ftl
, and rewrite as:<#include "common-header.ftl"> <h2>OGC API Feature Collections</h2> <p>List of collections published.</p> <p>See also: <#list model.getLinksExcept(null, "text/html") as link> <a href="${link.href}">${link.type}</a><#if link_has_next>, </#if></#list>.</p> <#list model.collections as collection> <h2><a href="${serviceLink("collections/${collection.id}")}">${collection.id}</a></h2> <#include "collection_include.ftl"> </#list> <#include "common-footer.ftl">
Many templates are constructed using
#include
, for examplecollection.ftl
above uses<#include "common-header.ftl">
located next tocollections.ftl
.Presently each family of templates manages its own
common-header.ftl
(as shown in the difference betweenogc/features
service templates, and getfeature templates above).A restart is not required, the system will notice when the template is updated and apply the changes automatically.
Language codes are appended for internationalization. For French create the file
GEOSERVER_DATA_DIR/workspace/workspace/ogc/collections_fr.ftl
and translate contents:<#include "common-header.ftl"> <h2>OGC API Feature Service</h2> <p>Liste des collections publiées.</p> <p>Voir également: <#list model.getLinksExcept(null, "text/html") as link> <a href="${link.href}">${link.type}</a><#if link_has_next>, </#if></#list>.</p> <#list model.collections as collection> <h2><a href="${serviceLink("collections/${collection.id}")}">${collection.id}</a></h2> <#include "collection_include.ftl"> </#list> <#include "common-footer.ftl">
For details on how to write templates see Freemarker Templates tutorial.
The following functions are specific to OGC API templates:
serviceLink(path*, format)
generates a link back to the same service. The first argument, mandatory, is the extra path after the service landing page, the second argument, optional, is the format to use for the link.genericServiceLink(path*, k1, v1, k2, v2, ....)
generates a link back to any GeoServer OGC service, with additional query parameters. The first argument, mandatory, is the extra path after the GeoServer context path (usually/geoserver
), the following arguments are key-value pairs to be added as query parameters to the link.resourceLink(path)
links to a static resource, such as a CSS file or an image. The argument is the path to the resource, relative to the GeoServer context path (usually/geoserver
).