Inverse dimension problem in GridCoverage2d

Martin Desruisseaux added a comment - 22/Aug/05 4:33 AM Yes, the 'getAxis(1)' is cleary a bug; it should have been 'getAxis(i)' as reported. Thank for spotting that. I fixed this bug on my local copy and will commit after the usual maven build-test cycle. However, the "inverse[dim - i - 1]" is less obvious to me. For a 2D grid coverage, this mean "if axis 0 is oriented toward West instead of East, actually invert axis 1 (usually the y axis). If axis 1 is oriented toward South instead of North, actually invert axis 0 (usually the x axis)". Maybe this situation is wanted when the coordinate reference system uses a (latitude,longitude) order? (I would need to check what the actual behavior is in such case). So my question regarding the [dim - i - 1] proposal is: which CRS is in use when such case is wanted?

Martin Desruisseaux added a comment - 22/Aug/05 5:52 PM After a little bit of investigation, it seems that the axis swapping issue (i.e. inverse[dim - i - 1]) is a consequence of usage of CRS with (latitude,longitude) axis. The GridCoverage2D constructor with an Envelope argument is a convenience constructor which assumes that axis order in the supplied image matches exactly axis order in the supplied CRS. In other words, if axis order in the supplied image is (x,y) (which is the case for a majority of images), then the CRS given to this constructor should probably have a (longitude,latitude) or (easting,northing) axis order. If this is not the case (for example for the EPSG:4326 CRS with (latitude,longitude) axis order), then the constructor variant with a MathTransform argument (instead of an Envelope) provides more determinist behavior, since math transform allows full control on axis swapping and inversion. It may be preferable to improves GridCoverage2D constructor in order to perform automatically axis swapping for CRS using (latitude,longitude) axis order. One thing we need to think about is what to do if axis don't match exactly the expected set, e.g. (longitude,time) axis without latitude. I know it sound strange, but those kind of images are really in use in oceanographic publications.

Martin Desruisseaux added a comment - 30/Aug/05 6:18 PM A fix has been commited on trunk as of revision 15556. Setting the status to "resolved", but not yet "closed" since we need to make sure that the fix work as expected in "real world" applications. The fix include the following:   - Improved javadoc explaining what the GridCoverage2D(..., Envelope, ...) convenience constructor expects and how it handle axis.   - Removed the inspection of axis in GridCoverage sources. It was probably overkill, and bring more complexity to an already complex constructor.   - Swap automatically axis in the particular case where the axis orientations are (NORTH|SOUTH, EAST|WEST).