Support grid coverages

[Dimitar Misev]

Petascope should support GridCoverage, and the systemtest should load one 4D floating-point grid coverage.

[Dimitar Misev]

changeset:1b57f46123827e40ba0975892b15511c6c477907

[Piero Campalani]

Before closing the ticket, I believe we should:

• drop gml:boundedBy/ows:BoundingBox elements in case of simple GridCoverage
• add some WCS/WCPS test, like a coverage description and:

  service=WCS&
  version=2.0.1&
  request=GetCoverage&
  coverageid=float_4d&
  subset=0(0)&
  subset=1(0)&
  subset=2(0,20)&
  subset=3(0,20)
  

  which currently does not work for a NullPointer at:

  petascope.util.CrsUtil.convertToInternalGridIndices(CrsUtil.java:781)
  

  indeed those are already internal indexes, so we have to inhibit that call for GridCoverages.

[Peter Baumann]

isn't removing the boundedBy violating req 1 in WCS Core?

[Piero Campalani]

Now I see that req.. I was not aware of it: a boundedBy element does not make sense in a GridCoverage because it does not have a CRS so we don't have the necessary info to fill a bounding box.
If we set a CRS instead then it does not really make sense to stick with the GridCoverage type, but rather we use RectifiedGridCoverage/ReferenceableGridCoverage types. ?

[Peter Baumann]

the idea in WCS 2 was that _every_ coverage has a CRS. In case of a GridCoverage that would likely be an IndexCRS. Otherwise we loose uniform treatment of coverages.

[Piero Campalani]

After a brief discussion, it was decided to specify a BBOX for GridCoverage coverages too, automatically setting a proper [IndexCRss Index CRS] and assuming:

• the offset vectors are the versors of the nD cartesian CS bound to the origin of the datum-marray (this means in practice {[1,0,0],[0,1,0],[0,0,1]} for a 3D grid);
• the origin of the coverage coincides with the origin of the CRS ([0,0,0,_,0]).

This way external indexes coincide with internal rasdaman ones, and probably reduces confusion.

The coverage function will then work assuming this geometric mapping of the grid to the CRS.

[Piero Campalani]

In this specific case, resolving this ticket also means adding an Index4D CRS to SECORE.
Right now a compounding of, say, 3+1 Index CRSs is possible but personally quite ugly.

The question is about which axis label to give to the 4th axis: now we have 'i', 'j', 'k'.

.. 'l' ?

CoE people dropped "I" and "O" UTM zones from their scheme since they were similar to 1 and 0 numbers. In this case lowercase l might pose the same problem, so we could also directly jump to 'm' ?

[Peter Baumann]

indeed, I opt for m. And, for our MetOcean folks with 5D data, let's go 5D and add "n".

[Piero Campalani]

Index CRS assigned by default + tests in changeset:30c21ef.