Re-organize CIS into simpler Core + Extensions

[jerstlouis]

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.

• There is a lot of confusion with the similarly named coverage classes inherited from GMLCOV which CIS 1.1 currently indicates may be deprecated in the future, and for which there is no JSON encoding (see also JSON encoding for rectified grid-regular coverage, GridCoverage vs. GeneralGrid #11)
• There is no JSON encoding defined for the discrete-mesh coverage types (MultiPointCurve, MultiPointSurface, MultiPointSolid)
• There are dependencies on separate complex standards (e.g. coverage function from GML 3.2.1; RangeType / DataRecord from SWE Common; transformation from SensorML) which requires an implementor to dig deep into those standards in order to implement conformance classes, despite only small bits of those being relevant
• There is a lack of examples for certain capabilities (e.g. grid-transformation -- any possibilities to define transformation besides SensorML? the one example links to HTML pages, surely that is not valid; using GeneralGridCoverage with custom CRS with affine transformation to handle the GMLCOV grid coverage types use cases)
• The Conceptual and Logical model for CIS are defined together in the same conformance classes, leading to significant confusion as to how encodings besides the XML/GML, JSON and RDF defined in the standard (other-format-coverage conformance class) can still conform to the Conceptual Model (e.g. coverage and grid-regular conformance class, as illustrated by the CoverageJSON e-mail thread. Having separate conformance classes for the logical model would avoid the need for an other-format-coverage conformance class altogether, and make the Abstract Tests more streamlined.

To address these issues, I suggest that in a future CIS (1.2?) revision:

• We fully deprecate coverage types marked for deprecation (GridCoverage, Rectified­Grid­Coverage, Reference­able­Grid­Cov­er­age), after verifying the use cases for them are easily and clearly handled (e.g. with proper examples such as for custom CRS defining affine transformation) by the GeneralGridCoverage
• We define the missing JSON encodings for the discrete mesh coverage types (perhaps embedding TopoJSON or GeoJSON)
• We try to better align the name of the conceptual/logical model classes with the name of the conformance classes, where possible (e.g. right now General Grid coverages is defined inside class grid-regular which is super confusing)
• We embed in each part/document all the essential relevant explanations, UML diagrams, schemas and examples inherited from other standards (GML 3.2.1, SWE Common, SensorML), while still referencing those documents as appropriate
• We re-organize the specifications into separate parts/documents as suggested below:

1. A minimalistic Core Coverage Implementation Schema covering the current coverage conformance class (AbstractCoverage), including describing the domain set and range type) as well as support for regular grid (grid-regular conformance class, GeneralGridCoverage) but without introducing irregular grids/axes yet
   • Conceptual Model
   • Logical model
   • Encodings (JSON, RDF, XML)
2. An Irregular Grid Coverage extension adding support for irregular grids (grid-irregular conformance class) to GeneralGridCoverage
   • Conceptual Model
   • Logical model
   • Encodings (JSON, RDF, XML)
3. A Point Coud Coverage extension adding support for point clouds (discrete-pointcloud conformance class, MultiPointCoverage)
   • Conceptual Model
   • Logical model
   • Encodings (JSON, RDF, XML)
4. A Discrete Mesh Coverage extension, adding support for coverage defined by 1D, 2D or 3D geometries (discrete-mesh conformance class, MultiCurveCoverage, MultiSurfaceCoverage, MultiSolidCoverage)
   • Conceptual Model
   • Logical model
   • Encodings (JSON, RDF, XML)
5. A Grid Transformation extension adding support to apply transformations to the grid (grid-transformation conformance clas, as done with SensorML (including practical examples)
   • Conceptual Model
   • Logical model
   • Encodings (JSON, RDF, XML)
6. A Partitioned Coverage extension adding support to specify a coverage in multiple parts (coverage-partitioning conformance class; review whether the Position / Values specified here is redundant with the Point Cloud extension)
   • Conceptual Model
   • Logical model
   • Encodings (JSON, RDF, XML)

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

[EmDevys]

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

[jerstlouis]

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…

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.

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.

In OGC API - Coverages, the /coverage response only includes what the negotiated content type (e.g. image/tiff; application=geotiff) is directly capable of representing:

Req 5 C The content of that response SHALL also include the domainset and rangetype as well, to the extent that the negotiated format can describe it.

Negotiating multipart/related could perhaps return e.g. a CIS JSON for the DomainSet and RangeType + a GeoTIFF for the RangeSet, but that is not really necessary because they are available separately.

The DomainSet and RangeType are usually either embedded in /collections/{collectionId} or at /coverage/domainset and /coverage/rangetype (but always linked from /collections/{collectionId}, using a JSON pointer if they are in the same document). So this this is why I suggest this multipart conformance class seems more tied to the protocol/service (RFC 2387 and WCS in particular).

[luciocola]

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

[jerstlouis]

Thank you @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
  • RegularGridCoverage
  • IrregularGridCoverage
• Discrete Coverages
  • MultiPointCoverage (point cloud)
  • DiscreteMeshCoverage (including MultiPointCoverages)
    • MultiCurveCoverage
    • MultiSurfaceCoverage
    • MultiSolidCoverage
    • Do we need a separate MixedGeometryCoverage?

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).

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 interpolated 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 dense 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.

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.

[pebau]

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."

[jerstlouis]

@pebau what's wrong with the CIS 1.1 modularization is that (trying to sum up the above):

• It does not clearly distinguish between the concepts and the specific logical models used in the GML, JSON and RDF encodings,
• It imports a lot of complexity from GMLCOV which it says is likely to be deprecated anyways,
• It is a single specification/very large document covering many different capabilities that relies on separate also very large specifications, but despite that it leaves several things ambiguous and unspecified, with not enough concrete encoding examples in the document to be able to follow.

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).

