search

opengeospatial / ogcapi-coverages

OGC API - Coverages draft specification
https://ogcapi.ogc.org/coverages
Apache License 2.0
22 stars 13 forks source link

Determine implications of OGC API - Common - Part 2 #64

Closed ghobona closed 4 years ago

ghobona commented 4 years ago

The SWG today (2020-05-27) discussed whether the development of OGC API - Common - Part 2: Collections might have implications for OGC API - Coverages. The SWG agreed to revise the document, if possible, to be consistent with OGC API - Common - Part 2: Collections.

ghobona commented 4 years ago

The SWG on 2020-05-27 agreed that @jerstlouis would review the specifications and estimate the changes needed and how long they might take to apply to the document.

@jerstlouis will report back to the SWG on 2020-06-03.

ghobona commented 4 years ago

Cc: @cmheazel @Schpidi

jerstlouis commented 4 years ago

An important on-going discussion has been happening in Common ( https://github.com/opengeospatial/oapi_common/issues/140 ), and it seems like we are finally converging towards solutions to settle the big Collections issue.

  1. Relation type So far, one important change is that the "items" relation type would not be appropriate for coverage. The exact meaning of an "items" relation type is still being discussed (e.g. whether it implies that the link follows the /items semantics of the Features API), but it seems now that the relation type would be the primary mechanism by which a client recognizes the access method provided by a link. This enables supporting more than one access method for a single collection (e.g. the same data available through SensorThings, Features and Coverage), while identifying which link provides which access method. Therefore I suggest to change this relation type from "items" to "coverage".

  2. Extensible /collections/{collectionId} resource It has also been clarified that by default, a JSON schema is extensible unless "additionalProperties" is explicitly set to false. So it would already be perfectly okay to add additional information directly at /collections/{collectionId}, and part of my suggestion was that some coverage resources which are not going to be overly lengthy could be provided as properties of the /collections/{collectionID} resource. I believe this could generally include the DomainSet, RangeType and Metadata. As the Metadata seems to be currently described as application-specific, perhaps this could be a general Common concept rather than coverage-specific (and preferably as a linked resource). For the DomainSet, it might be that non-gridded coverages require a more verbose description. In this case, perhaps it could be specified that as an alternative to fully describe the whole DomainSet, a link to a DomainSet resource could be provided instead. What is currently being returned from /coverage would nicely merge into that {collectionID} resource. The envelope could be an extra property with more complex coverage-semantics which the {collectionID}'s spatial and geospatial extent do not support describing adequately.

  3. /coverage, /coverage/description, /coverage/all and /coverage/rangeset Currently, /coverage/all is indicated as returning "everything", i.e. both the coverage description and the coverage data itself (the RangeSet). One of my concerns with this is that some formats (media types) may either:

    • not support specifying the data alone without the description (netCDF? GeoTIFF?)
    • while other RangeSet formats may not support specifying the description at all

    To keep things simple, I would suggest that:

    • /collections/{collectionId} embeds the description as properties, except when the DomainSet is too bulky in which case the domainSet property could be omitted, and a link with "rel" : "domainSet" could be included instead linking to /coverage/domainset.
    • /collections/{collectionId}/coverage returns the data (RangeSet), and if the selected media type defines a mechanism for it, the description components as well.
    • /coverage/rangeset could still optionally be supported to return only the data without the description for formats that support this.

  4. Formats recommendations Like Features and Tiles, no specific media types is mandated by Coverage. This is good, but Features and Tiles make some recommendations on specific formats that are commonly implemented. I could not find any such recommendation in the current draft specs. I would suggest including at least mentions of CIS JSON, CIS RDF, GeoTIFF, netCDF and CoverageJSON.

  5. Missing example responses None of the examples responses at https://github.com/opengeospatial/ogc_api_coverages/tree/master/standard/examples/JSON seem to have any proper content. I think the lack of proper examples is quite hindering for developers wanting to implement clients & services. Some of the examples likely require selecting a specific media type, and text-based formats are probably better suited for example responses (e.g. CIS JSON).

tomkralidis commented 4 years ago

Thanks @jerstlouis for summarizing this important issue. I have chimed in a bit on https://github.com/opengeospatial/oapi_common/issues/140 as much as I can as time permits, so thanks very much for working on this one and reporting back. Thoughts related to OACov:

jerstlouis commented 4 years ago

@tomkralidis Thanks!

Would also suggest a once over on the spec and the various JSON/OpenAPI/yaml (even renaming this repo to ogcapi-coverages for consistency with the other standards here on GitHub)

This has also been bugging me a lot. Currently there are all sorts of naming for the repos and it makes them hard to find, especially when switching between them:

It would be nice to standardize this @ghobona .

tomkralidis commented 4 years ago

Note we changed ogcapi-records at some point for the consistency.

pvretano commented 4 years ago

@jerstlouis don't forget ogcapi-records! ;)

jerstlouis commented 4 years ago

@pvretano well at least that is consistent with Features ;)

