What is everybody going to be working on?

[ghobona]

Post a comment letting us know what you are going to be working on.

[doublebyte1]

I will try to test some server and client implementations of OGC API records:

Pygeoapi
Geonetwork
QGIS Metasearch

[aaime]

Work on a first implementation of OGC API - Coverages in GeoServer.

[jerstlouis]

We will be improving our implementation of OGC API - Processes and Coverages in GNOSIS Map Server and Cartographer (client), including interaction of the two via the Workflows extension.
In particular we will be working on a server-side coverage processor, and improve support for multiple bands.

We hope to perform Technology Integration Experiments with our client & server against other implementations of Processes, Coverages and Workflows. We are also planning to work on improving the Workflows specification, re-organizing it in separate conformance classes and updating it to reflect the finalization of OGC API - Processes - Part 1: Core.

We will also be working on improving the Coverages specifications.

Another topic of interest is discussing a Coverages extension allowing to combine discovery/OGC API - Records (e.g. to discover scenes with a maximum cloud cover using scene metadata) and/or value-based filtering (e.g. using a cloud coverage band) with data access (e.g. Coverage request), using CQL for example. This would be a very useful capability for a GeoDataCube API (related: opengeospatial/ogcapi-coverages#103 & opengeospatial/ogcapi-coverages#105).

[tomkralidis]

On my side, as part of various Geopython projects as time permits:

• OGC API - Records: help test/move forward specification and clarify relationship with STAC
• OGC API - Processes: update pygeoapi per the latest changes/updates to the specification
• OGC API - Coverages: help with YAML schemas

IMO clarifying the OARec and STAC relationship and any resulting changes to the OARec specification are critical path. cc @pvretano @cholmes

[EHJ-52n]

I will work on pygeoapi and try to implement a processes api server for an open data cube instance.

• Identify potential processes to implement: Spectral Products: Vegetation, Water, Urbanization
• add dummy process to current tb17 test deployment
• implement one of above identified processes

[pvgenuchten]

i'm wrapping up geopython/pygeoapi#725 related to multilingual support (of special interest to ogc-api-records)
i hope to work on qgis metasearch (ogc-api-records client)
Linking to WMS/WFS from a ogc-api-records record, to facilitate instant binding

[ByronCinNZ]

Keen to work on any OGCAPIR issues involving ISO19115 or DCAT.
Also, OpenSearch - ATOM support. Willing to create a simple client to test.
Do have a problem with time zones here in New Zealand. So will mostly be available either early or late.

[gardengeek99]

Server and client implementations of OGC API - Processes

[ghobona]

I'll be documenting an 'OGC API - Processes Getting Started guide for Spring.io Developers'.

The idea is to take new implementers through the stages of using Spring with openapitools-generator on OGC API - Processes. Note that the guide will use a 'profile' of the building blocks.

[ghobona]

On Day 2 and 3, I will set up a maven and TestNG project for the Executable Test Suite (ETS) of OGC API - Coverages.

[pvretano]

I would welcome one or more people working on an ISO19115 extensions since there seems to be a lot of interest in it. I think it would involve mapping the core record model into ISO19115 (which should be fairly easy) and then describing the additional elements of the ISO19115 model. @tomkralidis @kalxas worked on something so ping them for sure.

Put the work in the "proposals" directory for now. There is already a proposal for faceted searches there so you can use that as a template if you like.

[jerstlouis]

@pvretano we should also consider how this ISO19115 extension fits in with Common, e.g. opengeospatial/ogcapi-common#69 (comment) (point 4).

Collections becomes searchable with ISO 19115 fields, and ISO19115 metadata can be retrieved following a data-meta relation link (from either collection or dataset).

[ByronCinNZ]

@pvretano I can do the mappings of ISO115 to core easy enough. Not clear what clear what describing the additional elements involves. Keen to see @tomkralidis @kalxas previous work

[pvretano]

@ByronCinNZ it is basically a documentation exercise.

• STEP 1: Map as many ISO 19115 fields as you can to the core record properties (see Table 13 & Table 14)
• STEP 2: Decide which properties from ISO19115, not already mapped in STEP 1, you want to add to the record schema to enhance its information content; it can be all of them or some subset -- whatever your community needs.
• STEP 3: Decide which record encoding(s) you want to support ... for the sake of example lets say you decide GeoJSON.
• STEP 4: OGC API Records already maps the core record properties to GeoJSON here.
• STEP 5: Decide how you want the add the properties you identified in STEP 2 into a GeoJSON record/feature. This can be by adding them to the "properties" section or as top level "foreign elements" as the GeoJSON specification calls them. As long as you don't disturb the mapping from STEP 4 you are free to add them any way you like. STAC, for example, adds a top-level "assets" object to the GeoJSON record.

There are some other housekeeping steps you need to describe such as how you negotiate to the format(s) you decided to support in STEP 3. This basically means describing which MIME types or profile tokens that should be used.

And that, in broad strokes, is pretty much it...

Makes sense?

If yes, then I should probably document this process somehow in the specification.

[ByronCinNZ]

@pvretano Yes that makes sense. I can easily commit to completing step 1 today. Hopefully will get a start on step 2 through 5 in an iterative manner.

I have been doing a great deal of work with the ICSM Metadata Working Group (ANZLIC) which provides official guidance for spatial metadata across Australia and New Zealand. This I can use for guidance for additional required fields.

I would note that I will be using ISO 19115-1:2018 and not the older versions. This may be slightly at odds with @tomkralidis @kalxas previous work

[francbartoli]

On my side: touching pygeoapi for starting an early implementation for the OAProc workflows extension

[NazihFino]

On behalf of Ethar Inc & Open AR Cloud, Philip Lamb, Colin Steinmann, Nazih Fino worked to extend our web-based geospatial visualization tool to render datasets from the coverages API. Additionally, because of our participation in Testbed 17, we are especially focused on visualizing datasets that contain a time dimension, and or orientation data. We believe datasets that contain these dimensions are especially well suited to Geo Data Cubes