Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What extensions should OAPI Coverages have? #15

Closed
pebau opened this issue Apr 26, 2019 · 9 comments
Closed

What extensions should OAPI Coverages have? #15

pebau opened this issue Apr 26, 2019 · 9 comments
Assignees

Comments

@pebau
Copy link
Contributor

pebau commented Apr 26, 2019

In addition to the Core functionality, at some time a wider range of operations should be supported, such as further subsetting, scaling, etc. Here a first attempt:

  • Range subsetting (also known as band subsetting, variable extraction)
  • Scaling (change of grid resolution while keeping the space/time extent)
  • CRS transformation (space, time, and possibly other dimension types!) +
  • Transaction (insert, update, and deletion of coverages)
  • Interpolation (whenever interpolation is involved in the request on hand, the method indicated shall be applied)
  • Processing (WCPS queries for extraction, filtering, aggrgation, analytics, etc.)

Items marked with a "+" are of relevance beyond coverage world and might be discussed in a wider context.

@Schpidi
Copy link
Member

Schpidi commented Apr 26, 2019

Teleconference 20190426: How will this extend to application profiles?

@pebau
Copy link
Contributor Author

pebau commented Apr 26, 2019

WCS knows about 2 types of extensions:

  • enhancing an existing request type, like GetCoverage, with further parameters to enhance and/or finetune behavior
  • add new request types altogether (such as insert coverage)

@phersh2
Copy link

phersh2 commented Apr 26, 2019

We'll have to figure out how all this applies to Application Profiles to WCS (MetOcean and EO), as well as the two type of extensions: 1) to GetCoverage and 2) extensions that include new extraction patterns (which includes the extension to the MetOcean Application Profile in the GetCorridor and GetPolygon functions)

@pebau
Copy link
Contributor Author

pebau commented Apr 26, 2019

we might also consider extensions for the various encodings, such as:

  • XML, JSOB, RDF, ...
  • GeoTIFF, NetCDF, GRIB2, ...
    Note that standards exist for many formats, explaining how a coverage should be represented in that format.

@Schpidi Schpidi added this to Hackathon in Core release Jun 17, 2019
@Schpidi Schpidi added this to Backlog in Core release Nov 27, 2019
@cmheazel
Copy link
Contributor

The current version (12/30/19) has the following conformance classes:

  • core
  • subset
  • HTML
  • JSON
  • OAS30
    There is also a discussion of content negotiation and requirements for the default mime-types.
    I have not included a conformance class for all possible formats due to the large number of possibilities.

@pebau
Copy link
Contributor Author

pebau commented Jan 2, 2020

FWIW, WCS is structured into format encodings, processing functionality, and protocol bindings.

@pebau
Copy link
Contributor Author

pebau commented Jan 7, 2020

Have created a branch extensions with some stub contents: https://github.com/opengeospatial/ogc_api_coverages/tree/extensions/extensions, hopefully helps in discussion.

@Schpidi Schpidi removed the Hackathon label May 20, 2020
@Schpidi Schpidi removed this from Backlog in Core release May 20, 2020
@Schpidi
Copy link
Member

Schpidi commented May 20, 2020

In the WCS SWG Teleconference @cmheazel volunteered to make sure the core/extension structures like directories, Readme, etc. are aligned between common, features, and coverages.

@cmheazel
Copy link
Contributor

OBE - the process for managing extensions has matured since this issue was written.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants