GetCoverage ReferenceableDatasets incorrect subsetting.

[pacesm]

The GetCoverage for referenceable datasets SHALL NEVER return pixels outside of the extent of the full original dataset. In other words, the subsetting shall return a subset of the image contained in the spatial subsetting geometry and it shall not inflate this subset by the no-data pixels.

[constantinius]

Unfortunately, this is not what the CRS Extension specifies (which is quite vague, to be honest). The spec states:

Requirement 21 crs-gridded-coverage/getCoverage-rangeSet: The range values of the response to a successful GetCoverage request containing an outputCrs parameter shall be determined according to the following conceptual evaluation model: Take the bounding box of the request’s subsetting parameter (or the full coverage bounding box if no subsetting was specified in the request); re-project this bounding box to the output CRS provided; generate the result image extent as the smallest bounding box around the reprojected subsetting box; fill this new image extent with pixel values re-projected from the coverage’s Native CRS to the output CRS in a way that, for each axis, the smallest distance between any two reprojected grid points is used as offset (including all interpolation and resampling necessary) unless specified otherwise by further request parameters.

So in my opinion, there is no obligation to trim the subsetting bounding box to the coverages extent in the desired projection. I also think that this would be a dangerous thing to do, since the response would not be what the client requested.

E.g: If you specify the subsets for the geospatial region of a dummy CRS: 10, 10, 20, 20, but the coverage only is in the region 12, 12, 18, 18 you would always have to re-evaluate the actual response, as have no guarantee that the response is what you asked for.

I think there are two viable options to respond when the subsets are larger than the coverages extent:

• Always try to return with an "inflated" image (current implementation)
• Return with an error. This would be inline with the "pixel" subsetting method, but this could be really tricky to handle in border cases.

I agree, that the current implementation might not be perfect and there is a need for discussion. But I think that cropping the subsets to the coverages extent is WORSE.

[eox-cs1]

This situation has been under a long discussion during standard writing. -> Always try to return with an "inflated" image (current implementation) has been the agreed solution: give the user what the user asks for. Imagine: A user request e.g. 10 coverages with a predefined subset, then the user shall get these coverages with the requested subset, regardless it its full of data or partly filled with zeros. Otherwise the user needs to check each coverage of the returned stack for its coordinates and fit it accordingly before the user could start his actual work e.g. run some statistical analysis on the stack. For the implemented solution the Top-Left pixel will always have the same coordinates and the returned coverages can easily be stacked and processed further.

[pacesm]

Add eox-ca1, are you sure you talking about Referenceable Dataset, i.e., the images in the original satellite geometry? Because what you are describing seems like desired behaviour for the rectified datasets with a given output CRS (!=ImageCRS) when you can really get a pile of pixel-to-pixel co-registered rasters. The subsetting CRS (the subject if this discussion) gives you no guarantee of the output grid even for the Rectified datasets (different rectified coverages can have different native CRSes). For the Referenceable Datasets the situation is even more complex. There is not concept of the output CRS other than the ImageCRS as these dataset are never re-sampled unless you turn them into the Rectified Datasets. The images can never be stacked without proper co-registration. The mapping between the map-coordinates and the pixel space is typically guaranteed with a reasonable precision inside image extent only (if the mapping outside of the image extent exists at all). If you try guess size of the inflated image in the extrapolated pixel space outside of the image extent you blindly rely on some unpredictable mathematical artefacts which can sometime run quickly out of any reasonable bounds.

Add Constantinus, in my opinion, the Requirement 21 cannot be applied to the REFERENCEABLE dataset despite the fact it has been canonized in the standard. For me it just another example how not-well-thought-through the WCS standard really is. The only correct subsetting of a REFERENCEABLE dataset is:

1. Take the subsetting geometry in and the Referenceable Dataset raster outline geometry both projected in the subsetting CRS and make their intersection.
2. Project this intersection to the ImageCRS (the only possible outputCRS of a Referenceable Dataset) and get a portion of the image containing this intersection geometry. And, BTW, this was the behaviour before you "fixed" it.