Path syntax

[cmheazel]

From Swath Coverage Engineering Report

In the context of the WCS REST API design experiment, the resources are identified by paths. Each path uniquely identifies a resource. For example, the root path / identifies the entry point which returns a document containing links to other resources - i.e. specifications identified by "/api", conformance declaration (identified by "/conformance"), and list of coverages (identified by "/coverages"). The coverage description of each coverage is identified as "/coverages/{coverageId}" while the actual data of a coverage is identified as "/coverages/{coverageId}/rangeSet". The paths are unique identifiers for different resources.

[pebau]

This does not define a path, unfortunately:

• "Each path uniquely identifies a resource" so such a resource could be _path_to_some_resource or /path/to/some/resource. What is the difference, where is it described?
• What is the resource of /path/to as compared to /path/to/ and /path/to/resource?
• at last when it comes to collection there is some feeling around that /collection and /collection/a means that a is part of the collection, so we have a part-of relationship. Makes sense, this is the well-known semantics of file systems typically used underneath. This we should make clear, and use it consistently.
• The above example for coverages is massively counterintuitive:
• /coverages/id is proposed to just return a description, rather it should return the coverage.
• /coverages/id/rangeSet is proposed to return the "actual data" - what is this? The syntax suggests: only the pixels, no rangeType, no metadata, no domainSet. Hard to motivate.

[chris-little]

I think trying to define a path scheme is the wrong place to start. I would be happier with the approach of asking what are meaningful queries from a user wanting to use coverage data. E.g.
What data is available?
What other services are associated with this data (visualisation, subsetting, re-projection, processing,...)?
Are there any metadata?
What are the constraints on my use of this data?
Will the data swamp my device/connection?
What is a conformance class?
What is a rangeSet?
Etc.

[cmheazel]

@chris-little I agree in principle. Just remember that this first release is a simple core. What are the capabilities which will be needed by every OAPI-Coverages implementation? That alone should keep us busy for a couple months.

[nmtoken]

@chris-little I completely agree, in fact I might go further and suggest we already have the syntax needed from the name=value pairs.

We need to look at common requests, and I think most of what you have listed should be common,
certainly

What data is available?
What other services are associated with this data (visualisation, subsetting, re-projection, processing,...)?
Are there any metadata?
What are the constraints on my use of this data?

I would add:

What formats
What extents
What CRS (I'm not sure we should be constrained by WFS 3.0 decision to only support WGS84 lon/lat in core)
What operations (which may be the same as services?)
What protocols/methods

I like the

Will the data swamp my device/connection, but perhaps this is a secondary operation/service, based on some selection of format/extent/crs/protocol...

[pebau]

interesting discussion! All I find so far is not constrained to coverages, but is a valid question for any kind of data addressed by OGC so far. So this might constitute good input for OpenAPI Common.

-Peter

On 27.03.19 16:28, James Passmore wrote: @chris-little <https://github.com/chris-little> I completely agree, in fact I might go further and suggest we already have the syntax needed from the name=value pairs. We need to look at common requests, and I think most of what you have listed should be common, certainly What data is available? What other services are associated with this data (visualisation, subsetting, re-projection, processing,...)? Are there any metadata? What are the constraints on my use of this data? I would add: What formats What extents What CRS (I'm not sure we should be constrained by WFS 3.0 decision to only support WGS84 lon/lat in core) What operations (which may be the same as services?) What protocols/methods I like the Will the data swamp my device/connection, but perhaps this is a secondary operation/service, based on some selection of format/extent/crs/protocol... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF0ejj2nRAB48vTZxrLPsdbqOcbz3wKvks5va44agaJpZM4b_ceX>.

-- Dr. Peter Baumann - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 "A brilliant idea is a job halfdone."