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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
