ENVI dataset geotransform

[rsoconnor]

There is a possible bug in file "envidataset.cpp" in line 567.

In the function WriteProjectionInfo

    osLocation.Printf( "1, 1, %.15g, %.15g, %.15g, %.15g", 
                       adfGeoTransform[0], adfGeoTransform[3], 
                       adfGeoTransform[1], fabs(adfGeoTransform[5]) );

The last argument is hardcoded to be always positive. This will result in an incorrect transform if the true value is negative when the file is read back in.

I believe it should be:

    osLocation.Printf( "1, 1, %.15g, %.15g, %.15g, %.15g", 
                       adfGeoTransform[0], adfGeoTransform[3], 
                       adfGeoTransform[1], -adfGeoTransform[5] );

[antonio]

Small test program to reproduce the issue

[antonio]

Please find attached a small test program to reproduce the issue and a patch implementing the solution suggested by rsoconnor (including a regression test).

Anyway I'm not sure that the proposed solution is OK since elements 6 and 7 of the "map info" parameter (see ​http://www.exelisvis.com/docs/ENVIRasterMetaData.html) should be x and y pixel sizes and I doubt they can have negative values.

The attached patch fixes the issue in GDAL but I don't know if it produces files that actually compatible with IDL/ENVI.

[Jukka Rahkonen]

The fix feels safe from the GDAL point of view because in vast majority of cases the value of Y coordinate is decreasing from top to down and the result would be just the same. In optimal case we would have a real sample file created by ENVI and showing the Y value increasing from top to down. By reading the documentation about ENVI header file structure it is impossible to know how the "map info" field of such image would look like.

[Even Rouault]

All those tickets have more than one year and nobody has acted on it, so the priority is not so high

[Even Rouault]

Probably obsoleted by the fix done in #1778