Demystifing OGC APIs with GeoServer: introduction and status of implementation - FOSS4G EU 2025

The OGC APIs are a fresh take at doing geo-spatial APIs, based on WEB API concepts and modern formats, including:

- Small core with basic functionality, extra functionality provided by extensions
- OpenAPI/RESTful based
- JSON first, while still allowing to provide data in other formats
- No mandate to publish schemas for data
- Improved support for data tiles (e.g., vector tiles)
- Specialized APIs in addition to general ones (e.g., DAPA vs OGC API - Processes)
- Full blown services, building blocks, and ease of extensibility

This presentation will provide an introduction to various OGC APIs and extensions, such as Features, Styles, Maps and Tiles, STAC and CQL2 filtering. Some of specs are finalized and complete enough that they have a GeoServer supported extensions, while others are provided as community modules. Join us to find out the current state of implementation, our future steps, and how you can participate in it.

Transcript

1. OGC APIs with GeoServer: implementation, availability, and next steps Ing. Andrea Aime GeoSolutions 1
2. 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
3. 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
4. OGC API - Common elements 4
5. OGC API (OAPI) Common (visually) 5
6. 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
7. 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
8. 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
9. 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
10. GeoServer implementation, common elements 10
11. 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
12. Classic services and APIs side by side
13. Templates for HTML representations • HTML representation is controlled by templates, fully user customizable • Example, collections page, vanilla: 13
14. 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
15. OGC API - Features 15
16. 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
17. (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
18. (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
19. 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
20. 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
21. 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
22. 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
23. 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
24. OGC API - Tiles 24
25. 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
26. Tiles resource, URL templates ogc/tiles/collections/topp%3Astates/styles/population/map/tiles/ WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}?f=image%2Fpng 26
27. 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
28. OGC API - Processes 28
29. 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
30. Look ma! No collections! 30
31. Process list 31
32. Inputs, outputs, formats 32
33. 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
34. 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
35. OGC API - Coverages 35
36. OGC APIs - Coverages • The simplest WCS ever? • Collection as a single coverage • GeoServer has a partial implementation from an OGC code sprint 36
37. 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)
38. Other interesting bits (not implemented yet) • Scaling • Tiled coverages: scalable access to raw data • Scenes: enumerate, filter, describe sub-images • Looking for sponsors!
39. OGC API - Maps 39
40. 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
41. Maps API • Adds a notion of a “style”, listed in collection metadata • Adds a “map” resource 41
42. “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
43. “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
44. Other APIs 44
45. 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
46. Customization example by DLR 46
47. 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
48. 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
49. 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
50. Moving forward 50
51. 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
52. 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
53. That’s all folks! Questions? andrea.aime@geosolutionsgroup.com info@geosolutionsgroup.com 53