4th paragraph:  This technical guidance shows how the operations required by the INS NS ...

This technical guidance shows how the operations required by the [INS NS] ...

The Spatial Object Types defined in [INS ISSDS] that ...

(23) NOTE: … and in the INSPIRE Generic Conceptual model document is used synonymously with spatial object. [Note modified from INSPIRE Generic Conceptual model]

2nd paragraph: For example, [INS NS] uses the abbreviated title for the document as shown below:

For example, [INS NS] uses the abbreviated title for the document as shown below:

p.14, 1st paragraph: Coverage functions are used...

(5) coordinate reference systems

Systems for uniquely referencing spatial information in space as a set of coordinates (x, y, z) and/or latitude and longitude and height, based on a geodetic horizontal and vertical datum [INSPIRE Directive]

(6) coverage

spatial object that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain, in accordance with ISO 19123:2007  [INS ISDSS]

EXAMPLE Orthoimage, digital[PB1]  elevation model (as grid or TIN), point grids etc.

(1) coverage

spatial object that acts as a function to return values from its range for any direct position within its spatial, temporal or spatiotemporal domain, in accordance with ISO 19123:2007 [INS ISDSS]

EXAMPLE Orthoimage, Image timeseries, digital elevation model (as grid or TIN), point grids etc.

(12) geographical grid systems

NOTE 2 ... Thus, a 'geographical grid' is equivalent to an ISO 19123 coverage. ...

(12) geographical grid systems

NOTE 2 ... The unqualified term 'grid' may refer either to a grid geometry or a geographical grid (coverage) depending on the context.

(13) GML coverage

(13) GML coverage

... subclass (specialization) of a Coverage ...

(17) range (of a coverage)

... feature attribute...

(21) spatial data services

operations...

Not sure about meaning of this row 2: another service? Detailing of row 1 = headline?

Based on the explanation below, maybe it is better understandable to leave out this “NOT ABLE” and just state “By definition, if a service ….”

Leave out file/database exemplification.

For all standards referenced, suggest to use just major version number. Reasons:

• By definition, all 1.x are compatible, therefore anything that works with 1. should also work with 1.1. Confining this would introduce artificial constraints
• Later changes, say from 1.0 to 1.1 will require major work, such as edits + new version

Conformance classes used:

• gml-coverage 

The WCS core specification specifies the core operations required to be implemented by any WCS, remaining agnostic of the request encoding; protocol bindings are WCS extensions. This way, functionality and encoding are separated.

Two protocol bindings are currently supported by WCS 2.0:

Three bindings, actually: GET, POST, SOAP. REST is under preparation.

BTW, you list only one.

Conformance classes used:

• HTTP POST
• SOAP encoding

Support for the this protocol binding is indicated in a WCS GetCapabilities response as:

No, a coverage is delivered in its Native Format, whatever this might be.

CAVEAT: GMLCOV is not GML!

Based on the points made in the table, why not establish a recommendation for say JSON for 1D; TIFF for 2D; NetCDF for 3D, 4D? Or maybe tie format recommendations to the Annex themes?

As it stands, clients might have a hard time confronted with the myriads of format choices.

e.g. Example 5: http://myserver.ac.uk/some/folders/ows?service=WCS&request=GetCapabilities&

Is this special for this choice? Why not implementing institution, for example?

Support for the extension is indicated in the GetCapabilities response by the following profile information:

The first conformance class is the WCS CRS core conformance class, crs:

<ows:Profile>

http://www.opengis.net/spec/WCS_service-extension_crs/1.0/conf/crs

</ows:Profile>

Second, the WCS CRS specialization for gridded coverages needs to be supported for raster-type coverages:

<ows:Profile>

http://www.opengis.net/spec/WCS_service-extension_crs/1.0/conf/crs-gridded-coverage

</ows:Profile>

If the WCS CRS extension is supported then all actually supported CRSs are listed in the crsSupported elements of the Capabilities document:

...

Example 23: ...

Note that such CRSs can be spatial, temporal, or mixed spatio-temporal. The OGC Name Type Specification for CRSs (OGC 11-135r2) establishes how to compose new CRSs from existing ones, such as adding a time axis to a horizontal CRS for obtaining image timeseries, as expressed in the following example:

http://www.opengis.net/def/crs-compound?
    1=http://www.opengis.net/def/crs/EPSG/0/4326&
    2=http://www.opengis.net/def/crs/OGC/0/8601

The list of reported supported CRS is NOT in any order and cannot be used to imply the native CRS of any coverage.

A WCS server supporting the CRS extension allows two additional parameters in the GetCoverage request: outputCrs for determining the CRS into which the coverage is to be projected before encoding and delivery and subsettingCrs indicating the CRS in which the request bounding box is expressed.

Subsetting is subdivided into trimming and slicing. Trimming retains the dimension of the coverage, it just reduces the extent along one or more axes; for example, trimming a 2D coverage yields a 2D output. Syntactically, trimming is expressed by indicating a lower and upper bound for the axis along which subsetting takes place.

Slicing reduces the dimension of the output by cutting out a (hyper-) plane at the slice point indicated. For example, in an x/y/t image timeseries a slice point at a particular point in time would extract a 2D x/y image. Conversely, slicing in x and y would extract a 1D timeseries. Obviously, the output format chosen must be able to encode the coverage extract; in the 2D case discussed this might be GeoTIFF, whereas in the 1D timeseries extract GML or JSON might be appropriate.

Suggest to uniformly keep parameter names in uppercase. In this example we have 3 different conventions!