Re-organize CIS into simpler Core + Extensions #21
Comments
|
This seem a good synthesis of potentialities for way forward, to serve as a base for discussion and evaluation.
Great, more work to be done on Coverage standards !
For the deprecation of CIS 1.0, let’s be careful as presently so many implementation rely on GMLCOV/CIS 1.0 and servers based on WCS 2.0.1…
Of course CIS 1.1 extends the CIS 1.0 and decouples the encoding, GML, JSON, … So the future coverage data should move towards CIS 1.1, or CIS 1.2.
About the multi-part, this is the necessary mechanism for CIS schema in order to handle binary formats in addition to GML or JSON, so IMHO there is a real interest in this mechanism in the Coverage Implementation Schema.
Just some thoughts before going to have coverage dreams
Emmanuel
|
The suggestion is not to deprecate CIS 1.0 itself, but to not include in CIS 1.2 the classes currently identified (in CIS 1.1) as being possibly deprecated in future versions, so that clients/consumers and servers/producers based on CIS 1.2 do not have to deal with those legacy classes. Current WCS could continue to use CIS 1.0 or 1.1 that still supports them, but OGC API - Coverages (and potentially future versions of WCS) could move on to CIS 1.2 without the legacy complexity.
In OGC API - Coverages, the
Negotiating The DomainSet and RangeType are usually either embedded in |
|
Good analysis and possible way forward…
My really basic contribution:
1) As I said work as to be done.. but let’s do it systematically..
2) The classification in 6 coverages level seems complete , do you agree that it should be more comprehensive
A coverage is the digital representation of some spatio-temporal phenomenon. ISO 19123<https://en.wikipedia.org/wiki/ISO_19123> provides the definition:
[a] feature that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain
3) First establishing a definition.. is this good enough or to be revised ..? happy to contribute to the discussion
4) Assuming the above is somehow correct.. we have a “digital” representation of a sp-temp phenomenon and “feature that acts as a function to return values from its range for any direct position within sp-temp domain… so range and domainset (complex standards (e.g. coverage function from GML; RangeType / DataRecord from SWE Common; transformation from SensorML) so no complex concept but the ones to be represented really ..
5) I understand the “discrete” representation of phenomena (for several historical reasons) is this still true? Considering resolutions of sensors actually available and more precise in the future ? yes they are digital data but their representation of the continuum is quite detailed..
6) From the above point, if we have to adopt a standard covjson which definition is similar to coverage but “simplify” some items.. and the process in reality is more complex we probably are missing something..
7) Sp-temp phenomena means not only 1 picture a day but also 3 measurement a second.. considering streaming ? so other encoding mpeg4- webVMT.. etc etc..and their way to represent metadata i.e. XMP or other..
Regards
Lucio Colaiacomo
|
|
Thank you @luciocola for the input.
I would say those 6 parts address a total of 4 main coverage types (all inheriting from an AbstractCoverage defined in the Core):
The 5. transformation extension applies to the GriddedCoverage types, and the 6. partitioned coverage is an extension to create a coverage out of multiple coverages of any types. As for being comprehensive, the Core + Extension allows to define additional types of coverages as new extensions if necessary. e.g., the coverage types defined in Abstract Topic 6 (which I think may be over-specified) could be addressed more specifically by new extensions (e.g. a HexagonalGridGoverage).
I actually like that simple definition, but wondering if perhaps the qualification of the domain is too specific? "within its spatial, temporal or spatiotemporal domain" -- isn't it possible to have a coverage with additional dimensions that are neither temporal nor spatial, e.g. a temperature axis?
If I understand correctly, there are two things that can be discrete in a coverage, and this is a little bit confusing (at least to me) right now in the specification:
I think what is important is to define wich coverage information from the CIS conceptual model CoverageJSON is capable of encoding, and how it does so, as I describe here.
I think coverages can be derived from spatiotemporally-referenced video streams, but that requires photogrammetry etc. Otherwise the information in the video is really not organized in a way that facilitates retrieving values for a certain direct position. A process (coverage function) can be written that generates such a coverage from a video as an input, and allows retrieving values from a spatiotemporal position, but to be efficient it probably involves preprocessing/caching behind the scene. |
|
so what's wrong with the CIS 1.1 modularization?
-Peter
…On 12.11.21 15:45, Jerome St-Louis wrote:
Thank you @luciocola <https://github.com/luciocola> for the input.
The classification in 6 coverages level seems complete , do you agree that
it should be more comprehensive
I would say those 6 parts address a total of 4 main coverage types (all
inheriting from an /AbstractCoverage/ defined in the Core):
* /GriddedCoverage/
o *RegularGridCoverage*
o *IrregularGridCoverage*
* /Discrete/ Coverages
o *MultiPointCoverage* (point cloud)
o *DiscreteMesheCoverage* (including /MultiPointCoverages/)
+ /MultiCurveCoverage/
+ /MultiSurfaceCoverage/
+ /MultiSolidCoverage/
+ Do we need a separate /MixedGeometryCoverage/?
The /4. transformation/ extension applies to the GriddedCoverage types, and
the partitioned coverage is an extension to create a coverage out of multiple
coverages of any types. As for being comprehensive, the Core + Extension
allows to define additional types of coverages as new extensions if necessary.
e.g., the coverage types defined in Abstract Topic 6 (which I think may be
over-specified) could be addressed more specifically by new extensions (e.g. a
HexagonalGridGoverage).
First establishing a definition.. is this good enough or to be revised .
I actually like that simple definition, but wondering if perhaps the
qualification of the domain is too specific? /"within its spatial, temporal or
spatiotemporal domain"/ -- isn't it possible to have a coverage with
additional dimensions that are neither temporal nor spatial, e.g. a
/temperature/ axis?
I understand the “discrete” representation of phenomena (for several
historical reasons) is this still true? Considering resolutions of sensors
actually available and more precise in the future ? yes they are digital
data but their representation of the continuum is quite detailed..
If I understand correctly, there are two things that can be discrete in a
coverage, and this is a little bit confusing (at least to me) right now in the
specification:
* The type of value for a particular Field of the RangeType/DataRecord can
be discrete, e.g. a land cover category, which should never be
interpolaetd with another category because the result would be completely
meaningless. I think one limitation right now to be solved is to be able
to specify this separately for each type Field of the DataRecord
* The discrete coverage types based on geometries, i.e.
/discrete-pointcloud/ and /discrete-mesh/ (/MultiPoint/, /MultiCurve/,
/MultiSurface/, /MultiSolid/), where the values are only accurate exactly
for that feature. In a sense, this is making a Coverage out of a vector
feature collection. Depending on what the real world phenomena behind
those feature are, interpolation makes more or less sense. Interpolating
between a desnse set of accurate sensors is certainly something that makes
sense. Still, the measurements are discrete. But, yes I would say that
this is still true.
From the above point, if we have to adopt a standard covjson which
definition is similar to coverage but “simplify” some items and the
process in reality is more complex we probably are missing something.
I think what is important is to define wich coverage information from the CIS
conceptual model CoverageJSON is capable of encoding, and how it does so, as I
describe here
<opengeospatial/CoverageJSON#21 (comment)>.
Sp-temp phenomena means not only 1 picture a day but also 3 measurement a
second.. considering streaming ? so other encoding mpeg4- webVMT.. etc
etc. and their way to represent metadata i.e. XMP or other.
I think coverages can be derived from spatiotemporally-referenced video
streams, but that requires photogrammetry etc. Otherwise the information in
the video is really not organized in a way that facilitates retrieving values
for a certain direct position. A process (coverage function) can be written
that generates such
a coverage from a video as an input, and allows retrieving values from a
spatiotemporal position, but to be efficient it probably involves
preprocessing/caching behind the scene.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABOR5DTYEE3T6AFD2P6MFX3ULUR7LANCNFSM5H3FO3CQ>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
--
Dr. Peter Baumann
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
https://rasdaman.com, mail: ***@***.***
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
- Professor of Computer Science, Jacobs University Bremen
https://www.faculty.jacobs-university.de/pbaumann
mail: ***@***.***
tel: +49-421-200-3178, fax: +49-421-200-493178
"A brilliant idea is a job halfdone."
|
|
@pebau what's wrong with the CIS 1.1 modularization is that (trying to sum up the above):
In the end it tries to define all type of coverages and several encodings, but most readers are left confused about all of them. (note: this is not intended as criticism, but I think we need to acknowledge these issues in order to be able to improve the specification and make it more accessible and successful going forward). |
note that we want to be able to transcode coverages across formats.
hm, where does the modularization scheme reference GMLCOV and GML, except in the encoding?
|
Of course. But coverages can be transcoded across formats even if the logical representation of the same concepts for those formats differ. Therefore separating the conceptual model from the logical model would actually facilitate this. As an example, the logical models of netCDF and CoverageJSON to store and transmit coverage information differ from the CIS encodings, but they can likely express the same DomainSet, RangeType and RangeSet concepts.
There is a vague dependency on GMLCOV / CIS 1.0 in the core coverage conformance class. I will admit I probably did not look at GMLCOV much until now, but essentially that is my argument that readers should not be expected to read the older version of a specification to be deprecated to clearly understand the current version. Looking at it now, it is becoming clear that this the biggest issue I have with CIS 1.1: it imports the older 1.0 specification of itself, instead of explicitly including all conformance classes that still apply, as specifications revisions normally do.
Because this is in Requirement 1 part of the Requirement 1 says this:
What is meant by "this CIS 1.1 standard" as part of the one of that a coverage must implement? My brain stack overflows: this is a requirement with infinite recursion on the whole spec. If what is meant is the new types introduced in CIS 1.1 (e.g. GeneralGridCoverage), this is not clear at all. There is also no separate conformance class for the legacy GMLCOV coverage types vs. the new CIS 1.1 coverage types, it's all in the core coverage conformance class. Any client, visualization or processing tool wishing to support CIS 1.1 coverages is then expected to implement support for all of the inherited GMLCOV coverage types, at least for GML where there is actually an encoding specified for them. And 12.1 gml-coverage overview describes changes to the schemas in 1.1, which might also mean that a client must also be ready to handle the same coverage types encoded using either the GMLCOV 1.0 / CIS 1.0 or the CIS 1.1 types, all as a "CIS 1.1" coverage (i.e. not even being able to ask a service to explicitly negotiate the use of CIS 1.1 schema or coverage types, because CIS 1.1 explicitly specifies that all CIS 1.0 is valid CIS 1.1). I feel like continuing to support both GMLCOV / CIS 1.0 and CIS 1.1, each with a fixed set of coverage types and a specific encoding, and being able to negotiate between clients and servers the representation to return, would have better addressed the compatibility objectives without introducing ambiguity as to what is expected to be in a CIS 1.1 coverage. I also feel like defining the conceptual model and logical model without separate conformance classes for each, and encodings with a single encoding-specific conformance class covering all coverage types, all in the same document, is problematic. But I think I better understand the situation now (the argument that CoverageJSON does not conform to CIS) from those GML Application Profile of binary encodings still including GML + binary data in e.g. netCDF. In my opinion, it should not be necessary for a netCDF or CoverageJSON encoding of a coverage to conform to CIS to include data in the exact logical model as in CIS GML/JSON. In fact 6.2 even acknowledges that "not all encodings are informationally complete". But especially if it is possible to extract the same information (e.g. DomainSet, RangeType) directly from the encoding's own logical model, it should be possible for an encoding to conform to the CIS conceptual model (and to the other-format-coverage conformance class). Having separate conceptual and logical conformance classes would make this clearer / easier. And to me the concept of representing the multiple components of a coverage (separate DomainSet / RangeType) using GML or JSON + some other binary format able to represent coverage data by itself is confusing because A) GMLCOV / CIS 1.1 also defines a way to encode the whole thing including the RangeSet directly in the GML, and B) those other encodings might be able to stand on their own with enough information to infer the DomainSet and/or RangeType. Different media types would also be needed to identify [GML or JSON extra information]+[some other encoding] combinations. Being able to directly request the DomainSet and RangeType and negotiate a media type for each, as in OGC API - Coverages, avoids the need for all that, fortunately. |
|
Hi Jerome,
I do not agree/understand your point B at the end.. could you kindly explain how to include in an easier way generic sensor data into coverages?
Thanks and I apologize for the question..
|
|
Thanks @luciocola . By point B) you mean:
correct? What I meant is that any particular coverage encoding (e.g. netCDF, CoverageJSON) might define their own mechanisms (logical model) to encode the CIS concepts of DomainSet and/or RangeType in addition to RangeSet, including potentially informations about sensor data. Granted, the latter is less likely for several raster data encodings, and they could also be informationally incomplete. But even if they currently don't include all the relevant information, a future version or an extension could be developed for those encodings to include this information directly in such encodings, without the need for a separate CIS GML or JSON file. And with OGC API - Coverages, one can potentially request the DomainSet separately (e.g. from I hope that makes sense and answers your question. |
|
Thanks a lot this clarify..
What I personally see is that is not-logic to define an encoding specific logical model that is already implemented in CIS. This in my humble opinion (and maybe I can be completely wrong..) can cause an increase in issues of interoperability giving the opportunity to specific encodings select the way this information is returned…
Regards and thanks
|
|
@luciocola Thank you, I understand the interoperability concerns. My opinion is that in some cases, encodings are already defined for some communities of interest with an existing logical model that does carry the necessary information. If a clear mapping can be established, it might actually improve interoperability to be able to readily use those existing formats without the need for additional information in a specific format/logical model (e.g. CIS GML/JSON). It is not super clear to me at the moment whether other encodings for coverage data can conform to the Coverage Implementation Schema concepts without implementing its exact logical model, or whether they can only conform to the Abstract Topic 6 / 19123-1 concepts. The other-format-coverage conformance class seems to hint that they can conform to CIS, even if they are informationally incomplete. But maybe the intent of CIS was to actually require the DomainSet / RangeType to always be provided in its exact logical model? Personally, I feel like a strong conceptual model allowing to establish clear mappings to established encodings would achieve greater interoperability than forcing a particular model on all potential encodings. Keeping in mind that one could still require support for particular encodings that stricly adheres to the CIS logical model as well. |
|
hm, to disentangle:
|
|
hm...if there is no mesh encoding, this should not CovJSON prevent from describing the grid coverage aspect. |
|
this distinction of conceptual / logical / encoding has been brought up by one stakeholder recently, it is not part of the coverage ecosystem. Also, I am puzzled by the use of "logical" - GML and JSON for sure are not logical, rather they describe concrete physical encodings, physical byte strings. |
|
AFAICS OAPI-Coverages does have the same problem - how do you return a complete big coverage, and you want to use GeoTIFF and want to be informationally complete? |
"quod erit demonstrandum" (which remains to be proven)
CIS 1.0 is not deprecated. Actually, if you ask me I would like to because coverage understanding much has improved since that writing. But I acknowledge the implementations out there which need to keep their fundament - we cannot deprecate it easily and soon. I keep on wondering why the worry here is about CIS 1.0 - no issue with GML 3.3 that is included, too? In standardization sometimes compromises have to be made... ...and not all can be done in one step. As you correctly have identified some parts still need to be completed. |
...because it splits the coverage in several parts, which comes at a price:
|
|
@pebau Thanks for all the feedback.
What I meant by necessary information was "able to represent the CIS concepts of DomainSet, RangeType, RangeSet". e.g. I think NetCDF might do a better job with the DomainSet than GeoTIFF alone, but perhaps it would be possible to define GeoTIFF tags that could better represent that information. That would improve interoperability between netCDF and GeoTIFF and other encodings.
I was referring to the GML Application Profiles where e.g. a GML file tags along the GeoTIFF file to "add" that information. Some formats also have extension mechanisms (like GeoTIFF tags) which allow to add information without making them incompatible, which would actually be a good approach to ensure that distributed files remain informationally complete.
But the specification seems to acknowledge that despite a PNG or CSV coverage only being able to represent e.g. the RangeSet, it can still conform to the other-format-coverage and coverage conformance classes of the CIS specification. So for even more able formats like CoverageJSON, which allows to properly geo-reference the data, that should of course also be the case. |
I completely agree here that GML and JSON are concrete physical encodings. But CIS specifies a logical model shared by the GML, JSON and RDF encoding -- that is what I refer to as the CIS logical model (UML classes and same or very similar property names). |
As I suggested above, possibly GeoTIFF tags could be defined to provide a better representation of e.g. the DomainSet and RangeType.
In OGC API - Coverages, the CIS JSON DomainSet and RangeType might be embedded in the |
The question is not about whether CIS 1.0 is deprecated or not, but whether a client/viewer/processing tool supporting only CIS 1.1 needs to be able to handle / expect dealing with CIS 1.0 coverage types and schemas/encoding approaches as well. That is a big burden on developers of simple clients. e.g. CIS 1.1 (or 2.0) could have omitted inclusion of deprecated coverage types for which there is a better way to define them (e.g. GridCoverage), and define a single supported way (schema) to encode them in GML, while WCS servers continue to support both CIS 1.0 and 1.1, if there is a mechanism for clients to negotiate which to return.
The exact same issue with GML 3.3 actually as you point out, but as an implementer I am already in desperation before reading on that I also need to support a 3rd completely different specification.
Yes, but I think it is the particular compromises that were made and how those steps were separated in this case, that leaves readers and implementers of CIS 1.1 (or maybe just myself) confused. Especially the fact that 1.1 is a minor revision of CIS, but it has an ambiguous dependency on its prior version. |
|
@jerstlouis @luciocola Apologies for being 5 days behind. A use case that seems reasonable to me is: A building may have many postal addresses or ownerships, on different floors. My reading of ISO19123-1/Abstract Topic 6 is that this is envisaged as being supported. I do not see anything that says a coverage range cannot be geometry-valued. |
As I highlighted in the CoverageJSON / Conceptual modeling e-mail thread, the current CIS specification presents many significant barriers to implementation by developers. These are also obstacles faced by the CoverageJSON submitters in trying to do a proper comparison with CIS and to an eventual harmonization effort.
To address these issues, I suggest that in a future CIS (1.2?) revision:
To review: whether the current multipart-coverage (easy to confuse with coverage-partitioning) and container conformance classes are also relevant for defining additional extensions, or if perhaps they are better handled in the definition of an API/service or data store, respectively.
(See also current complete CIS UML diagrams)
@joanma747 @pebau @Schpidi @cmheazel @ogcscotts @ghobona @cnreediii @jonblower @chris-little @tomkralidis @pomakis @rob-metalinkage @luciocola @lieberjosh @KathiSchleidt @EmDevys @dblodgett-usgs
The text was updated successfully, but these errors were encountered: