OGC APIs with GeoServer: implementation, availability, and next steps Ing. Andrea Aime GeoSolutions 1 

GeoSolutions Enterprise Support Services Deployment Subscription Professional Training Customized Solutions GeoNode • Offices in Italy & US, Global Clients/Team • 30+ collaborators, 25+ Engineers • Our products • Our Offer 

Affiliations We strongly support Open Source, it is in our core We participate in OGC testbeds and get funded to advance new open standards We support standards critical to GEOINT 

OGC API - Common elements 4 

OGC API (OAPI) Common (visually) 5 

OGC API (OAPI) Common • Can be found at: https://ogcapi.ogc.org/common/ • Restful, base resources (part 1, core): • / (landing page) • /conformance (which optional parts implemented) • OpenAPI definition (often at /api, linked with rel =service-desc) • For services exposing data (part 2, collections): • /collections • /collection/{collectionId} 6 

Links, links everywhere! • All resources are linked to the others: /collections /collections/{collectionId} Backlinks to self and alternative representations (different formats) Links to each collection { "href":"http://data.example.org/collections.json", "rel":"self", "type":"application/json", "title":"this document" } 7 

Resource representations • OAPI Commons recommends: ○ HTML for humans ○ JSON for machine to machine • Choosing format, many possibilities: ○ Accept header ○ Path Extension (myResource.json) ○ Custom query param (“f” is a common choice) 8 

Extensions and conformance • Tiny core, bare minimum for a working service • Modular extensions for everything else. E.g. ○ OGC API - Features - Part 1: Core ○ OGC API - Features - Part 2: Coordinate Reference System ○ OGC API - Features - Part 3: Filtering ○ OGC API - Features - Part 4: Create, Replace, Update and Delete (Draft) ○ OGC API - Features - Part 5: Schemas (Draft) ○ … property selection, geometry generalization, … • Find what is supported using conformance declaration 9 

GeoServer implementation, common elements 10 

One engine, multiple protocol layers • Each OGC API is built on top of a shared engine (found in GeoServer core) • Each service implementation parses the requests down to a common model OGC API - Features WFS 1.1 Features services engine WFS 1.0 WFS 2.0 11 

Classic services and APIs side by side 

Templates for HTML representations • HTML representation is controlled by templates, fully user customizable • Example, collections page, vanilla: 13 

Optional Custom Links • Configurable links for services and collections • Examples: license, metadata, enclosure, INSPIRE tags, human readable description of the data set or collection 14 

OGC API - Features 15 

Features API, part 1, core • Adds a notion of “items” (the features): • /collection/{collectionId}/items • /collection/{collectionId}/items/{itemId} • Only supported CRS are • CRS84 (WGS84 lon/lat) • CRS84h (WGS84 lon/lat/height) • Schema not required, features can be anything: • Simple • Complex • Heterogeneous • GeoServer implementation is CITE Compliant (part 1 and 2) 16 

(Part 1) /collection/{collectionId}/items • Lists the contents of a collection • Can be a GeoJSON document, GML, anything • Base core filtering implemented by GeoServer • bbox in CRS84 or CRS84h • datetime (instant or range of times) …/collections/buildings/states? bbox=-110,45,-100,55 &datetime=2018-02-12T23%3A20%3A52Z 17 

(Part 1) Paging • limit query parameter (first page) • A limit is always present (server default) • Paging works through links, "prev" and "next" rel values [ { "href":"http://example.org/collections/buildings/items.json?limit:50", "rel":"prev", "type":"application/geo+json" }, { "href":"http://example.org/collections/buildings/items.json?limit:50&offset:50", "rel":"self", "type":"application/geo+json" }, { "href":"http://example.org/collections/buildings/items.json?limit:50&offset:100", "rel":"next", "type":"application/geo+json" } ] 18 prev next 

Part 2 - CRS by Reference • OGC API - Features, part 2, Coordinate Reference Systems by Reference • Info about storage CRS • BBOX with CRS • Output reprojection • CRS information as a response header (does not rely on format native ability) { "crs": [ "http://www.opengis.net/def/crs/OGC/1.3/CRS84", "http://www.opengis.net/def/crs/EPSG/0/4326", "http://www.opengis.net/def/crs/EPSG/0/3857" ], "storageCrs": "http://www.opengis.net/def/crs/EPSG/0/26713" } 19 

