Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Critical
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 2.0.x
-
Component/s: Configuration
-
Labels:None
Description
As can be seen from the snippet below:
String userDefinedCrsIdentifier = (String)envelope.get( "srsName" );
String nativeCrsWkt = (String)envelope.get("crs");
coverage.setSRS(userDefinedCrsIdentifier);
CoordinateReferenceSystem crs = CRS.parseWKT(nativeCrsWkt);
coverage.setNativeCRS( crs );
ReferencedEnvelope bounds = new ReferencedEnvelope(
(Double) envelope.get( "x1" ), (Double) envelope.get( "x2" ),
(Double) envelope.get( "y1" ), (Double) envelope.get( "y2" ),
crs
);
coverage.setNativeBoundingBox(bounds);
The catalog importer reads the bounds projected in the user defined CRS and associates to them the native CRS, so resulting on a final Coverage Envelope which has wrong coordinates against its CRS.
Of course this error can cuse unexpected GeoServer behavior when threating Rasters.
oops, my fault.
The fix is easy, yet its a bit annoying due to the following:
ResourceInfo hast setNativeBoundingBox and getNativeBoundingBox. It also has getBoundingBox() to get the bounds in the declared crs, but there's no setter for it. Instead, ResourceInfo explicitly documents it to be a derived property from getNativeBoundingBox().
That is, ResourceInfo implementations shall store the native box and perform the reprojection themselves for the getBoundingBox() result.
Which leads me to think I would prefer to change that contract and keep the catalog *Info classes being as plain data objects as possible instead of forcing them to make any computation.