[gdal-dev] GDAL 1.7.3 can't read tiff written by GDAL 1.11

[Even Rouault]

Le mardi 22 juillet 2014 00:02:32, Eli Adam a écrit :
> On Mon, Jul 21, 2014 at 1:46 PM, Even Rouault
> 
> <even.rouault at mines-paris.org> wrote:
> > Le lundi 21 juillet 2014 22:18:27, Eli Adam a écrit :
> >>  Hi all,
> >> 
> >> I've got some recent tiff data that can't be read by GDAL 1.7.3
> >> ("gdalinfo.exe has stopped working").  It appears to work fine with
> >> GDAL 1.11.  The output from GDAL 1.11 can't be read by GDAL 1.7.3
> >> either.  Hmm, oddly it seems to work with GDAL 1.6.
> >> 
> >> I have an older MapServer and GDAL that I'd like to use with new data
> >> without updating MapServer and GDAL so my goal is find a way to use or
> >> alter the data so it is usable by GDAL 1.7.3.  I also want to know if
> >> the data is valid and complies with the the geotif specification.
> > 
> > Looks reasonable at first sight
> > 
> >> This is on Windows 7 and OSGeo4W although I also had some similar
> >> issues on Ubuntu 10.04.  Below are GDAL 1.11 version, gdalinfo with
> >> debug, listgeo, and finally gdal_translate output that can't be read
> >> by GDAL 1.7.3 (attached).  There are messages about "GTIFF: converting
> >> geokey to meters to fix bug in old libgeotiff"
> > 
> > Yes, tricky issue with non-meter linear unit. See ticket
> > https://trac.osgeo.org/gdal/ticket/3901 to get heavily confused.
> 
> I read that and am somewhat confused :) but have a basic understanding
> of it as well now.  I tried gdal_translate -projwin 7367110 520505
> 7367120 520495 06S08W19.tif 06S08W19_gdal1_11_ouput3.tif --config
> GTIFF_LINEAR_UNITS BROKEN to try and make a broken tiff to see if it
> would work.  GDAL 1.7.3 can't read the output of that either.

Lol, fortunately GTIFF_LINEAR_UNITS BROKEN will not produce a broken geotiff. 
It is meant at trying to improve things when you notice that there's a 
conversion between meters and the advertized linear units that hasn't been 
done (or has been done twice I don't remember the details).

> 
> > Related to that, I guess your listgeo is from libgeotiff 1.3 or older
> > since it should display ProjFalseEastingGeoKey: 2500000.000000 m
> > normally
> 
> Using the OSGeo4W installer libgeotiff appears to be 1.3.0-3 (is there
> a command line option to determine libgeotiff or libtiff version?).
> 
> I just looked these up on EPSG and now my basic understanding of
> ticket 3901 is faltering.
> http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:c
> rs:EPSG::6558&entity=urn:ogc:def:crs:EPSG::6559&reportDetail=long&style=urn
> :uuid:report-style:default-with-urn&style_name=OGP%20Default%20With%20Urn&t
> itle=Oregon_foot_meter
> 
> Is it incorrect to report ProjFalseOriginEastingGeoKey (Double,1):
> 8202099.73753281 with ProjLinearUnitsGeoKey (Short,1): Linear_Foot?

It is correct, but the listgeo output also lists afterwards something like :

Projection Method: CT_LambertConfConic_2SP
   ProjFalseOriginLatGeoKey: 43.666667 ( 43d40' 0.00"N)
   ProjFalseOriginLongGeoKey: -120.500000 (120d30' 0.00"W)
   ProjStdParallel1GeoKey: 44.333333 ( 44d20' 0.00"N)
   ProjStdParallel2GeoKey: 46.000000 ( 46d 0' 0.00"N)
   ProjFalseEastingGeoKey: 2500000.000000 m
   ProjFalseNorthingGeoKey: 0.000000 m
Projection Linear Units: 9002/foot (0.304800m)

where ProjFalseEastingGeoKey is normalized in meters.

> 
> >> and "TIFFReadDirectory:
> >> Warning, Unknown field with tag 2457 (0x999) encountered."
> > 
> > Cannot find its definition in the TIFF tag catalog, but shouldn't cause
> > issues. This will be ignored
> > 
> >> Further
> >> below the GDAL1.11 information, is GDAL 1.7.3 showing that it can't be
> >> read and the error output.
> >> 
> >> Do 06S08W19_gdal1_11_ouput2.tif and 06S08W19.tif conform to the geotif
> >> specification and contain valid data? Any suggestions on how to keep
> >> using my older install without updating?
> > 
> > I managed to read your attachef file with latest state of 1.7 branch
> > (1.7.3 with a few additional fixes) on Linux, and cannot see anything in
> > the log between this and 1.7.3 that could explain the issue. However, as
> > more or less expected, the georeferencing is not read correctly (since
> > #3901 was fixed in 1.8) and the false easting value is multiplied by 1.
> > / 0.3048.
> 
> Would different versions of libgeotiff explain it working (with
> incorrect georeferencing?) for you and erroring out for me?

No idea why it crashes on osgeo4w. Well, I somehow remember that there have 
been ABI changes in libgeotiff between versions, but if that was the case of a 
mismatch between actual libgeotiff ABI and the one expected by the GDAL build, 
then it would likely crash on most geotiff files, and not that one only. Does it 
crash only on that geotiff ? Anyway that's an old version, and you cannot undo 
the past, just try to make the future better ;-)

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html