chris-little commented 4 years ago

And EDR API has not yet got a new branding (OGC API - Environmental Data Retrieval?)

jerstlouis commented 4 years ago

To summarize points 2 & 3 of the proposal:

The advantages I see from this is that while it preserves full compatibility with the CIS model, it greatly reduces the entry barrier for non-coverage experts, and facilitates a simple implementation for clients & services, including serving simple coverage data by a static server.

e.g. only two resources are required for a simple one-file gridded coverage GeoTIFF or netCDF:

(This also happens to nicely mirror Features with {collectionID} and {collectionID}/items)

jerstlouis commented 4 years ago

This ( https://github.com/opengeospatial/oapi_common/issues/140#issuecomment-637620660 ) is the comment from the big Collections discussion in Common which is stirring us towards using more specific relation types, and why I was suggesting "coverage" rather than "items" for the {collectionID}/coverage resource.

pebau commented 4 years ago

hm, I see the long and involved description, and the different handling in different branches - now I fail to see how I just can get a coverage. How would I do the equivalent of a vanilla GetCoverage, even without subsetting?

jerstlouis commented 4 years ago

@pebau {collectionID}/coverage

{collectionID}/coverage/rangeset , if available, in the case the format (media type) supports both including or omitting the description, and you want to omit the description (but this is more useful together with subsetting, to avoid the description overhead)

And {collectionID} is much the equivalent of DescribeCoverage. A coverage with a complex DomainSet requires an extra fetch of {collectionID}/coverage/domainset, linked from {collectionID}.

pebau commented 4 years ago

@tomkralidis: just a small fix concerning

+1 to recommend CoverageJSON, GeoTIFF, NetCDF as media types

CIS is the standardized JSON encoding, so first candidate. We might also add CIS's RDF, BTW. CoverageJSON is not compatible with CIS.

jerstlouis commented 4 years ago

@pebau Would you have a link to CIS JSON encoding? (Is this it: https://docs.opengeospatial.org/is/09-146r6/09-146r6.html#46 ?)

Googling for "cis json encoding", first hit is for CoverageJSON :/ ( https://www.w3.org/TR/covjson-overview/ ). I don't see any issue with adding any formats which existing/initial implementations will support.

So I would suggest we use extracts from the CIS standardized JSON encoding for the properties in {collectionID}, as well as for the optionally linked /coverage/domainset.

CIS standard JSON could also be the format of /coverage and /coverage/rangeset if a link is included identified by media type simply "application/json".

pebau commented 4 years ago

@jerstlouis:

Googling for "cis json encoding", first hit is for CoverageJSON :/ ( https://www.w3.org/TR/covjson-overview/ ).

duckduckgoin for "feature" I get a high-ranked

Sneakers, high-end apparel and accessories - Feature [Search domain feature.com] https://feature.com Feature was created as a venue where fashion, music and art could co-exist. Since then, it has been our mission to provide the highest quality in footwear, apparel and accessories that street wear and high end fashion culture have to offer.

I don't see any issue with adding any formats which existing/initial implementations will support.

If compatible, yes. And, again, IMHO there are further interesting candidates, such as RDF.

BTW, as I often have expressed I am not against having a compatible CoverageJSON encoding as a CIS encoding. It just is not there yet, whereas OGC coverage JSON is standard, compatible, and therefore makes sense as primary choice.

pebau commented 4 years ago

...just for the sake of avoiding misinterpretations: please read previous search results as tongue-in-cheek!

pebau commented 4 years ago

sorry,today is my day of delivering slicewise:

@pebau Would you have a link to CIS JSON encoding? (Is this it: https://docs.opengeospatial.org/is/09-146r6/09-146r6.html#46 ?)

yes, exactly - conformance class json-coverage. (and to give proper credit: done by Joan Maso) Examples you find in http://schemas.opengis.net/cis/1.1/json/examples/

jerstlouis commented 4 years ago

@pebau Well I always complain about the term feature, especially when used meaning vector data and unqualified as such ;) Still, it would be nice to do some SEO to improve search results on CIS JSON :)

I added CIS JSON and CIS RDF at the head of the list of formats to recommend. Even if a coverage representation is deemed "incompatible" with CIS, I think we still need to acknowledge the possibility that implementations may be supporting those formats (e.g. @tomkralidis 's implementation was one of the first for OGC API - Coverage, at the coverage & analytics code sprint, and CoverageJSON is the one encoding that he decided to implement (unless I'm mistaken and made some wrong assumptions?). Generally speaking CoverageJSON seems to be quite popular.).

If it is possible to convert between CoverageJSON and a CIS-compliant encoding, is "not compatible" really accurate?

jerstlouis commented 4 years ago

From CoverageJSON (https://www.w3.org/TR/covjson-overview/#cis):

The main points of difference are:

I think it will be necessary to accommodate people in both camps :)

pebau commented 4 years ago

@pebau Well I always complain about the term feature, especially when used meaning vector data and unqualified as such ;) Still, it would be nice to do some SEO to improve search results on CIS JSON :)

