Fix gdal command

[roya0045]

Description

Minor bug/typo? encountered while digging into #46414

@nyalldawson Would you know if this is a typo, I assume it is.

Though strangely with this error, it yielded the same results as our standard process, now the outputs are different, maybe there is another extra negative somewhere or I'm just dealing with weird cases? Still not sure why already georeferenced images are handling badly regardless of the method.

[agiudiceandrea]

@roya0045 I think the minus sign is needed.
AFAIK, in the Georeferencer, for a non georeferenced raster, the "Source Y" coordinate is always negative: the top-left corner of the source raster to be georeferenced has 0,0 coordinates with the X values increasing toward the "right" and the Y values increasing "upwards" (so they are negative "downwards"); in gdal_translate -gcp, the <pixel> and <line> values are also top-left based, with the <pixel> values increasing toward the "right" but with the <line> values increasing "downwards" (so they must be positive "downwards").

[roya0045]

@roya0045 I think the minus sign is needed. AFAIK, in the Georeferencer, for a non georeferenced raster, the "Source Y" coordinate is always negative: the top-left corner of the source raster to be georeferenced has 0,0 coordinates with the X values increasing toward the "right" and the Y values increasing "upwards" (so they are negative "downwards"); in gdal_translate -gcp, the and values are also top-left based, with the values increasing toward the "right" but with the values increasing "downwards" (so they must be positive "downwards").

So this would only be an issue for raster that are already georeferenced? That's possible.

[agiudiceandrea]

So this would only be an issue for raster that are already georeferenced? That's possible.

Yes. If the added raster has a geotransform set, then the "Source X" and "Source Y" are incorrectly not expressed as raster pixels coordinates, but as geotransformed coordinates.
So, I think the issue could be fixed in one of two ways:

• always remove any raster geotransform when the raster is added to the Georeferencer map canvas
• or, make sure to translate the geotransformed coordinates to raster pixels coordinates

[roya0045]

Though the issue is not the gdal expression exported but the process itself. Maybe @rouault would be able to tell if gdal only works with pixel coordinates or projected coords once an image is georeferenced.

[rouault]

if gdal only works with pixel coordinates or projected coords once an image is georeferenced.

it depends on utilities and options used. It is normally clearly documented. e.g if using gdal_translate, -srcwin is in pixel coordinates and -projwin in georeferenced coordinates

[agiudiceandrea]

if using gdal_translate, -srcwin is in pixel coordinates and -projwin in georeferenced coordinates

@rouault, AFAIK this is not the case for gdal_translate -gcp option, in which <pixel> and <line> values are always in raster pixels coordinates even if the source raster already has a geotransform set, isn't it?

[roya0045]

@agiudiceandrea yeah it works fine with non-georeferenced images, in the georeferencer the top-left corner is 0,0 and the image has negative y, so making them positive makes the command work.

Though I have reservations about removing an transformation on the image. If someone would want to adjust something they would have to import the geoerefenced image in the canvas to get the coordinates of the existing pixel. This would be an instance where the user would want to correct the deformation or perform a simple transform on an image that is already georeferenced and 'deformed'. If they have the original points that would be doable.

[rouault]

for gdal_translate -gcp option, in which and values are always in raster pixels coordinates even if the source raster already has a geotransform set, isn't it?

yes

[roya0045]

@agiudiceandrea I thinnk the best solution would be to add a coord to the datapoint, currently the 'pixelcoord' is the position in the georeferencer, it's not the true coordinate of the chosen pixel, it's the rastercoord.

I can check into reworking the code and making sure the raster coord gets properly converted into the true pixel coords. That way there is no need for finicking around with a 'hack' (the - in the gdal script) and would be more consistent.

@nyalldawson does that sounds like a reasonable approach?

[roya0045]

Needed code seem to be mostly present, though convoluted. Will investigate the issue.