|
The attached geotiff has extents of approximately 152 degrees longitude to -168 longitude, crossing the anti-meridian. Its native projection is a custom pacific-centered projection, defined by following wkt and it has a NODATA value set to -9999:
PROJCS[“Pacific World Equidistant Cylindrical”,
GEOGCS[“WGS 84”,
DATUM[“WGS_1984”,
SPHEROID[“WGS 84”,6378137,298.257223563,
AUTHORITY[“EPSG”,“7030”]],
AUTHORITY[“EPSG”,“6326”]],
PRIMEM[“Greenwich”,0],
UNIT[“degree”,0.0174532925199433],
AUTHORITY[“EPSG”,“4326”]],
PROJECTION[“Equirectangular”],
PARAMETER[“latitude_of_origin”,0],
PARAMETER[“central_meridian”,150],
PARAMETER[“standard_parallel_1”,0],
PARAMETER[“false_easting”,0],
PARAMETER[“false_northing”,0],
UNIT[“metre”,1, AUTHORITY[“EPSG”,“9001”]]]
The image is rendered correctly when geoserver responds to a GetMap request that specifies its native projection.
However, when the image is requested via GetMap as a whole-world image in epsg:4326, geoserver has to split the image at the anti-meridian and show part of the image on the left and the rest on the right. These two parts of the image must of course be returned to the requestor as a single image, so geoserver should use transparent pixels for the “filler” (i.e., set the filler grid values to the nodata value). Instead, geoserver selects a value that is different from the NODATA value in the original geotiff and as a result the pixels gets styled into a color according to the sld as if they contained real information. This results in an opaque color band connecting the two pieces of the reprojected, split image.
If the reprojected image is requested as a geotiff instead of png, you can use qgis or similar tool to inspect the grid value used for the filler pixels. The value selected is not consistent across different geotiffs.
Steps to reproduce:
- add following custom pacific centered projection to geoserver’s epsg.properties file:
904326=PROJCS[“Pacific World Equidistant Cylindrical”,
GEOGCS[“WGS 84”,
DATUM[“World Geodetic System 1984”,
SPHEROID[“WGS 84”,6378137,298.257223563,
AUTHORITY[“EPSG”,“7030”]],
AUTHORITY[“EPSG”,“6326”]],
PRIMEM[“Greenwich”,0,AUTHORITY[“EPSG”,“8901”]],
UNIT[“degree”,0.0174532925199433,AUTHORITY[“EPSG”,“9108”]],
AXIS[“Geodetic longitude”, EAST],
AXIS[“Geodetic latitude”, NORTH],
AUTHORITY[“EPSG”,“4326”]],
PROJECTION[“Equidistant_Cylindrical”, AUTHORITY[“EPSG”,“1028”]],
PARAMETER[“central_meridian”,150],
PARAMETER[“latitude_of_origin”,0],
PARAMETER[“standard_parallel_1”,0],
PARAMETER[“false_easting”,0],
PARAMETER[“false_northing”,0],
UNIT[“m”,1.0],
AXIS[“Easting”, EAST],
AXIS[“Northing”, NORTH],
AUTHORITY[“EPSG”,“904326”]]
-
optionally, add the attached sld to geoserver.
-
create a geotiff store using the attached geotiff. Publish it as a layer using these parameters:
Declared srs: EPSG:904326
SRS Handling: force declared
Lat/lon bounding box: leave as default
Available style: sld created above
default style: sld created above
-
request the image using WMS GetMap with BBOX set to whole world (-180,-90,180,90) and srs=epsg:4326. If output type is image/png you’ll see a single color horizontal band connecting the two valid parts of the image, colored according to the sld. If the output format is specified as image/geotiff then you can see the value assigned to the NODATA region does not match the NODATA value from the original geotiff (using qgis or similar tool).
I’ve reproduced this behavior in geoserver 2.7.2 and 2.8.2 with the “-Dorg.geotools.jaiext.enabled=true” system variable passed to the java command starting up GeoServer.
|
