Closed ghobona closed 2 years ago
I will try to test some server and client implementations of OGC API records:
Work on a first implementation of OGC API - Coverages in GeoServer.
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: https://github.com/opengeospatial/ogcapi-coverages/issues/103 & https://github.com/opengeospatial/ogcapi-coverages/issues/105).
On my side, as part of various Geopython projects as time permits:
IMO clarifying the OARec and STAC relationship and any resulting changes to the OARec specification are critical path. cc @pvretano @cholmes
I will work on pygeoapi and try to implement a processes api server for an open data cube instance.
i'm wrapping up https://github.com/geopython/pygeoapi/pull/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
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.
Server and client implementations of OGC API - Processes
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.
On Day 2 and 3, I will set up a maven and TestNG project for the Executable Test Suite (ETS) of OGC API - Coverages.
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.
@pvretano we should also consider how this ISO19115 extension fits in with Common, e.g. https://github.com/opengeospatial/ogcapi-common/issues/69#issuecomment-864623592 (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).
@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
@ByronCinNZ it is basically a documentation exercise.
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.
@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
On my side: touching pygeoapi for starting an early implementation for the OAProc workflows extension
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
Post a comment letting us know what you are going to be working on.