Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Demystifing OGC APIs with GeoServer introductio...

Demystifing OGC APIs with GeoServer introduction and status of implementation - FOSS4G 2023

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 have reached a final release, some are in draft: we will discuss their trajectory towards official status, as well as how good the GeoServer implementation is tracking them, and show examples based on the GeoServer HTML representation of the various resources.

Simone Giannecchini

December 20, 2023
Tweet

More Decks by Simone Giannecchini

Other Decks in Technology

Transcript

  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 2
  2. Affiliations We strongly support Open Source, it Is in our

    core We actively participate in OGC working groups and get funded to advance new open standards We support standards critical to GEOINT 3
  3. OGC APIs - OpenAPI • Fresh take on spatial data

    interoperability • Based on OpenAPI/RESTful concepts • Resource/representation • HTTP verbs • Small core, a basic service can be implemented in a matter of days • Extensions for every other functionality 5
  4. OGC API (OAPI) Common • Can be found at: https://github.com/opengeospatial/oapi_common

    • Resources: • / (landing page) • /conformance (conformance classes implemented) • For services exposing data: • /collections • /collection/{collectionId} • OpenAPI definition linked from landing page with rel service-desc 6
  5. Links, links everywhere! • All resources are linked to the

    others, in the various encodings: /collections /collections/{collectionId} Backlinks to self and alternative representations (different formats/encodings) Links to each collection in each of its formats { "href":"http://data.example.org/collections.json", "rel":"self", "type":"application/json", "title":"this document" } 7
  6. Resource representations • OAPI Commons recommends: ◦ HTML for humans

    and crawlers ◦ JSON for machine to machine • Choose: ◦ Accept header ◦ Custom query param (“f” is a common choice) 8
  7. Extensions and conformance • Tiny core, bare minimum for a

    working service • Modular extensions for everything else • Find what is supported using conformance declaration 9
  8. One service per API • The current GeoServer implementation has

    one separate service per API • Matches 1-1 classic OGC services • Each OGC API is built on top of the classic OGC service engine (found in GeoServer core) • An implementation of a uber-service with all blocks together is possible, but not trivial, since each service is a pluggable module in GeoServer (can be pulled away at any time) OGC API - Features WFS 1.1 Features services engine WFS 1.0 WFS 2.0 11
  9. Mimic classic OGC service • Same output formats as classic

    OGC service ◦ e.g., can extract zipped shapefile out of OGC API - Features • Similar vendor extensions ◦ e.g. can filter using Extended CQL ◦ but some vendor extensions are not yet exposed (e.g., filtering mosaic images via CQL like in WCS) • Integrate same basic functionality ◦ Authentication and authorization supported out of the box ◦ Monitoring and control-flow similarly supported 12
  10. HTML Resource representations • HTML representation is controlled by templates,

    fully user customizable • Example, collections page, vanilla: 13
  11. Customizable links • Configurable links for services and collections •

    Examples: license, metadata, enclosure, INSPIRE tags, human readable description of the data set or collection 14
  12. Features API Core • In addition to OAPI core: •

    /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 • “describeBy” can link to schema (optional) 16
  13. /collection/{collectionId}/items • Lists the contents of a collection • Can

    be a GeoJSON document, GML, anything • Filtering • bbox in CRS84 or CRS84h • datetime (instant or range of times) • extra parameters declared in the API document (only by equality, not supported by GS) …/collections/buildings/items? bbox=41,54,42,55 &datetime=2018-02-12T23%3A20%3A52Z &buildingState=good 18
  14. 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" } ] 19
  15. 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) • Compliant, CITE tests pass { "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" } 21
  16. Part 3 - Filtering (draft) • Queryables: properties that can

    be used for filtering ◦ May be a sub-set 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 • cql2-text, cql2-json • GeoServer supports also ecql-text (classic GeoServer extended CQL) 22
  17. CQL2 encodings (earlier draft) 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 23
  18. Sorting • Not part of OGC API - Features •

    Discussed in issue 157 • Syntax borrowed from OGC API - Records /items?sortby=name,-dateOfBirth 24
  19. STAC API (RC1) • Spatio Temporal Asset Catalog • Search

    engine for “assets” in space and time • Typical asset: satellite imagery • GS implementation, compatible with OGC API - Features 26
  20. GeoServer implementation structure Collection Item Granule STAC STAC Maps e.g.

    Sentinel 2 e.g. specific Sentinel 2 scene Band 12 of the scene 27
  21. OGC APIs - Coverages • The simplest WCS ever? •

    Collection as a single coverage • Partial implementation from code sprint 30
  22. Coverage extraction • Core allows to extract data from a

    coverage by: • bbox • datetime • Scaling available too but not implemented yet ...collections/nurc:Img_Sample/coverage? f=image%2Fpng& bbox=-130,20,-100,40 or &subset=Lat(20:40),Long(-90:-70) 31
  23. OGC API - Maps • Draft specification available (GeoServer implements

    earlier version) • Partial implementation from code sprint • 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 33
  24. Maps API • Adds a notion of a “style”, listed

    in collection metadata • Adds a “maps” resource 34
  25. “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 35
  26. “info” resource (GS specific) • Not part of the standard

    (used to be in a previous draft) • 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 -------------------------------------------- 36
  27. OGC API - Tiles building block • Finalized specification https://docs.ogc.org/is/20-057/20-057.html

    • Full implementation based on earlier draft • Adds resources for tiles, tile matrix sets, eventually styles 38
  28. Building block, can tile “anything” • /collections/{collectionId} 🡪 data tiles

    from single collection • /collections/{collectionId}/maps 🡪 rendered tiles from single map • /collections 🡪 raw tiles from multiple collections (list of collections as query param) • /map 🡪 tiles from multi-layer map (list of collections as query param) • /add/your/own/here 🡪 if it can be sliced, API Tiles can expose it 39
  29. Tiles “metadata” resource • Extension provided by some implementations (not

    core) • Describes the tiles contents • Can return TileJSON (GeoServer does) { "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" ... 41
  30. OGC API - Styles • Building block to describe styles

    for a resource • In GeoServer a stand-alone API • Implements early draft. Specification is slow moving. 43
  31. 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 44
  32. DGGS related APIs • Discrete Global Grid System • A

    way to describe position and accuracy as a hierarchical pyramid of cells rHealPix (equal area) H3 (equal distance) 45
  33. DGGS related APIs • Access to zones, neighbours, children, mapping

    to point/polygons • DAPA style aggregation API: aggregate over area, time, or both 46
  34. Next steps - code • Move from community module to

    extension • At least for Features • Waiting CQL2 and its implementation • Complete outdated/partial implementations • Tiles • Coverages • Maps • More extensions • Features: property selection, transactions • More APIs • processes • records 48
  35. 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) • Overall hopefully more business around it 49