<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Javier,</p>
<p>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</p>
<p>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.</p>
<p>You may generate a "correctly" oriented file by specifying
explicit -te to gdalwarp</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 25/09/2025 à 17:24, Javier Jimenez
Shaw via gdal-dev a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CADRrdKshSiVzmEw50tGi2qm+_yYcGwGHxAKGsJv9_rSEG+Th5A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi</div>
<div><br>
</div>
<div>I got a GeoTIFF from South Africa that is displayed in the
Mediterranean sea in QGIS.</div>
<div><br>
</div>
<div><span style="font-family:monospace">$ gdalinfo sa.tif <br>
Driver: GTiff/GeoTIFF<br>
Files: sa.tif<br>
Size is 1305, 909<br>
Coordinate System is:<br>
PROJCRS["Hartebeesthoek94 / Lo21",<br>
BASEGEOGCRS["Hartebeesthoek94",</span></div>
<div><span style="font-family:monospace">...<br>
ID["EPSG",2049]]<br>
Data axis to CRS axis mapping: 1,2<br>
Origin = (-43632.855010000006587,-3629566.022050000261515)<br>
Pixel Size = (0.275826758620690,-0.275760660066007)<br>
Metadata:<br>
AREA_OR_POINT=Area<br>
TIFFTAG_SOFTWARE=pix4dmapper<br>
Image Structure Metadata:<br>
COMPRESSION=LZW<br>
INTERLEAVE=PIXEL<br>
PREDICTOR=2</span><br>
<br>
</div>
<div>As you can see, the Origin is very negative, and in Lo21 it
should be positive.</div>
<div>Ok, lets change the geotransform parameters:</div>
<div><br>
</div>
<div><span style="font-family:monospace">$ 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</span></div>
<div><span style="font-family:monospace">$ gdalinfo
sa.located.tif <br>
Driver: GTiff/GeoTIFF<br>
Files: sa.located.tif<br>
Size is 1305, 909<br>
Coordinate System is:<br>
PROJCRS["Hartebeesthoek94 / Lo21",<br>
BASEGEOGCRS["Hartebeesthoek94",<br>
DATUM["Hartebeesthoek94",<br>
...<br>
ID["EPSG",2049]]<br>
Data axis to CRS axis mapping: 1,2<br>
Origin = (43632.855009999999311,3629566.022049999795854)<br>
Pixel Size = (-0.275760660000000,0.275760660000000)</span><br>
<br>
</div>
<div>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)</div>
<div><br>
</div>
<div>I run gdalwarp hoping that it changes it. And it does in
GDAL 3.8.4</div>
<div><span style="font-family:monospace">$ gdalinfo --version<br>
GDAL 3.8.4, released 2024/02/08</span></div>
<div><span style="font-family:monospace">$ gdalwarp
sa.located.tif sa.cog.3.8.4.tif -of COG<br>
$ gdalinfo sa.cog.3.8.4.tif<br>
Driver: GTiff/GeoTIFF<br>
Files: sa.cog.3.8.4.tif<br>
Size is 1305, 909<br>
Coordinate System is:<br>
PROJCRS["Hartebeesthoek94 / Lo21",<br>
BASEGEOGCRS["Hartebeesthoek94",<br>
ID["EPSG",2049]]<br>
Data axis to CRS axis mapping: 1,2<br>
Origin = (43272.987348700000439,3629816.688489940017462)<br>
Pixel Size = (0.275760660000079,-0.275760660000079)</span></div>
<div><br>
</div>
<div>See how it changes the origin and the signs of the pixel
size</div>
<div><br>
</div>
<div>However in 3.11.4 it is different</div>
<div><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:monospace">$ gdalinfo
sa.cog.3.11.4.tif<br>
Driver: GTiff/GeoTIFF<br>
Files: sa.cog.3.11.4.tif<br>
Size is 1305, 909<br>
Coordinate System is:<br>
PROJCRS["Hartebeesthoek94 / Lo21",<br>
BASEGEOGCRS["Hartebeesthoek94",<br>
...<br>
ID["EPSG",2049]]<br>
Data axis to CRS axis mapping: 1,2<br>
Origin = (43632.855009999999311,3629816.688489940017462)<br>
Pixel Size = (-0.275760660000000,-0.275760660000000)</span><br>
<br>
</div>
<div>Having the negative pixel size for the first coordinate is
affecting the performance in QGIS? </div>
<div><br>
</div>
<div>Is there a better way to do all this?</div>
<div><br>
</div>
<div>Thank you,</div>
<div>Javier</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>