right, calls for OGC's marketing office ;-)

I added CIS JSON and CIS RDF at the head of the list of formats to recommend.

thanks, appreciated!

Even if a coverage representation is deemed "incompatible" with CIS, I think we still need to acknowledge the possibility that implementations may be supporting those formats (e.g. @tomkralidis 's implementation was one of the first for OGC API - Coverage, at the coverage & analytics code sprint, and CoverageJSON is the one encoding that he decided to implement (unless I'm mistaken and made some wrong assumptions?). Generally speaking CoverageJSON seems to be quite popular.).

well...I could bore you with a list of agencies, businesses, research centers, data providers using CIS JSON, with 2-digit Petabytes of offerings. But me engineer would rather go for the technical merits :-)

If it is possible to convert between CoverageJSON and a CIS-compliant encoding, is "not compatible" really accurate?

definitely that would change it: if both can be converted into each other in both directions without loss of information and with all the coverage types, we have a win.

FWIW, earlier we have worked with encoding writers wanting to bring in their formats into coverage world, such as NetCDF and GRIB2 and JPEG2000, helping to get this correspondence established.

pebau commented 4 years ago

@jerstlouis: thanks for sharing - interesting, so that is their view - let's inspect:

From CoverageJSON (https://www.w3.org/TR/covjson-overview/#cis):

The main points of difference are:

* CIS uses a different set of rules for gridded and non-gridded data, whereas CoverageJSON uses a single consistent set.

actually, CoverageJSON only describes grids, and even only regular grids, so a small subset of CIS JSON. (Note: a bit hard to discover as they have only JSON examples, could not find a comprehensive specification.)

* CIS allows each Coverage to have exactly one CRS, whereas CoverageJSON allows different CRSs to be applied to different sets of coordinates in the domain (e.g. one CRS for x and y, and another CRS for z).

in CIS, this CRS is the common bracket, composed from, say, EPSG for x/y, something else for z, something else for t - so same principle, but one common, coherent mechanism (information not distributed over several places.

* Version 1.1 of CIS defines a JSON encoding that uses a near-literal translation of GML structures into JSON. CoverageJSON does not use GML as its starting point.

so....? but actually it does not start from GML, but from UML,. CIS addresses (and integrates) a far larger ecosystem than CoverageJSON, not just JSON.

I think it will be necessary to accommodate people in both camps :)

so we talk politics now ;-)

jerstlouis commented 4 years ago

@pebau

Thanks for sharing your thoughts on that comparison. I will definitely need to dig into these further at some point.

so we talk politics now ;-)

