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

Comparison of CoverageJSON with ISO19123 (both 2005 and draft 2022) #23

Open
chris-little opened this issue Nov 18, 2021 · 6 comments
Open
Labels
comparison work help wanted Extra attention is needed Priority 3 Nice to have

Comments

@chris-little
Copy link
Contributor

chris-little commented Nov 18, 2021

I have extracted most of the key assertions/statements from the ISO 19115:2005 (also known as OGC Abstract Topic 6) into this AsciiDoc file with view to constructing a comparison table. I envisage columns for CoverageJSON, GeoTIFF and CIS JSON.

@jerstlouis What do you think of this approach? I can also produce the assertions from the proposed revised CD19115

@jerstlouis
Copy link
Member

jerstlouis commented Nov 18, 2021

@chris-little ISO 19123-1, right?

I think that's a great start... Yesterday we had some interesting discussions and if I understood what came out of it, is that ISO 19123/AT6 is intended to be the conceptual model, while CIS is a particular implementation of it using the same logical model for all its encodings (CIS JSON/GML/RDF).

It's its other-format-coverage conformance class that confuses things a bit, especially since it explicitly allows that a coverage may be informationally incomplete. And the OGC® GML Application Schema - Coverages - GeoTIFF Coverage Encoding Profile which combines a CIS GML file that references a GeoTIFF makes things even more interesting -- I imagine in the case of your GeoTIFF column you are talking about GeoTIFF by itself. Including netCDF (there is also a CIS GML encoding for encoding for CF-netCDF) in there as well would be interesting too.

My take on all this is that if CIS is purely logical, OGC API - Coverages and other APIs should not expect to only support CIS-based encodings. A coverage is a coverage as long as it follows the conceptual model (AT6), not one specific logical model, in my opinion.

There is some on-going argumentation as to whether interoperability can only be achieved at the level of the logical model, or also at the conceptual model level, especially if transcoding back and forth at the conceptual model is a lossy operation. (also see the e-mail thread for some insight on these discussions). I think sometimes you absolutely want to avoid any information loss, sometimes a bit of information loss of a particular type is acceptable, and sometimes there is a greater tolerance to information loss, depending on the particular application domain.

@chris-little
Copy link
Contributor Author

chris-little commented Nov 18, 2021

@jerstlouis I did think of adding NetCDF, but was trying to limit the work. CoverageJSON follows the NetCDF quite closely, so I am not sure that an extra 5th column would add much insight.

I have now extracted some CD19123-1 (2021) statements, in a separate file.

Do you think there are too many ISO19123:2005 statements? I ran out of steam about page 26., and the remaining statements are about low level detail of the UML. I've skipped all the statements about grids, Thiessen Polygons etc.

We can comment meaningfully on, for example, statements about functions if the payload format explicitly stores the arguments for the functions.

I suggest we keep the branch separate for a while, while the master branch is used to fix some weaknesses in the orginal spec., hopefully not requiring any software changes. FAO @jonblower

@jerstlouis
Copy link
Member

jerstlouis commented Nov 18, 2021

CoverageJSON follows the NetCDF quite closely, so I am not sure that an extra 5th column would add much insight.

Well that is precisely the reason why I thought that would be insightful!
I don't think everyone is aware of this relationship between NetCDF and CoverageJSON.

There is the CF-netCDF 3.0 encoding using GML Coverage Application Schema, which if I understand correctly defines how to transcode CF-netCDF 3.0 into CIS GML. I imagine it is not far away from doing the opposite CIS GML -> CF-netCDF conversion.

Has that specification been considered in any of the CoverageJSON/CIS mapping efforts so far?

(Note: until I carefully read the Scope, it was not really clear to me what that specification was about from the name of the specification, and from its position as one of the "Format encoding extensions:" for WCS alongside the others where e.g. the GeoTIFF profile is rather about enhancing the information with a side GML file instead,)

This piece of that specification is particularly relevant:

6.1 GML 3.2.1 Coverage types
Since CF-netCDF dataset realizes the ISO19123:CV_DiscreteCoverage type [4], the following GML 3.2.1 coverage types are considered for the mapping (see Figure 4): GMLCOV:GridCoverage type, GMLCOV:RectifiedGridCoverage type, GMLCOV:ReferenceableGridCoverage type, or GMLCOV:MultiPointCoverage –i.e. ISO 19123:CV_DiscretePointCoverage.

The 19123-1 revision I think nuances some of that discrete vs. continuous separation of coverages as a fundamental coverage type.

In CIS 1.1, GeneralGridCoverage is introduced which is intended to replace the use of GridCoverage, RectifiedGridCoverage and ReferenceableGridCoverage. So essentially it should be possible to define in a similar way how CF-netCDF / CoverageJSON gridded coverages and multi-dimensional points correspond to CIS.

Does CoverageJSON support other types of coverages besides regular/irregular grids and multi-points?

@jonblower
Copy link
Contributor

jonblower commented Nov 19, 2021

Although CoverageJSON is somewhat "inspired by" CF-NetCDF, I think it's sufficiently different to justify a separate comparison exercise.

The CF-netCDF 3.0 encoding using GML Coverage Application Schema is useful in that it brings out a high-level mapping, but I don't think it goes into enough detail to enable someone, at a practical level, to derive a Coverage from a NetCDF dataset. I think more work would be needed to do this, and also to update to the CIS model.

Does CoverageJSON support other types of coverages besides regular/irregular grids and multi-points?

Yes. The Common CoverageJSON Domain Types Specification lists 12 types of domain (e.g. grids, trajectories, vertical profiles etc). These are not the only domain types that are possible: users can derive their own as extensions (which might one day become part of the core spec). I don't know exactly how these would map onto CIS coverage types; some of them might just be specialisations of multi-points. For example, CoverageJSON supports polygon-based domains, which are neither grids nor multi-points. A use case for this might be recording temperature statistics based on administrative regions.

@jerstlouis
Copy link
Member

For example, CoverageJSON supports polygon-based domains, which are neither grids nor multi-points.

I think this is a clear mapping to the MultiSurfaceCoverage of CIS (from 1.0 / GMLCOV).

@chris-little chris-little added comparison work help wanted Extra attention is needed labels Feb 2, 2022
@chris-little chris-little changed the title Comparison of CoverageJSON with ISO19123-1 Comparison of CoverageJSON with ISO19123:2005 Feb 17, 2022
@chris-little chris-little changed the title Comparison of CoverageJSON with ISO19123:2005 Comparison of CoverageJSON with ISO19123 (both 2005 and draft 2022) Feb 17, 2022
@chris-little
Copy link
Contributor Author

@jonblower Issues #53 and #54 could be included as tasks in this issue if there is a need and appetite for the work.

@chris-little chris-little added the Priority 3 Nice to have label Jul 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comparison work help wanted Extra attention is needed Priority 3 Nice to have
Development

No branches or pull requests

3 participants