GeoTIFF geotransform update fails in some cases

[Ari Jolma]

An attempt to update a GeoTIFF with a tiepoint+scale (normal geotransform) with one that requires ModelTransformationTag results in no apparent change because the tiepoint+scale values are not (and really cannot be) removed the way the libtiff api works.

For instance, if we do so we can end up with a file like:

   Tagged_Information:
      ModelTiepointTag (2,3):
         0                0                0                
         440720           3751320          0                
      ModelPixelScaleTag (1,3):
         60               60               0                
      ModelTransformationTag (4,4):
         2                0                0                0                
         0                3                0                0                
         0                0                0                0                
         0                0                0                1     

Then the GTiff driver just ignores the modeltransformtag since the tiepoint+pixelscale is still present.

[Ari Jolma]

This is not a bug, this is a feature. WriteGeoTIFFInfo is selective about when it writes the geotransform to the tiff file. The assumption is probably that this function is called only when new geotiffs are created - thus the support for editing the info of existing files is not good.

I'm changing this to an enhancement wish. There should be a way to force a new geotransform or directly set tiff fields through GDAL.

[warmerdam]

Ari,

The GeoTIFF driver *should* support update of the geotransform. There were some quirks at one point which were corrected (#2546). Could you provide a specific sequence to reproduce the problem you are seeing?

[Ari Jolma]

$ds = Geo::GDAL::Dataset::Open('L4123G1.tiff','Update');
@a = $ds->GeoTransform;
print "@a\n";
$a[5] *= -1;
@a = $ds->GeoTransform(@a);
print "@a\n";

Prints change from -2 to 2 as the geottransform[5], but the change does not propagate to disk, when this is run again, the change is again -2 to 2.

I think the issue is clear when you look at WriteGeoTIFFInfo, which does not write the trasform to the file if transform[5] is < 0. Thus the change from 2 to -2 is irreversible. I just got bitten by this because gdal_grid produces geotiffs with 2, which is not common.

[Even Rouault]

I understand what happens but doesn't really know how to solve. When you want to write a transform[5] >= 0, we can't use TIFFTAG_GEOPIXELSCALE and TIFFTAG_GEOTIEPOINTS. So we end up a few lines later (l2940) where we write a TIFFTAG_GEOTRANSMATRIX... in addition to the old tags. In the read code, we try first to read the TIFFTAG_GEOPIXELSCALE and TIFFTAG_GEOTIEPOINTS tags, so that explains why you get the old value. A listgeo on your updated file will show you that the GeotransformMatrix is written but ignored. Anyway, I doubt very much that the geotiff specification allows for all those tags to be present at the same time.

Other point Ari, you need that to correct the output of gdal_grid ? So there's probably a bug in gdal_grid ? I'd imagine that you're not supposed to fix the geotransform afterwards. Or if gdal_grid effectively writes an image topdown, you will need to invert both the y-resolution and the scanlines to get something consistant.

[warmerdam]

Updated main bug description.

I agree with Even's analysis and it will be difficult to correct this without changes to libtiff that make it possible to remove a tag from an existing directory. I'm going to leave this open but I do not anticipate it being resolved in the near future.

[Ari Jolma]

There no bug in gdal_grid. I stumbled upon this because my code (libral, where it reads from GDAL to libral memory raster) ignored the sign of geotransform[5]. I've now changed that, but the geotiff that I changed on false grounds can't be easily changed back to what it was after gdal_grid.

[Even Rouault]

Now that libtiff has support for TIFFUnsetField, this should be achievable

[warmerdam]

I have implemented simple logic to clear existing geotransform/tiepoints data before writing anew in trunk (r15985). Also a brief autotest (r15984).