subject:"\[Geoserver\-users\] geotiff compression with predictor"

Re: [Geoserver-users] geotiff compression with predictor

2017-05-25 Thread Andrea Aime

The GDAL GeoTIFF reader has been explicitly removed from the
GDAL extension package as it kept on causing problems (but I don't remember
the details of what was happening, sorry!).

Cheers
Andrea


On Thu, May 25, 2017 at 5:53 PM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> 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
> <andrea.a...@geo-solutions.it> 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 <k...@cornell.edu>
> 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 Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
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 pos

Re: [Geoserver-users] geotiff compression with predictor

2017-05-25 Thread Keith Jenkins

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)
<jukka.rahko...@maanmittauslaitos.fi> 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
> <andrea.a...@geo-solutions.it> 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 <k...@cornell.edu> 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

2017-05-25 Thread Rahkonen Jukka (MML)

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
<andrea.a...@geo-solutions.it> 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 <k...@cornell.edu> 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

2017-05-25 Thread Keith Jenkins

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

Re: [Geoserver-users] geotiff compression with predictor

2017-05-25 Thread Andrea Aime

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 Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
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.

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

2017-05-24 Thread Keith Jenkins

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

Re: [Geoserver-users] geotiff compression with predictor

Re: [Geoserver-users] geotiff compression with predictor

Re: [Geoserver-users] geotiff compression with predictor

Re: [Geoserver-users] geotiff compression with predictor

Re: [Geoserver-users] geotiff compression with predictor

[Geoserver-users] geotiff compression with predictor

6 matches

Site Navigation

Mail list logo

Footer information