Opened 3 years ago

Closed 3 years ago

#760 closed defect (fixed)

Support grid coverages

Reported by: dmisev Owned by: pcampalani
Priority: minor Milestone: 9.0.x
Component: petascope Version: development
Keywords: gridcoverage support Cc: pbaumann
Complexity: Medium

Description

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

Change History (12)

comment:1 Changed 3 years ago by dmisev

  • Resolution set to fixed
  • Status changed from new to closed

comment:2 Changed 3 years ago by pcampalani

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.

comment:3 Changed 3 years ago by pcampalani

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:4 Changed 3 years ago by pcampalani

  • Owner changed from dmisev to pcampalani
  • Status changed from reopened to assigned

comment:5 Changed 3 years ago by pbaumann

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

comment:6 Changed 3 years ago by pcampalani

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

comment:7 Changed 3 years ago by pbaumann

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.

comment:8 Changed 3 years ago by pcampalani

  • Cc pbaumann added; pcampalani removed
  • Keywords gridcoverage support added
  • Priority changed from critical to minor

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.

comment:9 Changed 3 years ago by pcampalani

  • Status changed from assigned to accepted

comment:10 Changed 3 years ago by pcampalani

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' ?

comment:11 Changed 3 years ago by pbaumann

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

comment:12 Changed 3 years ago by pcampalani

  • Resolution set to fixed
  • Status changed from accepted to closed

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

Note: See TracTickets for help on using tickets.