Save 37% off PRO during our Black Friday Sale! »

Demystifing OGC APIs with GeoServer: introduction and status of implementation

Demystifing OGC APIs with GeoServer: introduction and status of implementation

Join this presentation for an introduction to OGC API Features, Styles, Maps and Tiles (and more!), the state of their development, their extensions, as well as how well the GeoServer implementation is tracking them.

Bac74c17d65c22d0ae63915251f7750f?s=128

Simone Giannecchini
PRO

October 04, 2021
Tweet

Transcript

  1. Demystifing OGC APIs with GeoServer: introduction and status of implementation

    Ing. Andrea Aime GeoSolutions
  2. GeoSolutions • Offices in Italy & US, clients Worldwide •

    30+ collaborators, 25+ Engineers • Our products • Our Offer Enterprise Support Services Deployment Subscription Professional Training Customized Solutions GeoNode
  3. 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
  4. A bit of history

  5. At the beginning, there was WFS3 • First commit July

    31st 2017 • Developed in the repo for a bunch of months • A bunch of events shaped it • Commits history in the WFS_FES repository: WFS3 Hackaton Testbed 14 Vector Tiles Pilot Testbed 15 API Hackaton
  6. WFS3 hackaton, 6-7 March 2018 • Two intense days on

    WFS3 • Discussion • Implementation of WFS3 prototypes in various languages • GeoServer implementation: • First exposure to WFS3 • Remote participation, implemented a WFS3 community module for GeoServer • https://github.com/geoserver/geoserver/tree/2.19.x/s rc/community/wfs3
  7. Testbed 14 – March/December 2018 • GeoSolutions participates to Testbed

    14, Compliance Testing Thread • Complete implementation of WFS3 according to draft spec • Parallel implementation of CITE tests by Lat Lon • https://github.com/opengeospatial/ets-wfs30 • GeoServer WFS3 successfully passed the CITE tests Teamengine WFS3 Tests GeoServer WFS3 LD-Proxy WFS3 Cubewerx WFS3
  8. Vector tiles pilot – End of 2018 • GeoSolutions participates

    to the Vector Tiles Pilot • Prototyped in the WFS3 community module two extensions • Deliver vector data as tiles (MapBox Vector Tiles) • Publis the style source for client to render maps client side (SLD, GeoCSS, Mapbox) SLD interpreted client side to render vector tiles
  9. API Hackaton, London 2018 • The same Web API approach

    as WFS3 is extended to other APIs, as well as having a shared core API Commons Features Coverages Maps & Tiles Processes Catalogs Styles More!
  10. Periodic OGC API Sprints • Since then OGC organized periodic

    code sprints • Each sprint focuses on 2-3 specs and: ◦ Push forward specification drafts ◦ Implement and gather feedback ◦ Test interoperability • GeoSolutions participates to push GeoServer API implementations forwards
  11. OGC API - Common elements

  12. 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
  13. 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
  14. 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" }
  15. 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)
  16. Extensions and conformance • Tiny core, bare minimum for a

    working service • Modular extensions for everything else • Find what is supported using conformance declaration
  17. Most still in motion • Most APIs are still in

    draft stage and changing: • Released: ◦ OGC API - Features - Core (Sept 2019) ◦ OGC API - Features - Coordinate Reference Systems by Reference (Oct 2020)
  18. Features API Core

  19. Features API Core • In addition to OAPI core: •

    /collection/{collectionId}/items (features) • /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)
  20. OpenAPI definition • Two commons approaches • Uniform collections, all

    collections are described by a /collections/{collectionId} path • Distinct collections, each is given a separate path in the OpenAPI document
  21. Uniform collections • Simpler • Scales to thousands of collections

    easily • Limited: cannot say anything unique to each collection • GeoServer currently implements this approach
  22. Distinct collections • Verbose • Suitable for small number of

    collections • Can provide query params unique about a collection, (e.g. simple filtering)
  23. /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
  24. Paging • limit query parameter • A limit is always

    present (like in WFS 1.x and 2.x) but can be high • Paging works through links, "prev" and "next" rel values • Links can be implemented the way you want • GeoServer uses offset as an extra paging parameter [ { "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" } ]
  25. CORE: that’s all folks! • Yes ladies and gentlement, this

    is everything OGC API - Features - CORE covers
  26. Wait wait wait…. • Look that's nice, but what about….

  27. Coordinate Reference Systems by Reference • Support CRS other than

    CRS84 • Discover: ◦ Storage (native) CRS ◦ Supported target CRS • Parameters: ◦ bbox-crs (query) ◦ crs (reproject) • Finalized! • GeoServer currently (09/2021) implements older draft
  28. Filtering (draft) • Queryables: properties that can be used for

    filtering • filter/filter-lang/filter-crs, multiple query languages supported • First draft used CQL (supported by GeoServer). Public feedback asked for changes. • Current draft developing CQL2 (similar, yet not same)
  29. CQL2 encodings (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
  30. CRUD transactions in draft • Create/Replace/Update/Delete for single feature •

    Currently in early draft • Not supported by GeoServer as of 2021/09 .../collections/topp:states/items/states.1 POST PUT DELETE PATCH
  31. OGC Features API GeoServer HTML representations

  32. Features API landing page

  33. Features API /api

  34. Collections /collections

  35. Collection /collections/{collectionId}

  36. Items /collections/{collectionId}/items

  37. Coverages

  38. OGC APIs - Coverages • The simplest WCS ever? •

    Collection as a single coverage • GeoServer implementation is currently incomplete
  39. Coverage and its components • DomainSet: spatial and temporal domain

    description • RangeType: data structure (bands and types) • RangeSet: the actual pixel values • Metadata: any other info about the coverage DomainSet + RangeType + RangeSet + Metadata = ----------- Coverage Coverage Implementation Schema (JSON encoding)
  40. 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
  41. Missing bits • The GeoServer implementation lacks the following: •

    RangeSet resource → describes bands • Range subsetting → band selection • Scaling scale-size/scale-factor/scale-axes • Coverage tiles
  42. Maps

  43. Maps API • Draft available at https://github.com/opengeospatial/ogcapi-maps • Adds a

    notion of a “style”, listed in collection metadata • Adds a “maps” and optionally “info” resources GeoServer implementation is currently incomplete
  44. “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/collections/topp:states/styles/population/map?f=image/png
  45. “info” resource • Feature info at given location • Params:

    “i/j” mandatory, others same as “map” .../ogc/maps/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 SERVICE = 637487.0 MANUAL = 302635.0 P_MALE = 0.496 P_FEMALE = 0.504 SAMP_POP = 736744.0 --------------------------------------------
  46. Tiles

  47. Tiles API • Available at https://github.com/opengeospatial/ogcapi-tiles • Still evolving rapidly,

    GeoServer implementation not 100% up to date • Adds resources for tiles, tile matrix sets, eventually styles • Tiles can be “map” or “data” tiles (vector/raster tiles)
  48. 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, we'll tile it
  49. Tiles resource, URL templates ogc/tiles/collections/topp%3Astates/styles/population/map/tiles/ WebMercatorQuad/{tileMatrix}/{tileRow}/{tileCol}?f=image%2Fpng

  50. Tiles “metadata” resource • Extension provided by some implementations •

    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" ...
  51. Styles

  52. Styles API • An API without "collections" (look ma, no

    data!) • In addition to OAPI core:
  53. Style transformation • If the server supports it, fetch a

    style in various encodings (GeoServer can do CSS 🡪 SLD, MBStyle 🡪 SLD, YSLD 🡪🡪 SLD) A stylesheet can be marked as “native” SLD 1.0 core SLD 1.1 core YSLD extension MBStyles community GeoCSS extension SLD 1.0 inspired object model, with extensions
  54. Style metadata 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
  55. Styles API client • "Visual style editor" as developed by

    GeoSolutions in Testbed 15
  56. And more

  57. And more of APIS! • More APIS supported by GeoServer:

    • STAC API • DGGS/DAPA (Data Access and Processing API) • Images (mosaic management) • More APIs NOT supported by GeoServer yet: • Records (CSW) • Processes (WPS) • Routes (WPS specific for routing) • Environmental Data Retrieval
  58. That’s all folks! Questions? info@geo-solutions.it