[gdal-dev] Getting error with gdaladdo on Tiff files

Stephen Woodbridge woodbri at swoodbridge.com
Sun Jun 27 13:25:17 EDT 2010


OK, so I have solved the problem.

I built 1.7.2 from source and still had the problem with gdaladdo using 
the files that I warped with 1.5.2. I warped the files again using 1.7.2 
and then gdaladdo worked ok.

So, it looks like there might have been a bug in gdalwarp in 1.5.2 that 
does not show up checking with gdalinfo -checksum

-Steve

Stephen Woodbridge wrote:
> Frank Warmerdam wrote:
>> On Sat, Jun 26, 2010 at 6:41 PM, Stephen Woodbridge
>> <woodbri at swoodbridge.com> wrote:
>>> Hi all,
>>>
>>> I have a few Spot image files and ran the following. Is there a good 
>>> way to
>>> check the integrity of the original image. Should I have used some other
>>> options?
>>
>> Steve,
>>
>> I imagine the problem is due to a broken system libtiff.  You
>> can check the integrity of the original file using:
>>
>>   gdalinfo -checksum file1.tif
>>
>> I would suggest trying to rebuild GDAL using the internal libtiff.  The
>> system libtiff often has subtle issues with overview building which
>> requires zipping back and forth between the base and overview
>> image when doing io.
>>
>> Best regards,
> 
> Ok, ran the checksum on the 4 original files and no issues reported.
> 
> My gdal-1.5.2 build is a debian package that I build from source and my 
> debian/rules file has the following configure:
> 
>     for V in $(PYVERS); do \
>         PYTHON=/usr/bin/python$$V ./configure --prefix=/usr \
>             --mandir=\$$\{prefix\}/share/man \
>             --includedir=\$$\{prefix\}/include/gdal \
>             --with-threads \
>             --with-grass=no \
>             --with-ecw=no \
>             --with-mrsid=no \
>             --with-jp2mrsid=no \
>             --with-libtiff=internal \
>             --with-geotiff=internal \
>             --with-jasper \
>             --with-netcdf \
>             --with-xerces \
>             --with-geos \
>             --with-sqlite \
>             --with-curl \
>             --with-pg \
>             --with-ogdi \
>             --with-mysql \
>             --with-perl \
>             --with-ruby \
>             --with-python \
>             --with-cfitsio=no; \
>         mv GDALmake.opt GDALmake.opt-$$V; \
>     done
> 
> So it looks like I am already building it with internal libtiff and 
> geotiff.
> 
> GDAL is now configured for x86_64-unknown-linux-gnu
> 
>   Installation directory:    /usr
>   C compiler:                gcc -g -O2
>   C++ compiler:              g++ -g -O2
> 
>   LIBTOOL support:           yes
> 
>   LIBZ support:              external
>   GRASS support:             no
>   CFITSIO support:           no
>   PCRaster support:          internal
>   NetCDF support:            yes
>   LIBPNG support:            external
>   LIBTIFF support:           internal (BigTIFF=yes)
>   LIBGEOTIFF support:        internal
>   LIBJPEG support:           external
>   LIBGIF support:            external
>   OGDI support:              yes
>   HDF4 support:              yes
>   HDF5 support:              yes
>   Kakadu support:            no
>   JasPer support:            yes (GeoJP2=no)
>   ECW support:               no
>   MrSID support:             no
>   GRIB support:              no
>   cURL support (wms/wcs/...):yes
>   PostgreSQL support:        yes
>   MySQL support:             yes
>   Xerces-C support:            yes
>   Expat support:             yes
>   ODBC support:              yes
>   PGeo support:              yes
>   OCI support:               no
>   SDE support:               no
>   DODS support:              no
>   SQLite support:            yes
>   DWGdirect support          no
>   PANORAMA GIS support:      no
>   INFORMIX DataBlade support:no
>   GEOS support:              yes
> 
> 
>   Old-gen python          no
>   SWIG Bindings:          python ruby perl
> 
>   Statically link PROJ.4:    no
>   enable OGR building:       yes
>   enable pthread support:    yes
>   hide internal symbols:     no
> 
> 
> I'll keep poking at this. Please let me know if you have any other ideas 
> to look at. I'll also check the system for any possible old packages or 
> libs lying around.
> 
> Thanks,
>   -Steve
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



More information about the gdal-dev mailing list