Compatibility with OGC standards for APIs

[qgroom]

The OGC standards for APIs is the globally accepted standard for spatial data. To be able to dynamically include GBIF data into GIS systems and services the GBIF API should be compatible with OGC standards.
For example, this API https://www.ogc.org/standard/sensorthings/ distributes point data on devices, data, and applications.

How feasible is this?
I think implementing this would help bridge the gap between the biodiversity community and the geospatial community

I'm happy to discuss further and put you in touch with interested people, such as @grumets

[mdoering]

We had this desire in the early days of GBIF already and worked with OGC people at TDWG various times, we visited ESRI headquarters for an experimental week. But no existing implementation worked at the scale of GBIF data. I hope things have changed since then and it is simpler to expose OGC compliant services these days with billions of features. What would the exact services be that are needed? A Web Feature Service? Tiles n maps? OpenSearch? A catalogue service?

[ingosimonis]

OGC APIs have changed fundamentally from "all data at a query interface" towards Web APIs that provide custom made access to the data. The available APIs differ in response types and query options. It depends on your targets what API best qualifies. I doubt that you want to deliver "billions of features" to a customer in a single call serialized as individual features. If you can outline the use cases briefly, we could prepare for some discussion/meeting.

[MattBlissett]

I tried making an OGC WMTS description of the existing map APIs, but found QGIS and OpenLayers couldn't do much with it since they couldn't accept the search parameters.

The demo at https://labs.gbif.org/~mblissett/2022/06/wmts/experiment/4326.html can change the year with the slider, but the dataset and taxon filters don't seem to work.

The map on https://www.gbif.org/dataset/50c9509d-22c7-4a22-a47d-8c48425ef4a7 is one use case.

https://api.gbif.org/v2/map/occurrence/density/1/1/[email protected]?datasetKey=50c9509d-22c7-4a22-a47d-8c48425ef4a7&srs=EPSG%3A4326

The tiles have a single, main search parameter (datasetKey, could alternatively be taxonKey, country, networkKey, publishingOrg, publishingCountry).

Features can also be binned by hexagon bin=hex&hexPerTile=17 or square bin=square&squareSize=32.

And there are filters for year year=2000,2010 and basisOfRecord basisOfRecord=OBSERVATION&basisOfRecord=FOSSIL_SPECIMEN

---

The other API takes a long list of search parameters, used https://www.gbif.org/occurrence/map, e.g. https://www.gbif.org/occurrence/map?country=GB&taxon_key=5&year=1973,2004&license=CC0_1_0&coordinate_uncertainty_in_meters=0,77&occurrence_status=present

https://www.gbif.org/developer/maps

[ghobona]

@MattBlissett The use cases that you describe can be addressed by implementing a number of OGC API Standards.

The ability to render map tiles or vector tiles can be supported by implementing the OGC API - Tiles standard.

An example implementation of OGC API - Tiles is at https://maps.gnosis.earth/ogcapi

This OGC API - Tiles implementation is maintained by @jerstlouis

When querying data, the ability to filter data can be supported by implementing the OGC API - Features standard.

An example implementation of OGC API - Features is at https://demo.ldproxy.net/daraa

This OGC API - Features implementation is maintained by @cportele

Looking at the example URL that you have provided, you could reorganise the resources as follows to implement OGC API - Tiles:

https://api.gbif.org/v2/map/occurrence/density/50c9509d-22c7-4a22-a47d-8c48425ef4a7/tiles/WorldMercatorWGS84Quad/1/1/0?f=mvt

Alternatively, you could reorganise the resources as follows:

https://api.gbif.org/v2/map/occurrence/density/collections/50c9509d-22c7-4a22-a47d-8c48425ef4a7/map/tiles/WorldMercatorWGS84Quad/1/1/0.mvt

There is more to the OGC API - Tiles standard than the two example URLs that I have provided above. Therefore, please refer to the Standards document for a more detailed understanding of the standard.

[jerstlouis]

@ghobona To clarify the last MVT example above, the path should probably not contain /map/ before /tiles/ if it delivers Vector Tiles as the .mvt extension hints.

Also the path could simply be:

https://api.gbif.org/v2/map/occurrence/density/50c9509d-22c7-4a22-a47d-8c48425ef4a7/tiles/WorldMercatorWGS84Quad/1/1/0

and rely on HTTP content negotiation (Accept: application/vnd.mapbox-vector-tile) for selecting vector tiles.

Map tiles can separately be provided at e.g.,

https://api.gbif.org/v2/map/occurrence/density/50c9509d-22c7-4a22-a47d-8c48425ef4a7/map/tiles/WorldMercatorWGS84Quad/1/1/0 and negotiated with Accept: image/png (or with .png or ?f=png)

[ghobona]

Thanks for the correction @jerstlouis !

[doctorluz]

I think something that is valuable to keep hold of is the DOI that is created for any GBIF query - that really encourages citation of the data and reproducibility. Worth considering whether this could be built into an OGC-compliant API.