NODATA value not used for fill in reprojected tif

Description

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:

1) 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"]]

2) optionally, add the attached sld to geoserver.

3) 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

4) 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.

Environment

RHEL and Windows

Attachments

5

Activity

Andrea Aime 
February 15, 2017 at 11:47 AM

Mass closing all resolved issues not modified in the last 4 weeks

Andrea Aime 
February 9, 2016 at 9:51 PM

Thanks for getting back to us!

Tom Ruff 
February 9, 2016 at 8:51 PM

I tried reinstalling 2.8.2, adding the java option and following my steps to reproduce. This time it worked (connecting band was transparent), so must have been operator error the first time. I did notice that using the default raster style instead of the one that I attached to this issue will result in a black band connecting the two pieces of the image. So this issue can be closed as invalid.

Andrea Aime 
February 7, 2016 at 11:11 AM
(edited)

Btw, look at the full screenshot (just click on it), the little preview cuts away the second copy of the data.

Andrea Aime 
February 7, 2016 at 11:11 AM

Removed 2.7.2 from the "affects" since it's known 2.7.x cannot handle NODATA.
I've then tried with 2.8.2, following your instructions, but the output does not have the red band for me, it's transparent instead:

This is the URL I've used:
http://localhost:8080/geoserver/nurc/wms?service=WMS&version=1.1.0&request=GetMap&layers=nurc:bug&styles=&bbox=-180.0,-90,180.0,90&width=768&height=330&srs=EPSG:4326&format=application/openlayers

(the same url with image/png or image/jpeg does not produce red banding either).

The 2.8.2 is a fresh installation with the basic demo data, no other changes (that I can remember at least).

Cannot Reproduce

Details

Assignee

Reporter

Affects versions

Components

Priority

Created February 2, 2016 at 9:51 PM
Updated February 15, 2017 at 11:47 AM
Resolved February 9, 2016 at 9:51 PM