[Geoserver-users] NODATA value not used for fill in reprojected tif

GeoServer GeoServer User
1

I have a geotiff with a custom Pacific-centered projection. The tif has a single band with NODATA value set to -9999. When I request the layer from geoserver in the native projection it looks correct.

tifNative.png

When I request the layer in a whole-world Atlantic centered projection (epsg:4326) the image is split at the anti-meridian (i.e., shown running off the right edge of the map and continuing on the left). This is all good. However, the two halves of the image are connected by a maroon band. The maroon color comes from my sld, but where did the grid values that are being styled maroon come from?

tifFill.png

I would think that it should use the NODATA value from the original tif - which would result in the pixels being rendered transparent. But instead it appears to pick an arbitrary value and assigns that value to the grid points in the fill region. The pictures help illustrate what I’m talking about. Is this a bug, or am I doing something wrong?

I’m running Geoserver 2.7.2.

Thanks,

Tom

2

Hi Tom,
In lieu of any other answers, I’d suggest this looks like a bug.
If you want to report it (http://docs.geoserver.org/stable/en/user/introduction/gettinginvolved.html#bug-tracking) ideally with a reproduction case, hopefully it will get looked at.

Cheers,
Jonathan

···

On 20/01/2016 22:45, Ruff, Thomas wrote:

I have a geotiff with a custom Pacific-centered projection. The tif has a single band with NODATA value set to -9999. When I request the layer from geoserver in the native projection it looks correct.

tifNative.png

When I request the layer in a whole-world Atlantic centered projection (epsg:4326) the image is split at the anti-meridian (i.e., shown running off the right edge of the map and continuing on the left). This is all good. However, the two halves of the image are connected by a maroon band. The maroon color comes from my sld, but where did the grid values that are being styled maroon come from?

tifFill.png

I would think that it should use the NODATA value from the original tif - which would result in the pixels being rendered transparent. But instead it appears to pick an arbitrary value and assigns that value to the grid points in the fill region. The pictures help illustrate what I’m talking about. Is this a bug, or am I doing something wrong?

I’m running Geoserver 2.7.2.

Thanks,

Tom

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
[http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140](http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140)

_______________________________________________
Geoserver-users mailing list
[Geoserver-users@lists.sourceforge.net](mailto:Geoserver-users@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-users](https://lists.sourceforge.net/lists/listinfo/geoserver-users)
3

Sure, I can enter that next week with a test case and sample tiff.

Btw, in an attempt to determine the value that geoserver was using for the filler grid points created during the re-projection I requested the re-projected layer as output format image/tiff. The returned tiff had no NODATA value set even thought the original tiff did. Surprisingly, no projection was set in the tiff either (regardless of what projection was specified in the GetMap request). So it’s losing tiff metadata during re-projection. I suspect that this could be related to the issue.

Thanks,

Tom

tifNative.png

tifFill.png

···

On 20/01/2016 22:45, Ruff, Thomas wrote:

I have a geotiff with a custom Pacific-centered projection. The tif has a single band with NODATA value set to -9999. When I request the layer from geoserver in the native projection it looks correct.

tifNative.png

When I request the layer in a whole-world Atlantic centered projection (epsg:4326) the image is split at the anti-meridian (i.e., shown running off the right edge of the map and continuing on the left). This is all good. However, the two halves of the image are connected by a maroon band. The maroon color comes from my sld, but where did the grid values that are being styled maroon come from?

tifFill.png

I would think that it should use the NODATA value from the original tif - which would result in the pixels being rendered transparent. But instead it appears to pick an arbitrary value and assigns that value to the grid points in the fill region. The pictures help illustrate what I’m talking about. Is this a bug, or am I doing something wrong?

I’m running Geoserver 2.7.2.

Thanks,

Tom

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
[http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140](http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140)

_______________________________________________
Geoserver-users mailing list
[Geoserver-users@lists.sourceforge.net](mailto:Geoserver-users@anonymised.comsourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-users](https://lists.sourceforge.net/lists/listinfo/geoserver-users)
4

You would need to request your output as format=image/geotiff to see a projection being included in the output, image/tif is just the standard image format.

Ian

tifFill.png

tifNative.png

···

On 22 January 2016 at 22:19, Ruff, Thomas <THOMAS.RUFF@anonymised.com> wrote:

Sure, I can enter that next week with a test case and sample tiff.

Btw, in an attempt to determine the value that geoserver was using for the filler grid points created during the re-projection I requested the re-projected layer as output format image/tiff. The returned tiff had no NODATA value set even thought the original tiff did. Surprisingly, no projection was set in the tiff either (regardless of what projection was specified in the GetMap request). So it’s losing tiff metadata during re-projection. I suspect that this could be related to the issue.

Thanks,

Tom

From: Jonathan [jonathan-lists@anonymised.com]
Sent: Friday, January 22, 2016 1:54 AM
To: Ruff, Thomas
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] NODATA value not used for fill in reprojected tif

Hi Tom,
In lieu of any other answers, I’d suggest this looks like a bug.
If you want to report it (http://docs.geoserver.org/stable/en/user/introduction/gettinginvolved.html#bug-tracking) ideally with a reproduction case, hopefully it will get looked at.

Cheers,
Jonathan

On 20/01/2016 22:45, Ruff, Thomas wrote:

I have a geotiff with a custom Pacific-centered projection. The tif has a single band with NODATA value set to -9999. When I request the layer from geoserver in the native projection it looks correct.

tifNative.png

When I request the layer in a whole-world Atlantic centered projection (epsg:4326) the image is split at the anti-meridian (i.e., shown running off the right edge of the map and continuing on the left). This is all good. However, the two halves of the image are connected by a maroon band. The maroon color comes from my sld, but where did the grid values that are being styled maroon come from?

tifFill.png

I would think that it should use the NODATA value from the original tif - which would result in the pixels being rendered transparent. But instead it appears to pick an arbitrary value and assigns that value to the grid points in the fill region. The pictures help illustrate what I’m talking about. Is this a bug, or am I doing something wrong?

I’m running Geoserver 2.7.2.

Thanks,

Tom

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
[http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140](http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140)

_______________________________________________
Geoserver-users mailing list
[Geoserver-users@lists.sourceforge.net](mailto:Geoserver-users@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-users](https://lists.sourceforge.net/lists/listinfo/geoserver-users)

Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–

Ian Turton

5

On Wed, Jan 20, 2016 at 2:45 PM, Ruff, Thomas <THOMAS.RUFF@anonymised.com> wrote:

I have a geotiff with a custom Pacific-centered projection. The tif has a
single band with NODATA value set to -9999. When I request the layer from
geoserver in the native projection it looks correct.

There is a simple explanation for that, no GeoServer release before 2.8.0

has any support for NODATA in its raster
operations.
And even the 2.8.x series by default won't work properly with NODATA, one
has to activate a certain flag to add an experimental support for it.

The reason is that the low level library used to perform image processing,
JAI, has no notion of what NODATA is. We have build
a replacement called jai-ext that has explicit NODATA support (
https://github.com/geosolutions-it/jai-ext), and had 2.8.0xuse it
as an option, but by the time we had to release some kinks still had to be
worked out so we disabled it by default, however one can
make it come to life by adding the "-Dorg.geotools.jaiext.enabled=true"
system variable to the java command starting up
GeoServer.

If you want to stay on 2.7.x I'd suggest you change your style so that the
pixels at -9999 are marked as transparent in the
colormap, otherwise we are about to release 2.8.2, you can install it,
enable jai-ext, and see if the output gets better.
If not, then we'd indeed like to have a bug report filed :slight_smile:

2.8.2 is not officially released yet but release artifacts can already be
downloaded here, if you want to try them out:
http://ares.boundlessgeo.com/geoserver/release/2.8.2/

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

6

Andrea,
I think part of the problem here is that there are no pixels anywhere near -9999 once the reprojected geotiff has been generated. gdalinfo -stats only returns positive values in this case.

Thanks,
Dave

On Jan 23, 2016, at 6:27 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Jan 20, 2016 at 2:45 PM, Ruff, Thomas <THOMAS.RUFF@anonymised.com> wrote:
I have a geotiff with a custom Pacific-centered projection. The tif has a single band with NODATA value set to -9999. When I request the layer from geoserver in the native projection it looks correct.

There is a simple explanation for that, no GeoServer release before 2.8.0 has any support for NODATA in its raster
operations.
And even the 2.8.x series by default won't work properly with NODATA, one has to activate a certain flag to add an experimental support for it.

The reason is that the low level library used to perform image processing, JAI, has no notion of what NODATA is. We have build
a replacement called jai-ext that has explicit NODATA support ( https://github.com/geosolutions-it/jai-ext), and had 2.8.0xuse it
as an option, but by the time we had to release some kinks still had to be worked out so we disabled it by default, however one can
make it come to life by adding the "-Dorg.geotools.jaiext.enabled=true" system variable to the java command starting up
GeoServer.

If you want to stay on 2.7.x I'd suggest you change your style so that the pixels at -9999 are marked as transparent in the
colormap, otherwise we are about to release 2.8.2, you can install it, enable jai-ext, and see if the output gets better.
If not, then we'd indeed like to have a bug report filed :slight_smile:

2.8.2 is not officially released yet but release artifacts can already be downloaded here, if you want to try them out:
http://ares.boundlessgeo.com/geoserver/release/2.8.2/

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

-------------------------------------------------------
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

CONFIDENTIALITY WARNING: This e-mail may contain proprietary, privileged, or sensitive information of Applied Physical Sciences Corp. Any unauthorized use or disclosure of this communication is prohibited. Contractual restrictions may also apply to third parties. If you believe that you have received this email in error, please notify the sender immediately and delete it from your system.

7

Thanks for the background on NODATA support Andrea, and the info on different handling for the image/geotiff output format Ian. That is very helpful.

I’ll try upgrading and see how it behaves with the java option enabled. Staying on 2.7 and changing the style sounds a little trickier because the geotiffs are not being added manually and the value geoserver is assigning to the generated fill points seems non-deterministic to me. Also, in one of the geotiffs I’ve tested the value assigned to the fill points appears to be a value used in the original raster.

Thanks,

Tom

···

On Wed, Jan 20, 2016 at 2:45 PM, Ruff, Thomas <THOMAS.RUFF@…554…> wrote:

I have a geotiff with a custom Pacific-centered projection. The tif has a single band with NODATA value set to -9999. When I request the layer from geoserver in the native projection it looks correct.

There is a simple explanation for that, no GeoServer release before 2.8.0 has any support for NODATA in its raster
operations.
And even the 2.8.x series by default won’t work properly with NODATA, one has to activate a certain flag to add an experimental support for it.

The reason is that the low level library used to perform image processing, JAI, has no notion of what NODATA is. We have build
a replacement called jai-ext that has explicit NODATA support ( https://github.com/geosolutions-it/jai-ext), and had 2.8.0xuse it
as an option, but by the time we had to release some kinks still had to be worked out so we disabled it by default, however one can
make it come to life by adding the “-Dorg.geotools.jaiext.enabled=true” system variable to the java command starting up
GeoServer.

If you want to stay on 2.7.x I’d suggest you change your style so that the pixels at -9999 are marked as transparent in the
colormap, otherwise we are about to release 2.8.2, you can install it, enable jai-ext, and see if the output gets better.
If not, then we’d indeed like to have a bug report filed :slight_smile:

2.8.2 is not officially released yet but release artifacts can already be downloaded here, if you want to try them out:
http://ares.boundlessgeo.com/geoserver/release/2.8.2/

Cheers
Andrea

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

8

On Sat, Jan 23, 2016 at 5:35 PM, Dave Parillo <dparillo@anonymised.com> wrote:

Andrea,
I think part of the problem here is that there are no pixels anywhere near
-9999 once the reprojected geotiff has been generated. gdalinfo -stats
only returns positive values in this case.

I know, different problem though, WMS generates rendered maps, not raw
data, once those pixels go
through the colormap support they should come out as colors, so -9999
becomes the transparent one, or the background color, depending on
the the request.

If you want to get NODATA in output you're loooking for a raw data request,
that is, a WCS one.
There is a ticket open for such case, help to get it fixed would be very
much welcomed:

https://osgeo-org.atlassian.net/browse/GEOS-7077

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------