No, we explicitly try to stay away from politics :) (I myself don't belong to either camps, and would be inclined to implement both in our software).

This is partly why I think the OGC API specifications do not mandate a specific media type, recognizing the different needs and preferences of different communities.

And the recommendation is just to provide a sample of commonly used coverage formats, so I think it would be a fair compromise to include both CIS JSON and CoverageJSON in there.

pebau commented 4 years ago

@jerstlouis :+1:

This is partly why I think the OGC API specifications do not mandate a specific media type, recognizing the different needs and preferences of different communities.

couldn't agree more! In the WCS.SWG we had years (literally!) of discussion on "the" default format, every incoming community brought their own and relaunched discussion. In the end we had to give up and accept that "no one size fits all".

And the recommendation is just to provide a sample of commonly used coverage formats, so I think it would be a fair compromise to include both CIS JSON and CoverageJSON in there.

As said, no objection, as soon as CoverageJSON is compatible in the sense you defined it: translating back& forth retains the coverage.

chris-little commented 4 years ago

@jerstlouis There is a CoverageJSON standardisation effort, hosted in the WCS SWG, to be started soon. The one technical change that may help compatibility with CIS is the evolution of JSON-LD from 1.0 to 1.1, so there is some work to do besides just editorially producing an OGC standard.

The WCS SWG agreed to host the work last year, rather than have a separate, format only, SWG established. It was put back on the WCS agenda a month of so ago. As you say, there are plenty of implementations, and the user community is supportive of an OGC standardisation effort. I just need to get some money and contractual stuff sorted.

There is even a moribund GitHub repo in waiting: https://github.com/opengeospatial/CoverageJSON

ghobona commented 4 years ago

All,

Those are multiple reasons to proceed with CIS as mandatory. CoverageJSON can be optional. We need to aim to complete OGC API - Coverages - Part 1: Core soon, so that it can be sent to the OAB and the Public for Comment.

jerstlouis commented 4 years ago

@ghobona In Features, no encoding is mandatory. Was there a decision to have a mandatory encoding in OGC API - Coverage? The data model behind an OGC API - Coverage can be assumed to be CIS without mandating any particular encoding.

I do see:

The OGC JSON Schema for CIS standard addresses that need by defining a JSON schema for the CIS standard. This format should be used for all JSON encodings from the {root}/collections/{coverageid}/coverage/* paths

currently in the specs.

ghobona commented 4 years ago

... and there is clause_8_media_types.adoc which says "This API-Coverages standard is built around the OGC Coverage Implementation Schema (CIS). CIS content often includes multi-dimensional coordinates and coordinate reference systems in sensor and analytic space. "

jerstlouis commented 4 years ago

@ghobona The way I read the specs right now:

This would mean (or might be interpreted in this way) that support for CIS JSON is not mandatory, but recommended (and I think that's a good thing). The fact that it mentions all JSON encodings seems in direct conflict with the ability to support additional JSON-based formats, but is not strong enough either (should rather than shall) to ensure that application/json media type implies CIS JSON.

So I would like to suggest that:

ghobona commented 4 years ago

@jerstlouis That's a reasonable proposal, in my opinion.

What do others think of the proposal?

tomkralidis commented 4 years ago

No objections here. Having no mandatory (but recommended) encoding also leaves things open to seeing which formats move forward and are most used (without having to use them).

jerstlouis commented 4 years ago

It also supports the static server use case on affordable static cloud storage, where you can simply provide extra static resources (e.g. the {collectionID} containing the coverage description etc.) in addition to your netCDF or CIS RDF files.

pebau commented 4 years ago

good discussion! If din this suggestion also very reasonable. Brief comparison of format value, for the archive:

So while NetCDF on principle could be an overall candidate, ASCII formats like XML and JSON are preferred (i) for low dimensions due to their easier Web integration (really? XML?? - well, there are libraries available these days).

Another point: ISO SQL/MDA [1], the SQL datacube extension, has JSON as default encoding.

Bottom line:I like the "should support JSON".

[1] https://www.iso.org/standard/67382.html

PS: let us just factor out the /rangeset path discussion, please, it is a separate issue.

ghobona commented 4 years ago

All, thanks for the feedback. I suggest we formalise the decision regarding Item 4 of https://github.com/opengeospatial/ogc_api_coverages/issues/64#issuecomment-637893877 with a Motion during next week's telecon.

Regarding Item 1, is there any objection to the proposal in https://github.com/opengeospatial/ogc_api_coverages/issues/64#issuecomment-638167987 to use a relation type of ogc-coverage?

@jerstlouis Regarding, https://github.com/opengeospatial/ogc_api_coverages/issues/64#issuecomment-638193236, I am drafting an OGC-NA policy regarding repo naming.

tomkralidis commented 4 years ago

+1 to ogc-coverage. I'm just wondering whether it could/should be ogc-coverage or ogc:coverage (RE: https://github.com/opengeospatial/ogcapi-features/issues/383 && cc @cportele).

cportele commented 4 years ago

@tomkralidis - I added a comment in the linked issue.

jerstlouis commented 4 years ago

@ghobona I support a motion for Item 4. To clarify, I am still suggesting that no specific media type is mandated, so an OGC API - Coverage can still be conformant without supporting CIS JSON, but a strong recommendation (should) so that CIS JSON be the first format that a service/client considers supporting (just like in Features this is GeoJSON). Also part of the recommendation is that in the context of the coverage resources, it is clearly indicated that "application/json" refers to CIS JSON (with a link to https://docs.opengeospatial.org/is/09-146r6/09-146r6.html#46), and that any other JSON encoding (e.g. CoverageJSON) must use a more specific media type (it would be good to suggest a media type for CoverageJSON).

Also I think it would be good to get back to issues 2 & 3, and if possible also move on that (separate motion) so that we can adjust the specs accordingly before the OAB review and public comments. At this week's meeting there was some amount of support and no objection raised (other than @pvretano saying he slightly prefers to avoid extending the CollectionID resource too much, but this contrasts with the views of others in Common and big discussion https://github.com/opengeospatial/oapi_common/issues/140), but @Schpidi wanted to take a closer look. I summarized the proposed changes in https://github.com/opengeospatial/ogc_api_coverages/issues/64#issuecomment-638277791

pebau commented 4 years ago

@ghobona: All fine with me, except for item 3: semantics of /coverage, /coverage/description, /coverage/all and /coverage/rangeset where I heavily disagree.

It is counter-intuitive at best to get a coverage by addressing one of its components, rangeset, although you expect to also get domainset, rangetype, metadata, enevlope, and what not.

What about having features/attributes for accessing the complete features, in comparison?

jerstlouis commented 4 years ago

@pebau maybe I did not communicate this properly...

Assuming we are talking about a CIS JSON media type distribution, which supports both including or excluding the description.

You would get the full coverage including everything at {collectionID}/coverage. You would get only the rangeset at {collectionID}/coverage/rangeset. You could get only the domainset at {collectionID}/coverage/domainset, if the server decides to do this because the domainset is complex (otherwise it can be embdded directly as a property in {collectionID}). The rangetype would also be integrated in the {collectionID} resource.

The main change is that the coverage offering is moved from {collectionID}/coverage to {collectionID}, and so {collectionID}/coverage can return what {collectionID}/coverage/all was returning. And some resources are made optional to allow for media types that do not allow to describe some of these things by themselves, while it ensures that CIS JSON description of the coverage is always available from {collectionID}.

pebau commented 4 years ago

@jerstlouis, thanks for clarifying. I was not reading carefully enough. So what you describe sounds natural to me: {collectionID}/coverage gives me the coverage, {collectionID}/coverage/{facet} gives me the corresponding coverage facet. Then of course /all is not needed any longer.

Just to be sure: coverages/rangeset gives you only a naked set (in the math sense) of pixels, no georeference, no rangetype, no linearization scheme (aka sequence rule), no metadata, right? Actually, a multi-set like { 10, 10, 40, 49, ..., 250 } .

jerstlouis commented 4 years ago

@pebau correct, but I am suggesting that /rangeset be made optional, because some mediatypes (NetCDF? GeoTIFF?) would not support such naked set.

I am also dropping /rangetype, because that is always short & sweet and would be included in a property of {collectionID}, to avoid having to perform an additional HTTP round-trip to the server to retrieve only the rangetype. For /domainset, the server has the option to either embed it as a property of {collectionID}, or link to /coverage/domainset (which is optional, if the property is present). This addresses both the cases where the domainset is simple and when it is more complex and a separate resource (which you could also subset) is justified.

Metadata would be linked from {coverageID} as a separate resource at /coverage/metadata. Could metadata be made optional?

pomakis commented 4 years ago

@pebau correct, but I am suggesting that /rangeset be made optional, because some mediatypes (NetCDF? GeoTIFF?) would not support such naked set.

Unless I'm missing something, I don't think GeoTIFF is such an example. If a client wants a GeoTIFF of a coverage, how would it make that request if not through the .../coverage/rangeset endpoint? I was under the impression that:

.../collections/myCollection/coverage/rangeset?f=geotiff

would be more or less equivalent to the following WCS request:

...?service=WCS&version=2.0.1&request=GetCoverage&coverageId=myCollection&format=image%2fgeo%2btiff

On a related note, would it be wrong to have the output of:

.../collections/myCollection/coverage/rangeset?f=json

be:

{
  "type": "RangeSetRefType",
  "fileReference": [
    ".../collections/myCollection/coverage/rangeset?f=geotiff"
  ]
}
jerstlouis commented 4 years ago

@pomakis

If a client wants a GeoTIFF of a coverage, how would it make that request

.../collections/myCollection/coverage?f=geotiff

On a related note, would it be wrong to have the output of: .../collections/myCollection/coverage/rangeset?f=json be { ... }

I would expect this to always be a naked rangeset following CIS JSON, not a reference to another format, as per the recommendations earlier clarifying that simply "JSON" encoding for those coverage objects is always CIS JSON. I am not very familiar with CIS JSON, but I am assuming that your response is not CIS JSON? Otherwise having it be a reference can make it complicated for the client to get to the actual data if it can be a reference.

If your service does not offer CIS JSON encoding (even though it is strongly recommended, it would not be required), then you could simply omit the /coverage/rangeset resource. (because the GeoTIFF media type doesn't support a raw naked rangeset).

NOTE: This issue proposes changes to the /coverage resources, in an attempt to make things simpler, clarify things that in my opinion were not clear (e.g. the CIS JSON expectations), and better support some use cases (including easily serving a simple GeoTIFF), and I am assuming that your question relates to these proposed changes, not what the draft specifications currently say.

pomakis commented 4 years ago

If a client wants a GeoTIFF of a coverage, how would it make that request

.../collections/myCollection/coverage?f=geotiff

The coverage endpoint is supposed to return the domainset, rangetype and rangeset of the coverage. Does a GeoTIFF represent all three? Section 8.3 of the draft "OGC API - Coverages - Part 1: Core" document mentions using multipart/mime or zip, etc., to bundle things together when a binary format such as GeoTIFF is in the mix. How does this factor into things? This seems to imply that a GeoTIFF is considered only the rangeset of a coverage, and that if the domainset and/or rangetype also need to be communicated, it should all be delivered bundled as a multipart/mime or zip.

In this light, if the client wants just a GeoTIFF, would it do so via:

.../collections/myCollection/coverage?f=geotiff

or:

.../collections/myCollection/coverage/rangeset?f=geotiff

pebau commented 4 years ago

@pomakis: ahem, no - the GetCoverage request returns the complete coverage, as far as it can be encoded in GeoTIFF (described in the OGC CIS GeoTIFF extension). So mileage varies with the format used, but normally cannot be broken down simply to one or the other coverage constituent. Typically it is a wild ride through the components. For example, GeoTIFF can hold the domainset coordinates, parts of rangetype (after all, the TIFF file knows the band components by name). Re CRS it knows EPSG, but not temporal CRS. And so on....

The /rangeset component was introduced to extract a particular coverage component. I opposed to this right from the beginning (so about a year now) as it just does not make sense - think of a feature collection where you would extract either coordinates or attributes, but not both.

So the most straightforward thing for a client would be your 1st suggestion, .../collections/myCollection/coverage?f=geotiff

...why should a naive user need to know what a "rangeset" is?

jerstlouis commented 4 years ago

@pomakis My opinion is that GeoTIFF is much more than the naked set of values, so it is not just a plain rangeset, and I would argue that although it may not fully describe things per the CIS model, GeoTIFF would be a common community use case.

And we need to consider that as per my suggestion, the {collectionID} (potentially together with a linked /coverage/domainset, in the case of a complex domainset) would already provide a full CIS-compliant description of the coverage.

Section 8.3 of the draft "OGC API - Coverages - Part 1: Core" document mentions using multipart/mime or zip, etc., to bundle things together when a binary format such as GeoTIFF is in the mix.

This is way too complicated and impractical and in my opinion a major barrier of entry for simple implementations.

pebau commented 4 years ago

...coverage encodings are available for different situations in life (all of which have been brought to our doors over the years :) ):

...so users are free to pick their favourite.

pebau commented 4 years ago

@pomakis:

This is way too complicated and impractical and in my opinion a major barrier of entry for simple implementations.

A simple implementation would not support it, it is in the "cage" of a separate conformance class. Some implementations iwll only want to support NetCDF, or only GeoTIFF, or...

jerstlouis commented 4 years ago

@pebau but my point is that a we want it to be simple for a server to support GeoTIFF, without having to do this multipart stuff. It's easy with my proposal, and can even be done with a static webserver: {collectionID} has the CIS JSON description {collectionID}/coverage.geotiff is the GeoTIFF coverage ("rel" : "ogc-coverage")

pebau commented 4 years ago

My opinion is that GeoTIFF is much more than the naked set of values, so it is not just a plain rangeset,

exactly, and that is why /rangeset does not solve the encoding question.

and I would argue that although it may not fully describe things per the CIS model, GeoTIFF would be a common community use case.

yes, definitely - and therefore GeoTIFF is a perfectly valid output format. Just if you want to import that again into some CIS service it does not fulfil the requirement of completeness. But normally you export TIFF because you want to feed a GIS.