[gdal-dev] GeoTIFF in South Africa

[Even Rouault]

Javier,

can you post the output of "listgeo sa.tif" (on the original GeoTIFF) ?  
It would be interesting to see if they correctly use the 
CT_TransvMercator_SouthOrientated ProjCoordTransGeoKey

I don't remember a change that would explicily try to respect the 
negative sign of the x-pixelsize parameter in gdalwarp as those are 
rather untypical, but it might be a side effect of other changes. For 
those untypical geotransforms, QGIS will use GDAL's AutoWarpVRT 
functionality, which indeed has a runtime cost.

You may generate a "correctly" oriented file by specifying explicit -te 
to gdalwarp

Even

Le 25/09/2025 à 17:24, Javier Jimenez Shaw via gdal-dev a écrit :
> Hi
>
> I got a GeoTIFF from South Africa that is displayed in the 
> Mediterranean sea in QGIS.
>
> $ gdalinfo sa.tif
> Driver: GTiff/GeoTIFF
> Files: sa.tif
> Size is 1305, 909
> Coordinate System is:
> PROJCRS["Hartebeesthoek94 / Lo21",
>     BASEGEOGCRS["Hartebeesthoek94",
> ...
>     ID["EPSG",2049]]
> Data axis to CRS axis mapping: 1,2
> Origin = (-43632.855010000006587,-3629566.022050000261515)
> Pixel Size = (0.275826758620690,-0.275760660066007)
> Metadata:
>   AREA_OR_POINT=Area
>   TIFFTAG_SOFTWARE=pix4dmapper
> Image Structure Metadata:
>   COMPRESSION=LZW
>   INTERLEAVE=PIXEL
>   PREDICTOR=2
>
> As you can see, the Origin is very negative, and in Lo21 it should be 
> positive.
> Ok, lets change the geotransform parameters:
>
> $ gdal_translate -a_gt 43632.8550100000 -0.275760660 0 3629566.0220500 
> 0 0.27576066 -co COMPRESS=LZW -co PREDICTOR=2 sa.tif sa.located.tif
> $ gdalinfo sa.located.tif
> Driver: GTiff/GeoTIFF
> Files: sa.located.tif
> Size is 1305, 909
> Coordinate System is:
> PROJCRS["Hartebeesthoek94 / Lo21",
>     BASEGEOGCRS["Hartebeesthoek94",
>         DATUM["Hartebeesthoek94",
> ...
>     ID["EPSG",2049]]
> Data axis to CRS axis mapping: 1,2
> Origin = (43632.855009999999311,3629566.022049999795854)
> Pixel Size = (-0.275760660000000,0.275760660000000)
>
> That appears properly located in QGIS. But I think that due to the 
> signs in the pixel size, it is performing really bad (it is not doing 
> some optimizations)
>
> I run gdalwarp hoping that it changes it. And it does in GDAL 3.8.4
> $ gdalinfo --version
> GDAL 3.8.4, released 2024/02/08
> $ gdalwarp sa.located.tif sa.cog.3.8.4.tif -of COG
> $ gdalinfo sa.cog.3.8.4.tif
> Driver: GTiff/GeoTIFF
> Files: sa.cog.3.8.4.tif
> Size is 1305, 909
> Coordinate System is:
> PROJCRS["Hartebeesthoek94 / Lo21",
>     BASEGEOGCRS["Hartebeesthoek94",
>     ID["EPSG",2049]]
> Data axis to CRS axis mapping: 1,2
> Origin = (43272.987348700000439,3629816.688489940017462)
> Pixel Size = (0.275760660000079,-0.275760660000079)
>
> See how it changes the origin and the signs of the pixel size
>
> However in 3.11.4 it is different
>
> $ gdalinfo sa.cog.3.11.4.tif
> Driver: GTiff/GeoTIFF
> Files: sa.cog.3.11.4.tif
> Size is 1305, 909
> Coordinate System is:
> PROJCRS["Hartebeesthoek94 / Lo21",
>     BASEGEOGCRS["Hartebeesthoek94",
> ...
>     ID["EPSG",2049]]
> Data axis to CRS axis mapping: 1,2
> Origin = (43632.855009999999311,3629816.688489940017462)
> Pixel Size = (-0.275760660000000,-0.275760660000000)
>
> Having the negative pixel size for the first coordinate is affecting 
> the performance in QGIS?
>
> Is there a better way to do all this?
>
> Thank you,
> Javier
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250925/ce3d122d/attachment.htm>