Change Scope to refer to ISO19123-1 or Abstract Topic 6 instead of CIS 1.1
Closed this issue · 10 comments
In order to support a varity of encodings which are not necessarily implemented using the exact CIS 1.1 logical model.
this doesn't make sense and will not work, actually. We should respect the conceptual / logical / physical hierarchy, it has been established for good reason.
@pebau at the API level, the encoding (logical + physical) should not matter (e.g. the pygeoapi OGC API - Coverages implementation already serves CoverageJSON which does not follow the CIS logical/physical model).
The API should support a variety of encodings conforming to the conceptual model.
NOTE: We are not proposing to change the mandatory default representation of DomainSet and RangeType, which would still be required to support CIS JSON.
The /coverage (and /coverage/rangeset if available) however could follow any logical model for a coverage according to the conceptual model of upcoming ISO 19123-1.
This would allow the use of GeoTIFF, CoverageJSON, netCDF as is already common practice for OGC API - Coverages implementation.
SWG 2022-01-19: Motion to approve this change
Motion: Jerome
Second: Stephan
Discussions: We've discussed that even in WCS it is actually possible to retrieve only a GeoTIFF or netCDF response when using the specific media type rather than multipart/related, therefore this clarification is required to remove the ambiguity since neither of these formats by themselves conform to CIS.
There was no objection to unanimous consent in this meeting, but @pebau previously voiced an objection.
(2 votes / 2 active voting members in favor in this meeting)
there was an objection when I voiced my point ahead of the meeting, please consider that in counting.
And again, this proposition ignores the hierarchy conceptual - logical - physical. Encodings are physical so need to adhere to logical (CIS). And CIS (!) in turn is based on conceptual 19123-1.
Already with common sense this proposition easily can be seen as killing interoperability, but for the sake of completeness here above the architectural argument.
@pebau Updated to reflect your objection, but I don't understand your objection based on the conceptual / logical / physical hierarchy.
What we decided to do here is that OGC API - Coverages only requires conformance to the conceptual level, therefore implementations are free to support other physical (encodings) based on other logical models besides CIS. CIS JSON must still be supported for the DomainSet and RangeType.
This enables the use of CoverageJSON, GeoTIFF, and netCDF for the /coverage request, as is already common practice with OGC API - Coverages, and actually this is also already the case with WCS, as @Schpidi pointed out.
@jerstlouis in WCS, a lot of very different formats are supported by mapping them to CIS: physical based on logical model.
@pebau Could you please clarify this?
If a client negotiates a netCDF output format for a WCS request, the response from the WCS will be a physical netCDF encoding, correct?
That response will follow the netCDF physical model, and not the CIS logical model, correct?
The backend of the server could be anything, e.g. netCDF files.
So where does the CIS logical (specific classes / properties) or physical model (encodings) fit in any of this?
NOTE: There is definitely a lot of interoperability value in being able to map any particular encoding of a coverage as per ISO19123-1 to the CIS logical model (and therefore any of its physical models / encodings). But it seems to me that this mapping can be defined in a manner completely orthogonal to the service / API definition, and that the service / API definition should be agnostic of the logical or physical models (that is certainly the case in all of the OGC API specifications so far).
just recollecting points:
-
a GetCoverage request may return an incomplete coverage = not a coverage, ex: PNG. But this is not the coverage maintained by the server, and it cannot be ingested, eg, through WCS-T.
-
just to restate, CIS supports many formats and is open-ended. So any format that can represent a coverage as per CIS on principle can be used to encode a coverage.
As to this:
That response will follow the netCDF physical model, and not the CIS logical model, correct?
the response follows BOTH NetCDF model AND the CIS model, both at the same time.
another misconception: "any particular encoding of a coverage as per ISO19123-1" - 19123-1 is far from defining encodings, it is a conceptual model.
Re CoverageJSON, in all the months of discussion it has not proven to be compatible with CIS. So as it stands it is not a coverage as per CIS.
Bottom line, STRONGLY objecting to the proposal made with this ticket.
SWG 2022-04-27: As discussed last week, we will add conformance class specific to CIS JSON, as well to other encodings (e.g., netCDF, GeoTIFF, Coverages JSON). The Core conformance class however will only have a dependency on the conceptual ISO19123(-1?) / Abstract Topic, per the previous SWG motion. A separate issue will be filed to create the new encoding-specific conformance classes.
So (unfortunately) just for the records: the abstract model of 19123-1 can have different non-compatible logical models, and that means: by now, OAPI-Coverages has detached from the established coverage world, giving up interoperability and opening the door for incompatible definitions of a concrete coverage object.
PS: I will be curious about the conformance proof with 19123-1.