Part 3 - Filtering ● Queryables: properties that can be used for filtering ○ May be a subset of the actual attributes ○ May not even match the attributes (e..g, like “anyText” in CSW) ● filter: the filter specification ● filter-lang: the language used ● filter-crs: the CRS for the geometries used in the filter 20 

Filtering language: CQL 2 eo:cloud_cover BETWEEN 0.1 AND 0.2 AND landsat:wrs_row=28 AND landsat:wrs_path=203 { "and": [ { "between": [ {"property": "eo:cloud_cover"}, 0.1, 0.2 ] }, { "=": [{"property": "landsat:wrs_row"},28] }, { "=": [{"property": "landsat:wrs_path"},203] } ] } &filter-lang=cql2-text &filter-lang=cql2-json 21 

Other bits implemented, but not standard ● Sort ○ Discussed in issue 157 ○ Syntax borrowed from OGC API - Records ● Query by ids ○ Gather multiple features by id ○ It’s a proposal (not yet draft standard) ● Search ○ Idea borrowed by STAC ○ Search by POST on a single collection ○ Allows ● ECQL ○ Classic “Extended CQL” by GeoServer /items?sortby=name,-dateOfBirth 22 /items?&ids=id1,id2,id3 

What’s missing? ● Some draft standard bits are not implemented ○ CRUD – single feature create/update/delete (part 4) ○ Schemas (part 5) ○ Property selection (part 6) ○ Geometry simplification (part 7) 23 

OGC API - Tiles 24 

OGC API - Tiles building block • Finalized specification https://docs.ogc.org/is/20-057/20-057.html • GeoServer: full implementation, CITE compliant (needs a test fix found in the beta engine) • Adds resources for tiles, tile matrix sets, styles 25 

Tiles resource, URL templates ogc/tiles/collections/topp%3Astates/styles/population/map/tiles/ WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}?f=image%2Fpng 26 

