I have an ImageMosaic store backed by a Netcdf coverage. The X/Y dimensions are defined in kilometers.
The native CRS is based on a rotated polar_stereographic projection, with units defined as 'km':
First issue, on gt-render:
The following file:
The validArea for the projection defines x bounds as [-Double.MAX_VALUE,Double.MAX_VALUE]
When this envelope is reprojected to the target CRS in the user's request, it results in a much smaller area than what is expected. I am not sure if this is caused by an overflow due to the MAX_VALUE, or by a bug in the AffineTransform2D method that is executed when the reprojection is performed, since we specify UNIT['km', 1000.0] in the target CRS.
This issue causes the eventual image rendered, or WCS output, to be cut off.
I was able to get around the issue replacing the X bounds in the validArea to [-180, 180] (since WGS84 is specified in this envelope). This seemed to fix the issue I was seeing, and the entire domain of the dataset is returned by Geoserver.
The second issue involves the following if block:
Since a UNIT['km', 1000.0] is specified, the instance of the MathTransform is actually a ConcatenatedTransform, which is not handled in this method. This causes the parseCRS method to return null, and eventually throw a NullPointerException.
My fix was to check for a ConcatenatedTransform right before the if block, and extract the transform1, which represents the reprojection, before continuing:
A third issue exists concerning the x/y NetCDFCoordinate instances further below being hardcoded to the 'm' units. This causes the x/y variables in the Netcdf output to be labeled with the 'm' units, instead of 'km'. Note that the AffineTransform instance, as shown above, can be used to determine which units should be used, instead of hard-coding 'm'. However, I noticed that 'm' seems to be hardcoded in the baseline in multiple places, so I am not yet sure how much refactoring that would involve.
Running Geoserver 2.10.4 and Geotools 16.4.