Greetings, Kevin makes a well-reasoned argument that my initial patch was not general enough. It is true that in my application the x,y pixel sizes were equal so I did not detect the bug.
I am a geospatial novice and I derived my formulae from a response to a question I posted on the GIS StackExchange [1]. The development of the patch with write support was coordinated on the GDAL mailing list [2] and GitHub [3]. Fully general support for rotation would be desirable. Test cases for x=y, x!=y would help verify correctness. I agree that the given semantics for world files implies that xPixelSize and yPixelSize should be swapped in adfGeoTransform[2] and adfGeoTransform[4]. And although I have not fully digested the mathematics, I also agree that it makes sens to scale the x and y directions as suggested for adfGeoTransform[0] and adfGeoTransform[3]. I concur that the negative determinant issue seems to be not strictly related to the initial rotation support. However it would make sense to address both rotation issues in the same patch. Rather than forcing a pixel size to be negative and generating possibly incompatible ENVI headers, would it make sense to handle the cases det(GT)>0, det(GT)<=0 separately and retransform if necessary? In summary, although I would be happy to revise my patch as time allows, it sounds like Kevin's made a very good case and would be able to push something more quickly, so go for it! It would be nice to have some example GIS files exhibiting these properties to get a visual intuition for these transformations. Thanks for uncovering the issue and helping me learn more about the algebra of geospatial transformations. Taylor Alexander Brown [1] https://gis.stackexchange.com/questions/229952/rotate-envi-hyperspectral-imagery-with-gdal [2] https://lists.osgeo.org/pipermail/gdal-dev/2017-February/046127.html [3] https://github.com/OSGeo/gdal/pull/197 _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