Tiles “metadata” resource ● Optional functionality ● Describes the tiles contents ● May return TileJSON for XYZ ecosystem (GS does)Can { "tilejson": "2.2.0", "name": "topp:states" , "description" : "This is some census data on the states." , "scheme": "xyz", "tiles": [ ".../ogc/tiles/collections/topp%3Astates/tiles/WebMercatorQuad/{z}/{y}/{x}?f=mvt ], "center": [ -89.99999997494392 , 42.525564403512014 , 1.0 ], "bounds": [-124.731422 , 24.955967, -66.969849, 49.371735 ], "format": "application/vnd.mapbox-vector-tile" , "minzoom": 0, "maxzoom": 24, "vector_layers" : [ { "id": "states", "description" : "This is some census data on the states." , "fields": { "STATE_NAME" : "string", "STATE_FIPS" : "string", "HOUSHOLD": "number" ... 27 

OGC API - Processes 28 

OGC API - Processes • Final specification available • Building block to enumerate, describe and execute processes ○ JSON based ○ Synchronous or asynchronous execution • GeoServer has a recent but complete implementation of the core spec (and a bit more!) 29 

Look ma! No collections! 30 

Process list 31 

Inputs, outputs, formats 32 

Execute! Standard POST 33 curl -XPOST -H "Content-Type: application/json" -d @buffer.json "http://localhost:8083/geoserver/ogc/processes/v1/processes/JTS:buffer/execution" { "inputs": { "geom": { "value": "POINT(0 0)", "mediaType": "application/wkt" }, "distance": 10, "capStyle": "Square" }, "outputs": { "result": { "format": { "mediaType": "application/json" } } } } { "type":"Polygon", "coordinates":[[[10,10],[10,-10],[-10,-10],[-10,10],[10,10]]] } Complex input, inline. Could be a HTTP reference too 

Easier execute! Do you GET it? 34 { "type":"Polygon", "coordinates":[[[10,10],[10,-10],[-10,-10],[-10,10],[10,10]]] } http://localhost:8083/geoserver/ogc/processes/v1/processes/JTS:buffer/execution ? geom[type]=application/wkt&geom=POINT(0%200) &distance=10 &capStyle=Square &response[f]=application/json • KVP-Encoded Execute • Optional conformance class from OGC API - Processes “next” (1.1/2.0?) • Already implemented in GeoServer • Handy for small process invocations and educational usage 

OGC API - Coverages 35 

OGC APIs - Coverages • The simplest WCS ever? • Collection as a single coverage • GeoServer has a partial implementation from an OGC code sprint 36 

Coverage extraction • Core allows to extract data from a coverage by: • bbox • datetime ...collections/nurc:Img_Sample/coverage? f=image%2Fpng& bbox=-130,20,-100,40 or &subset=Lat(20:40),Long(-90:-70) 

Other interesting bits (not implemented yet) • Scaling • Tiled coverages: scalable access to raw data • Scenes: enumerate, filter, describe sub-images • Looking for sponsors! 

OGC API - Maps 39 

OGC API - Maps • Final specification available (GeoServer implements earlier version) • Building block to produce maps, can be attached to collections, but in general, to any resource that can be mapped • E.g., could be a OGC API - process result, that has a “map” sub-resource • GeoServer implements it as a stand-alone service 40 

Maps API • Adds a notion of a “style”, listed in collection metadata • Adds a “map” resource 41 

“map” resource • Fetches a map in the requested format • Params: width, height, bbox, crs, …. • Unlike WMS GetMap, all params are optional → similar to the GeoServer WMS reflector .../ogc/maps/v1 /collections/topp:states/styles/population/map?f=image/png 42 

“info” resource (GS specific) • Not part of the standard • Still useful (considers scale deps, filters, symbology) • Feature info at given location • Params: “i/j” mandatory, others same as “map” .../ogc/maps/v1/ collections/topp:states/styles/population/map/info? f=text/plain&i=50&j=10 Results for FeatureType 'http://www.openplans.org/topp:states': -------------------------------------------- the_geom = [GEOMETRY (MultiPolygon) with 276 points] STATE_NAME = Washington STATE_FIPS = 53 SUB_REGION = Pacific STATE_ABBR = WA LAND_KM = 172447.205 WATER_KM = 12226.63 PERSONS = 4866692.0 FAMILIES = 1264934.0 HOUSHOLD = 1872431.0 MALE = 2413747.0 FEMALE = 2452945.0 WORKERS = 1830031.0 DRVALONE = 1700872.0 CARPOOL = 282240.0 PUBTRANS = 104403.0 EMPLOYED = 2293961.0 UNEMPLOY = 139216.0 -------------------------------------------- 43 

Other APIs 44 

STAC API ● Spatio Temporal Asset Catalog ● Search engine for “assets” in space and time ● Typical asset: satellite imagery ● GS implementation, compatible with OGC API - Features 45 

Customization example by DLR 46 

OGC API - Styles • Building block to describe styles for a resource • In GeoServer a stand-alone API • Implements early draft. Specification is slow moving. 47 

OGC API - Styles - example Basic metadata info (yeah, I did not fill it yet, no love lost for metadata!) Access to style source, native (CSS) and converted (SLD) when possible List of layers involved in the style (could have many) and attributes used in each (style editor can use them to check compatibility with available data) The style identifier 48 

Discrete Global Grid System APIs • Access to DGGS zones, neighbours, children, mapping to point/polygons • DAPA style aggregation API: aggregate over area, time, or both 49 

Moving forward 50 

Next steps - code • Move from community module to extension • Features is a supported extension • Tiles is almost ready • Processes is not far behind • Complete older/partial implementations • Maps • Coverages • More extensions • Features: property selection, transactions, schemas • Implement more APIs • records 51 

Next steps - users/deploys • Hopefully get more uptake/usage • Currently few deployments (research institutes) • More hybrid deployments (both classic services and OGC APIs) • More front-end support (e.g., MapStore) • Community is looking for your help to complete the work: funds or your developer time • GeoServer already has the functionality, just need to expose it through the right resources/requests 52 I WANT YOU … FOR OGC API COMPLETE SUPPORT 

That’s all folks! Questions? [email protected] [email protected] 53