[pebau]

@pebau what's wrong with the CIS 1.1 modularization is that (trying to sum up the above):

* It does not clearly distinguish between the concepts and the specific logical models used in the GML, JSON and RDF encodings,

note that we want to be able to transcode coverages across formats.

* It imports a lot of complexity from GMLCOV which it says is likely to be deprecated anyways,

hm, where does the modularization scheme reference GMLCOV and GML, except in the encoding?

* It is a single specification/very large document covering many different capabilities that relies on separate also very large specifications, but despite that it leaves several things ambiguous and unspecified, with not enough concrete encoding examples in the document to be able to follow.

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).

[jerstlouis]

@pebau

note that we want to be able to transcode coverages across formats.

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.

hm, where does the modularization scheme reference GMLCOV and GML, except in the encoding?

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.

1.2.4 This document augments GMLCOV/CIS 1.0 as a backwards-compatible extension: any valid GMLCOV/CIS 1.0 coverage is also valid in CIS 1.1. This is accomplished through Requirement 1 which declares any valid GMLCOV/CIS 1.0 coverage to also be a valid CIS 1.1 coverage.

Because this is in Requirement 1 part of the coverage class (the CIS 1.1 Core), any encoding inherits this (although the JSON conformance class and schema do not specify how all those GMLCOV types are encoded, so that leaves ambiguity for the json-coverage conformance class).

Requirement 1 says this:

A coverage shall implement at least one of: this CIS 1.1 standard; the GMLCOV/CIS 1.0 standard; the GMLCOV/CIS 1.0 standard with the additional grid definitions provided with GML 3.3.

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.

[luciocola]

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..

[jerstlouis]

Thanks @luciocola . By point B) you mean:

B) those other encodings might be able to stand on their own with enough information to infer the DomainSet and/or RangeType.

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 /coverage/domainset) in CIS JSON which already defines how to retrieve SensorML transformations/information, hence why I believe the multipart/related e.g. GML+netCDF approach is less essential than it is with WCS.

I hope that makes sense and answers your question.

[luciocola]

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

[jerstlouis]

@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.

[pebau]

hm, to disentangle:

• "...that does carry the necessary information" - the necessity here is interoperability. Which is not a primary goal of some individual data encoding - NetCDF was not designed to be interoperable with GeoTIFF, to bring a brutal example. So "necessary" is a difficult attribute here.
• "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)." CIS encodings do not add information, they just explain how to use the native data format mechanisms to represent CIS information, as much as possible. Of course, because adding to a data format would mean breaking it, making it an incompatible clone.
• "The other-format-coverage conformance class seems to hint that they can conform to CIS, even if they are informationally incomplete." yes - PNG or CSV, for example. It represents a part of a coverage and will never be able to get ingested again as a neat georeferenced coverage, still it is good enough for a browser map display in practice, and so user need has driven it. So PNG and CSV could be specified as data formats suitable for representing "extracts" of a coverage.