Giovanni,
gdalwarp takes the absolute value of the second tr value, so -tr 10 -10
is understood as -tr 10 10
It is expected that gdalinfo reports a negative value for the pixel size
factor for the vertical axis, as in GeoTIFF when the image is north-up,
the first line of the image is intended to be the one displayed at the
top of your screen, and as the line number of your screen increase from
the top of your screen to the bottom, northings or latitudes increase
from the bottom to the top, hence the negative sign...
More detailed equivalent explanation at
https://gis.stackexchange.com/a/229807/218992 (you can ignore the
paragraph "As to why the image flipped..." which is specific to the
question in that stackexchange thread)
Even
Le 19/11/2023 à 02:15, Giovanni Anconitano via gdal-dev a écrit :
Hello,
I have a question about how to properly set the -tr flag when using
gdalwarp.
In particular, I'm using gdalwarp for resampling a GeoTiff from its
original resolution to a target resolution.
Let's consider, for simplicity, the original pixel size equal to (5m,
5m) and the target resolution equal to (10m, 10m).
This is the command I use: gdalwarp -tr 10 -10 input.tif output.tif
I'm using a negative <yres> because when I open the GeoTiff file in
QGIS, or if I use gdalinfo, I get a pixel size equal to (5, -5) for
the source raster.
Is it correct to use a negative <yres> with gdalwarp? I also tried -tr
10 10, but the result seems to be the same as the case in which I use
-tr 10 -10.
In both cases gdalinfo and QGIS display (10,-10) as the pixel size.
How does gdalwarp treat a negative yres value?
Thank you
Giovanni
*
*Fai crescere le giovani ricercatrici e i giovani ricercatori*
*
*con il 5 per mille alla Sapienza
*
Scrivi il codice fiscale dell'Università *80209930587
Cinque per mille <https://www.uniroma1.it/it/node/23149>*
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
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
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
