GeoTools

All coverage formats using RasterLayerRequest break if the destinationToSourceTransform is an affine transform

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.7.5
  • Component/s: None
  • Labels:
    None

Description

This is happening because the code calls:

requestedGridToWorld.preConcatenate((AffineTransform) destinationToSourceTransform);

However the requestedGridToWorld is a XAffineTransform on which the source coverage is defined and it's marked as immutable, calling preConcatenate on it will result in:

Caused by: java.lang.UnsupportedOperationException: This affine transform is unmodifiable.
	at org.geotools.referencing.operation.matrix.XAffineTransform.checkPermission(XAffineTransform.java:88)
	at org.geotools.referencing.operation.transform.AffineTransform2D.checkPermission(AffineTransform2D.java:94)
	at org.geotools.referencing.operation.matrix.XAffineTransform.preConcatenate(XAffineTransform.java:225)
	at org.geotools.gce.imagemosaic.RasterLayerRequest.inspectCoordinateReferenceSystems(RasterLayerRequest.java:779)
	at org.geotools.gce.imagemosaic.RasterLayerRequest.computeRequestSpatialElements(RasterLayerRequest.java:969)
	at org.geotools.gce.imagemosaic.RasterLayerRequest.prepare(RasterLayerRequest.java:748)
	at org.geotools.gce.imagemosaic.RasterLayerRequest.<init>(RasterLayerRequest.java:241)
	at org.geotools.gce.imagemosaic.RasterManager.read(RasterManager.java:330)
	at org.geotools.gce.imagemosaic.ImageMosaicReader.read(ImageMosaicReader.java:625)

I suggest the code to be modified so that requestedGridToWorld is built as a AffineTransform copy of the coverage affine transform, this will allow the pre-concatenation to work

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. GEOS-4675 WMS 1.3.0 may to handle CRS whose native order is NORTH/EAST (for raster formats that use RasterLayerRequest class)

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrea Aime added a comment -
Btw, the attached GeoServer jira contains a way to reproduce the problem in GeoServer, mind, you have to use the WMS 1.3 request provided by the user, which has the bbox entries swapped compared to the wms 1.1 since the official EPSG definition of that layer says NORTH/EAST axis order
Show
Andrea Aime added a comment - Btw, the attached GeoServer jira contains a way to reproduce the problem in GeoServer, mind, you have to use the WMS 1.3 request provided by the user, which has the bbox entries swapped compared to the wms 1.1 since the official EPSG definition of that layer says NORTH/EAST axis order
Hide
Permalink
Tony Young added a comment - - edited
Here is the same patch from GEOS-4675 but, as it is a GeoTools problem, it has been attached to this ticket. I can't figure out how to test it well, but it should probably be part of GranuleTest.
Show
Tony Young added a comment - - edited Here is the same patch from GEOS-4675 but, as it is a GeoTools problem, it has been attached to this ticket. I can't figure out how to test it well, but it should probably be part of GranuleTest.
Hide
Permalink
Simone Giannecchini added a comment -
done some commits on trunk and 2.7.x, waiting for some feedback...
Show
Simone Giannecchini added a comment - done some commits on trunk and 2.7.x, waiting for some feedback...
Hide
Permalink
Robert Coup added a comment -
Hi folks, I just tried this with the 20110724042210 nightly. It gets past the immutable error, but still doesn't return an image.

Flow as I can see it (tracing the example request from [GEOS-4675]):

* requestedBBox is initially (y0:y1, x0:x1) in RasterLayerRequest.inspectCoordinateReferenceSystems() - ie. North, East
* requestedBBox then gets updated to (x0:x1, y0:y1) because we have an AffineTransform (ie. the precompute now works), and destinationToSourceTransform is cleared
* in computeCropBBox(), destinationToSourceTransform gets resurrected because (requestCRS != rasterManager.spatialDomainManager.coverageCRS2D)
* it builds cropBBox, which is (y0:y1, x0:x1) (ie. swapped back)
* which then doesn't intersect rasterManager.spatialDomainManager.coverageBBox (x0:x1, y0:y1), because we're comparing x against y & vice versa.
* so we get an empty result
Show
Robert Coup added a comment - Hi folks, I just tried this with the 20110724042210 nightly. It gets past the immutable error, but still doesn't return an image. Flow as I can see it (tracing the example request from [ GEOS-4675 ]): * requestedBBox is initially (y0:y1, x0:x1) in RasterLayerRequest.inspectCoordinateReferenceSystems() - ie. North, East * requestedBBox then gets updated to (x0:x1, y0:y1) because we have an AffineTransform (ie. the precompute now works), and destinationToSourceTransform is cleared * in computeCropBBox(), destinationToSourceTransform gets resurrected because (requestCRS != rasterManager.spatialDomainManager.coverageCRS2D) * it builds cropBBox, which is (y0:y1, x0:x1) (ie. swapped back) * which then doesn't intersect rasterManager.spatialDomainManager.coverageBBox (x0:x1, y0:y1), because we're comparing x against y & vice versa. * so we get an empty result
Hide
Permalink
Robert Coup added a comment -
Patch to remove the transform work that inspectCoordinateSystems() does. Passes all unit tests, and adds a new test to GranuleTest to cover this case.
Show
Robert Coup added a comment - Patch to remove the transform work that inspectCoordinateSystems() does. Passes all unit tests, and adds a new test to GranuleTest to cover this case.
Hide
Permalink
Robert Coup added a comment -
Test data to go with the new test in GEOT3704-1.patch
Show
Robert Coup added a comment - Test data to go with the new test in GEOT3704-1.patch
Hide
Permalink
Robert Coup added a comment -
Would still like a review - I've gone back through the history of that method and it got introduced during a big refactor by Simone, so there may be further reasons it exists that I don't know about...
Show
Robert Coup added a comment - Would still like a review - I've gone back through the history of that method and it got introduced during a big refactor by Simone, so there may be further reasons it exists that I don't know about...
Hide
Permalink
Andrea Aime added a comment -
It seems there are still issues, please have a look at the new patch
Show
Andrea Aime added a comment - It seems there are still issues, please have a look at the new patch
Hide
Permalink
Andrea Aime added a comment -
Committed a small variant of Robert's patch that does not remove the existing code optimizing away the destinationToSourceTransform in case it's an affine one. The test added by Robert still passes, the mosaic attache to the GEOS issues displays fine in both WMS 1.1 and WMS 1.3
Show
Andrea Aime added a comment - Committed a small variant of Robert's patch that does not remove the existing code optimizing away the destinationToSourceTransform in case it's an affine one. The test added by Robert still passes, the mosaic attache to the GEOS issues displays fine in both WMS 1.1 and WMS 1.3

People

  • Assignee:
    Andrea Aime
    Reporter:
    Andrea Aime
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: