WCPS coverage information does not update the CRS on slices

[Piero Campalani]

Upon slicings, the (cell) dimensionality of a coverage is properly decreased by calling the setDimension() method of the petascope.wcps.server.core.CoverageInfo class.

However, like done for on the WCS counterpart (petascope.wcs2.parsers.GetCoverageMetadata class), the CRS must be updated too:

crsName = CrsUtil.sliceAxesOut(meta.getCrsUris(), slicedAxes);

From petascope.wcs2.extensions.AbstractFormatExtension.

This bug highlights the need for a refactoring in the handling of dynamic coverage metadata (static is in petascope.core.CoverageMetadata): WCS GetCoverageMetadata should be including and actively using the metadata from CoverageInfo on the WCPS side. We need a singleton point of metadata update.

[Piero Campalani]

This bug ends up delivering wrong RasQL encode queries (e.g. the whole compound CRS URI is passed to the class handling the GDAL parameters, and the extracted auth:code for GDAL is pointing to the last single URI).

[Peter Baumann]

to be fixed with WCPS 2.0, spec under work.

[Bang Pham Huu]

Replying to pcampalani:

This bug ends up delivering wrong RasQL encode queries (e.g. the whole compound CRS URI is passed to the class handling the GDAL parameters, and the extracted auth:code for GDAL is pointing to the last single URI).

with the new WCPS 1.5 service (it uses completely news classes), it will add the correct CRS from compound CRS in this case (i.e: slicing a 3D: eobstest coverage on time axis to a 2D coverage) correctly, so I think this ticket can be closed.

eobtest's CRS in GML:

http://localhost:8080/def/crs-compound?
1=http://localhost:8080/def/crs/EPSG/0/4326&
2=http://localhost:8080/def/crs/OGC/0/AnsiDate?axis-label="t"

WCPS query:

for c in (eobstest) return encode(c[t("1950-01-01")], "tiff")

and Rasql query:

SELECT encode(c[0,0:100,0:231], "gtiff" , 
"xmin=-40.50;ymin=25.00;xmax=75.50;ymax=75.50;crs=EPSG:4326") 
FROM eobstest AS c

[Peter Baumann]

great to see this work!
What happens if you slice in x and retain y/t?

[Bang Pham Huu]

Replying to pbaumann:

great to see this work!
What happens if you slice in x and retain y/t?

In your case, the output still a 2D coverage and the combination of y and t axes is not a valid CRS (neither geo-referenced CRS nor time CRS), then it will set the coverage's output CRS to Index2D.

[Peter Baumann]

yes, I agree to some extent. It is a good way to solve an otherwise really hard problem.
Is this behavior documented?

[Bang Pham Huu]

Replying to pbaumann:

yes, I agree to some extent. It is a good way to solve an otherwise really hard problem.
Is this behavior documented?

wrt your question, I think it is not yet in any documents as far as know.

[Peter Baumann]

…then this should be done. Reopening for this purpose.

[Dimitar Misev]

What is the petascope documentation, where can this information be put? Any suggestion Bang?

We have these petascope pages:

PetascopeDevGuide
PetascopeEmbedded
PetascopeInstallGuide
PetascopeOld
PetascopeSubsets
PetascopeTimeHandling
PetascopeUserGuide

[Bang Pham Huu]

For me, it seems ​http://rasdaman.org/wiki/PetascopeSubsets is the most suitable for adding this information (subset on axes and CRSs).

[Peter Baumann]

seeing this again:
what about extracting the axes from the CRSs involved (at least EPSG lists identifiers) and recombine a CRS in cases where we cannot directly derive from a compound CRS?

[Dimitar Misev]

Should be closed, documentation has been updated already at ​http://rasdaman.org/wiki/PetascopeSubsets#SetCRSforoutputcoverage