Le Wednesday 01 July 2009 10:50:51 Hermann Peifer, vous avez écrit :
> Even Rouault wrote:
> > Does gdalinfo -checksum lceugr100_00_pct_epsg4326.tif works ?
>
> Not really:
> Warning 1: lceugr100_00_pct_epsg4326.tif:PackBitsDecode: discarding 94
> bytes to avoid buffer overrun
> ERROR 1: lceugr100_00_pct_epsg4326.tif:PackBitsDecode: Not enough data
> for scanline 13228
> ERROR 1: TIFFReadEncodedStrip() failed.
>
> ERROR 1: IReadBlock failed at X offset 0, Y offset 13228
> ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 13228
> ERROR 3: Checksum value couldn't be computed due to I/O read error.
>
> > If it doesn't, you might want to try with a recent GDAL (e.g 1.6.1)and
> > internal libtiff support.
>
> OK. I upgraded from version 1.6.0 to 1.6.1. This didn't help. I ran into
> the same error at the same scanline 22054. :-(
>
> I am also not too sure about internal libtiff support, as configure
> tells me:
> LIBTIFF support: external (BigTIFF=no)
That tells you that you're using libtiff from your system (probably libtiff
3.8.2). Try again with : ./configure --with-libtiff=internal, make clean,
make. If it still doesn't work, you should check (with third-party software
not using libtiff) if your file is not corrupted. If it is not, then it is a
bug in libtiff.
>
> Some postings on Internet suggest as a workaround: first warping without
> compression, then compressing afterwards via gdal_translate. This worked
> fine for smaller raster data sets, but eventually, I ran into the error
> that the uncompressed (intermediate) destination file would be larger
> than the limit (4GB).
There's no using trying gdalwarp while gdalinfo -checksum gives errors.
Warping with compression should work in general but may lead to larger files
than necessary. There are several options :
- add -co BIGTIFF=YES to the gdalwarp command line if BigTIFF is an option for
your use case, to go beyond the 4GB limit
- do what you mention : gdalwarp then gdal_translate. But the gdal_translate
might also fail if the compressed data is still larger than 4GB (what it
cannot anticipate because compression rate is not known). As above,
adding -co BIGTIFF=YES to the gdal_translate command line will enable you to
produce file >= 4GB. In your case, the output file (uncompressed) is 121261 x
44229 = 5.3 GB, so you can hope that once compressed it goes beyond 4GB.
- for the sake of completeness : a variant is to use gdalwarp to produce a VRT
file and then use gdal_translate to produce a TIFF file. The gdalwarp will
just run in a few milliseconds. The gdal_translate will take more time than a
gdal_translate from a standard raster file as it will do the reprojection on
the fly.
gdal_warp -t_srs EPSG:4326 -of VRT input.tif output.vrt
gdal_translate output.vrt output.tif -co COMPRESS=PACKBITS [-co
BIGTIFF=YES]
>
> I am basically stuck now.
>
> :-( Hermann
> :
> > Le Tuesday 30 June 2009 16:06:52 Hermann Peifer, vous avez écrit :
> >> Hi.
> >>
> >> I am trying to warp a GeoTiff from EPSG:3035 to EPSG:4326. After 50%
> >> done, I end up with the following errors:
> >>
> >> $ gdalwarp -t_srs EPSG:4326 lceugr100_00_pct.tif
> >> lceugr100_00_pct_epsg4326.tif -co COMPRESS=PACKBITS
> >>
> >> Copying color table from lceugr100_00_pct.tif to new file.
> >> Creating output file that is 121261P x 44229L.
> >> Processing input file lceugr100_00_pct.tif.
> >>
> >> 0...10...20...30...40...50..ERROR 1:
> >> lceugr100_00_pct_epsg4326.tif:PackBitsDecode: Not enough data for
> >> scanline 22054
> >>
> >> ERROR 1: TIFFReadEncodedStrip() failed.
> >> ERROR 1: IReadBlock failed at X offset 0, Y offset 22054
> >> ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 22054
> >>
> >> Is there any issue with the decoding the PACKBITS compression?
> >>
> >> Hermann
> >>
> >>
> >>
> >> $ gdalinfo lceugr100_00_pct.tif
> >>
> >> Driver: GTiff/GeoTIFF
> >> Files: lceugr100_00_pct.tif
> >> lceugr100_00_pct.aux
> >> Size is 67000, 58000
> >> Coordinate System is:
> >> PROJCS["ETRS_1989_LAEA_L52_M10",
> >> GEOGCS["GCS_ETRS_1989",
> >> DATUM["European_Terrestrial_Reference_System_1989",
> >> SPHEROID["GRS_1980",6378137.0,298.257222101]],
> >> PRIMEM["Greenwich",0.0],
> >> UNIT["Degree",0.0174532925199433]],
> >> PROJECTION["Lambert_Azimuthal_Equal_Area"],
> >> PARAMETER["False_Easting",4321000.0],
> >> PARAMETER["False_Northing",3210000.0],
> >> PARAMETER["Central_Meridian",10.0],
> >> PARAMETER["Latitude_Of_Origin",52.0],
> >> UNIT["Meter",1.0]]
> >> Origin = (800000.000000000000000,6500000.000000000000000)
> >> Pixel Size = (100.000000000000000,-100.000000000000000)
> >> Metadata:
> >> AREA_OR_POINT=Area
> >> Image Structure Metadata:
> >> COMPRESSION=PACKBITS
> >> INTERLEAVE=BAND
> >> Corner Coordinates:
> >> Upper Left ( 800000.000, 6500000.000) ( 72d48'20.05"W, 59d 5'6.85"N)
> >> Lower Left ( 800000.000, 700000.000) ( 24d 7'20.21"W, 22d12'54.64"N)
> >> Upper Right ( 7500000.000, 6500000.000) ( 90d22'56.28"E, 61d55'58.94"N)
> >> Lower Right ( 7500000.000, 700000.000) ( 41d 0'50.13"E, 23d29'5.23"N)
> >> Center ( 4150000.000, 3600000.000) ( 7d17'47.28"E, 55d28'33.08"N)
> >> Band 1 Block=67000x1 Type=Byte, ColorInterp=Palette
> >> Metadata:
> >> LAYER_TYPE=thematic
> >> Color Table (RGB with 256 entries)
> >> ...
> >>
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev@lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
