Offset in WMS GetMap png response for requests on raster data with reprojection in GeoServer 2.28.4 and 3.0.0

GeoServer GeoServer User
1

After migrating from GeoServer 2.27.4 to 2.28.4, we noticed that GetMap requests on raster data with reprojection causes the PNG responses to contain an offset. The problem also occurs with GeoServer 3.0.0.

The screenshot below visualizes the problem. The BufferedImage is not aligned with its origin.

GeoTiffGetMapReprojectedTest
GeoTiffGetMapReprojectedTest1844×931 232 KB

I have no clue what could cause the issue. It may be a specific bug related to the Belgian reference systems (EPSG:31370 > EPSG:3812). In ground units, the shift is about 90m.The issue also occurred requesting coordinates in (EPSG:31370 > EPSG:4326). The problem only occurs with raster data (GeoTiff) not with vector data (PostGIS).

This testcase reproduces the issue. It succeeds on 2.27.4, but fails on 2.28.4 and 3.0.0

https://github.com/stijngoedertier/geoserver/commit/2ce35a3c7ec3112e3dfaf8407468f9f5dedeb382

Thank you in advance for your feedback.

2

Not aware of a specific issue for the belgian CRSs, but maybe… are you using a custom CRS defintion or a custom coordinate operation?
Anything in these sections of the documentation:

If so, an issue is know that might affect you, and a fix for it in the works

Cheers
Andrea

3

Thank you, Andrea. Good to hear that the issue might be known.

We actually do use an NTv2 Gridshift file (see GitHub - milieuinfo/gt-transformation-bd72lb72_etrs89lb08 · GitHub ) but it is not on the class path in the unit test. So I think it might be something else… I will do some further testing.

4

Just for completeness, we have issues too with custom projections/operations starting with 2.27.4. One of them is reported as GEOT-7917 and described a bit more in detail here: GS 2.27.5 / GT 33.5 - envelope transformations no longer working correctly . Not sure though if it’s related, but it might give you a hint for further investigations.

That issue is basically, if you have a custom operations defined, as pair of sourceSRS, targetSRS=MathTransform, but then your request for transformation is the other way ‘round: sourceCRS→ targetCRS, then that transformation is wrong and that might give you false results. In your test-case could you implement something like this:

MathTransform srcToTarget = CRS.findMathTransform(sourceCrs, targetCrs);
MathTransform targetToSrc = CRS.findMathTransform(targetCrs, sourceCrs);

assertTrue(src2Target.equals(targetToSrc.inverse()));

For our tests w.r.t. GEOT-7917 this test was in fact failing.

Hope that it helps to identify the issues.

5

Thanks for reporting this, @skalesse . It may be related. Nonetheless, I did some more testing and I confirm that the issue also occurs without bd72lb72_etrs89lb08.gsb NTv2 grid shift file on the class path:

  • I removed the jar containing the gsb file from our installation binary
  • I redeployed 2.28.4
  • I confirmed in the Reprojection Toolbox that the GSB-based transformation was no longer available
  • I see that GetMap WMS output still produces the offset in the output
6

This issue has been fixed by @aaime-geosolutions . See his pull request for GeoTools:

Many thanks to both of you for all your help with this. Looking forward to testing the next release.

7

While I fixed it to to the best of my abilities, it would be good if someone with the original datasets could try it out using a nightly build of the 3.0.x series or the 2.28.x series.
They can be found here:

Cheers
Andrea

8

Much appreciated. I can confirm that the unit test, which includes a sample of the original dataset, succeeds with your fix. We will deploy a snapshot build in our integration environment and do some further manual testing there.