Re: [Geoserver-users] geotiff compression with predictor
There is also this GDAL extension for GeoServer: http://docs.geoserver.org/latest/en/user/data/raster/gdal.html I haven't tried it, but from that page, it looks like GeoTIFF would still be handled by the built-in GeoServer GeoTIFF support (and not via the GDAL extension). Keith On Thu, May 25, 2017 at 11:53 AM, Rahkonen Jukka (MML) wrote: > Hi, > > I wonder if it woud work with the imageio-ext GDAL plugin > http://docs.geotools.org/stable/userguide/library/coverage/imageio.html which > seems to contain GDAL GeoTIFF driver > > -Jukka Rahkonen- > ________ > Keith Jenkins wrote: > Re: [Geoserver-users] geotiff compression with predictor > > Thanks, Andrea. For now, I'm just planning to avoid using compression > predictors in any GeoTiFFs. > > When we get data from other sources, we don't always know how the > files were generated. As far as I can tell, gdalinfo will indicate if > compression is used in a GeoTIFF, but it doesn't say what predictor > was used. However, tiffinfo will report the predictor. Of course, > one can always use gdal_translate to ensure that no compression > predictor is used. > > Hopefully this info will be useful for others troubleshooting in the future... > > Cheers, > Keith > > > On Thu, May 25, 2017 at 3:18 AM, Andrea Aime > wrote: >> Hi Keith, >> as far as I know predictor=3 is completely unknown to the TIFF reader, and >> the type=2 does not support 32 bit data. >> >> There is a ticket open in imageio-ext (the library we use to read TIFF) >> about this, >> although it may be a bit too specific (only talks about type 3): >> >> https://github.com/geosolutions-it/imageio-ext/issues/58 >> >> Cheers >> Andrea >> >> >> On Wed, May 24, 2017 at 10:05 PM, Keith Jenkins wrote: >>> >>> I've run into a WMS rendering problem with some compressed GeoTIFF >>> files that were generated using gdal_translate. When the problem >>> occurs during a WMS request, GeoServer returns XML containing: >>> >>> >>> Error rendering coverage on the fast path >>> org.geotools.coverage.processing.CoverageProcessingException: >>> java.lang.NullPointerException >>> java.lang.NullPointerException >>> >>> >>> You can see the full geoserver.log entry here: >>> https://gist.github.com/kgjenkins/5128f5afd3f82167e391c98a1c02f8f8 >>> >>> I'm running GeoServer 2.10.0 on Linux. >>> >>> I've tried various compression options, and the problem seems to occur >>> whenever I use gdal_translate -co PREDICTOR=2 or 3, and this happens >>> with both COMPRESS=LZW or DEFLATE. With no compression, or with >>> PREDICTOR=1 (the default, no prediction), everything works fine.) >>> >>> I've searched the archives of this list, and this seems to be the same >>> problem reported on 2014-06-06: >>> https://sourceforge.net/p/geoserver/mailman/message/32426808/ >>> >>> The only other mention seems to confirm the lack of GeoServer support >>> for GeoTIFF compression predictors, but dates from 2011: >>> https://sourceforge.net/p/geoserver/mailman/message/28400721/ >>> >>> For now, I'm content to simply use GeoTIFFs with no compression predictor. >>> >>> But is this something that should be submitted as a GeoServer issue? >>> In my search to see if such an issue already existed, I did find this >>> related issue for the GeoTools project. Here's the link, in case it >>> is relevant to GeoServer: >>> https://osgeo-org.atlassian.net/browse/GEOT-5542 >>> >>> Thanks for any guidance, >>> Keith > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Geoserver-users mailing list > Geoserver-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-users -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
Re: [Geoserver-users] geotiff compression with predictor
Thanks, Andrea. For now, I'm just planning to avoid using compression predictors in any GeoTiFFs. When we get data from other sources, we don't always know how the files were generated. As far as I can tell, gdalinfo will indicate if compression is used in a GeoTIFF, but it doesn't say what predictor was used. However, tiffinfo will report the predictor. Of course, one can always use gdal_translate to ensure that no compression predictor is used. Hopefully this info will be useful for others troubleshooting in the future... Cheers, Keith On Thu, May 25, 2017 at 3:18 AM, Andrea Aime wrote: > Hi Keith, > as far as I know predictor=3 is completely unknown to the TIFF reader, and > the type=2 does not support 32 bit data. > > There is a ticket open in imageio-ext (the library we use to read TIFF) > about this, > although it may be a bit too specific (only talks about type 3): > > https://github.com/geosolutions-it/imageio-ext/issues/58 > > Cheers > Andrea > > > On Wed, May 24, 2017 at 10:05 PM, Keith Jenkins wrote: >> >> I've run into a WMS rendering problem with some compressed GeoTIFF >> files that were generated using gdal_translate. When the problem >> occurs during a WMS request, GeoServer returns XML containing: >> >> >> Error rendering coverage on the fast path >> org.geotools.coverage.processing.CoverageProcessingException: >> java.lang.NullPointerException >> java.lang.NullPointerException >> >> >> You can see the full geoserver.log entry here: >> https://gist.github.com/kgjenkins/5128f5afd3f82167e391c98a1c02f8f8 >> >> I'm running GeoServer 2.10.0 on Linux. >> >> I've tried various compression options, and the problem seems to occur >> whenever I use gdal_translate -co PREDICTOR=2 or 3, and this happens >> with both COMPRESS=LZW or DEFLATE. With no compression, or with >> PREDICTOR=1 (the default, no prediction), everything works fine.) >> >> I've searched the archives of this list, and this seems to be the same >> problem reported on 2014-06-06: >> https://sourceforge.net/p/geoserver/mailman/message/32426808/ >> >> The only other mention seems to confirm the lack of GeoServer support >> for GeoTIFF compression predictors, but dates from 2011: >> https://sourceforge.net/p/geoserver/mailman/message/28400721/ >> >> For now, I'm content to simply use GeoTIFFs with no compression predictor. >> >> But is this something that should be submitted as a GeoServer issue? >> In my search to see if such an issue already existed, I did find this >> related issue for the GeoTools project. Here's the link, in case it >> is relevant to GeoServer: >> https://osgeo-org.atlassian.net/browse/GEOT-5542 >> >> Thanks for any guidance, >> Keith -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
[Geoserver-users] geotiff compression with predictor
I've run into a WMS rendering problem with some compressed GeoTIFF files that were generated using gdal_translate. When the problem occurs during a WMS request, GeoServer returns XML containing: Error rendering coverage on the fast path org.geotools.coverage.processing.CoverageProcessingException: java.lang.NullPointerException java.lang.NullPointerException You can see the full geoserver.log entry here: https://gist.github.com/kgjenkins/5128f5afd3f82167e391c98a1c02f8f8 I'm running GeoServer 2.10.0 on Linux. I've tried various compression options, and the problem seems to occur whenever I use gdal_translate -co PREDICTOR=2 or 3, and this happens with both COMPRESS=LZW or DEFLATE. With no compression, or with PREDICTOR=1 (the default, no prediction), everything works fine.) I've searched the archives of this list, and this seems to be the same problem reported on 2014-06-06: https://sourceforge.net/p/geoserver/mailman/message/32426808/ The only other mention seems to confirm the lack of GeoServer support for GeoTIFF compression predictors, but dates from 2011: https://sourceforge.net/p/geoserver/mailman/message/28400721/ For now, I'm content to simply use GeoTIFFs with no compression predictor. But is this something that should be submitted as a GeoServer issue? In my search to see if such an issue already existed, I did find this related issue for the GeoTools project. Here's the link, in case it is relevant to GeoServer: https://osgeo-org.atlassian.net/browse/GEOT-5542 Thanks for any guidance, Keith -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
