Coverage axes and CRS axes

[Piero Campalani]

Currently a coverage's metadata assigns CRS axes labels to the axes of a gridded coverage.
This can be misleading when it comes to rotated or curvilinear grids, though currently not supported.

Ideally, axes names are fetched from rasdaman, and fill the gml:axisLabels in the gml:domainSet of a coverage, whereas CRS axes appear in the ​gml:SRSReferenceGroup attributes group.

[Dimitar Misev]

There are no axis names in rasdaman. Did you mean petascopedb?

[Piero Campalani]

I should not open tickets on Sundays: I got confused with the range space rasdaman labelling.

petascopedb neither, it was discussed to keep it out and label the grid axes just as 0, 1, 2, and so on. It is practical, and does not overlap with CRS labelling.

We can still discuss this on the mailing-list: if we see users want a customisable labelling of the axes, then we can add it to petascopedb. ?

[Dimitar Misev]

What's the use of these labels? In WCPS the CRS axis label will be used right, while these 0,1,2,.. labels are just for the gml:axisLabels/gml:domainSet?

[Piero Campalani]

Yes.
In WCPS still there is no clear distinction between a grid or CRS axis label, anyway the user subsettings should be meant on the CRS, so yes, no 0,1,2 labelling in WCPS nor WCS queries. those are meant for the sake of GML description.

[abeccati]

Also not belonging to 8.5

[Piero Campalani]

From this problem derives a bug in the GML output of a coverage where CRS axis order does not reflect the rasdaman grid axis order, as with our eobstest (time + EPSG:4326) systemtest coverage.

Rasdaman axis order is time then easting (Long) then northing (Lat), whereas lat and long are flipped in the CRS definition (​http://www.opengis.net/def/crs/EPSG/0/4326).

This should be properly managed, otherwise, since rasdaman always stores eastings first, the GML would not bet coherent in case of lat-first CRSs.

[Peter Baumann]

hm, is the input correct wrt data and metadata axis order?

[Piero Campalani]

GML fixed in partial patch with changeset:db28696 : now the ordering of CRS axis semantics in the CRS related attributes follows what is expressed in the GML definition, while grid axis labels keep following their internal grid order as they are stored in rasdaman.

For binary encodings (GeoTiff and the like), the usual longitude-first order is kept to preserve coherent behaviors of GIS libraries. See [PetascopeUserGuide#GridaxislabelsandCRSaxislabels this] page for further insights.

What is left to close the ticket is a clearer distinction between CRS and grid axes: this will later easy implementation of non-aligned grids. This task probably represents a relevant structural change in Petascope, and as well is dependent on the future proceedings of the WCPS standard.

[Piero Campalani]

Axis order in coverage summaries (WCS capabilities) fixed in changeset:de1fac7.

[Dimitar Misev]

Closing as out of date with respect to the latest rasdaman version.