Distorted and Misplaced Georeferencer Output

[Lunate-Lance]

What is the bug or the crash?

When georeferencing GDAL-supported ASCII Gridded XYZ file, the output is placed adjacent to, but south of, the bounds defined by the GCP and stretched along both axes proportional to the inverse of the input raster pixel size (0.125,-0.5). Setting the target resolution in the Georeferencer Transformation Settings has no effect.

This behavior is not present in the current LTR, 3.22.14.

Steps to reproduce the issue

In 3.28.2:

1. Open Georeferncer
2. Open Raster->Add attached ASCII Gridded XYZ File GR_Bug_Test_Raster.xyz (*removing .txt suffix)
3. In Transformation Settings, set Transform Type to Polynomial 1, Target SRS to EPSG: 26920, select "Load in QGIS when done"
4. Load attached GCP File "GR_Bug_Test_Raster.xyz.points" (*removing .txt suffix)
5. Click "Start Georeferencing" and examine output.

Relevant Files for Issue Reproduction ASCII Gridded XYZ file, final .txt suffix was added so I could upload it here*. NoData = 3333. GR_Bug_Test_Raster.xyz.txt

Shapefile of 4 points used to georeference the raster corners. GR_GCP_BUG_TEST.zip

GCP file generated by the georeferencer using the above raster and the shapefile points, final .txt suffix was added so I could upload it here*. GR_Bug_Test_Raster.xyz.points.txt

Versions

QGIS version 3.28.2-Firenze QGIS code revision b47e00ba601 Qt version 5.15.3 Python version 3.9.5 GDAL/OGR version 3.6.1 PROJ version 9.1.1 EPSG Registry database version v10.076 (2022-08-31) GEOS version 3.11.1-CAPI-1.17.1 SQLite version 3.39.4 PDAL version 2.4.3 PostgreSQL client version unknown SpatiaLite version 5.0.1 QWT version 6.1.6 QScintilla2 version 2.13.1 OS version Windows 10 Version 2009

Active Python plugins ImportPhotos 3.0.4 LAStools 1.4 processing_saga_nextgen 0.0.7 qfieldsync v4.2.0 valuetool 3.0.15 db_manager 0.1.20 grassprovider 2.12.99 MetaSearch 0.3.6 processing 2.12.99 sagaprovider 2.12.99

Supported QGIS version

• [X] I'm running a supported QGIS version according to the roadmap.

New profile

• [X] I tried with a new QGIS profile

Additional context

Pixels are non-square. Distortion is proportional to the inverse of the pixel dimensions. 0.125 m results in 8x stretch along that axis.

[roya0045]

Is the issue specific to this filetype? Could you give it a try in GDAL directly (assuming the points are in the same crs as the input).

[Lunate-Lance]

I will convert the input to tiff and see if the result differs. Will also try console gdal approach and report.

On Sat., Dec. 24, 2022, 10:10 Alex, @.***> wrote:

Is the issue specific to this filetype? Could you give it a try in GDAL directly (assuming the points are in the same crs as the input).

— Reply to this email directly, view it on GitHub https://github.com/qgis/QGIS/issues/51299#issuecomment-1364557331, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANZ4CPJBZPMKDNEQBXLJOF3WO4U7HANCNFSM6AAAAAATID6C4Q . You are receiving this because you authored the thread.Message ID: @.***>

[Lunate-Lance]

Filetype: I converted the ASCII Gridded XYZ file to a tif using Export->Save As. Results are identical to the XYZ file.

GDAL Console: Generated a GDAL script in the Georeferencer and executed the two commands (pasted below) sequentially in the OSGeo4W Shell. The results (pictured below) were distorted, but in a slightly different way. Same result with Thin Plate Spline chosen as the transform method.

Georeferencer generated GDAL Script:

gdal_translate -of GTiff -gcp 0 -60 386375 5.12137e+06 -gcp 60 -60 386435 5.12138e+06 -gcp 60 0 386436 5.12132e+06 -gcp 0 0 386376 5.12131e+06 "MyPath/GR_Bug_Test_Raster.xyz" "MyTempPath/GR_Bug_Test_Raster.xyz" gdalwarp -r near -order 1 -co COMPRESS=None -t_srs EPSG:26920 "MyTempPath/GR_Bug_Test_Raster.xyz" "MyPath/GR_Bug_Test_XYZ_GR_Console.tif"

[roya0045]

Thanks for taking the time to test things.

I tested in 3.22.1 to see if the behaviour was ok, I see that the destination point are Set in New-Brunswick, using an european crs and the layer is georeferenced in the middle of Africa in a squashed way I don't know if this issue is due to the points being out of bound or the project itself, or if there's truly something wrong going on with the georeferencer...

[Lunate-Lance]

Thanks for looking into it, Alex. The CRS of the shapefile should be a UTM (EPSG: 26920) not a specifically European CRS.

To be clear, I can't replicate this issue in 3.22.14 and I've successfully used this process for years in previous versions of QGIS.

Cheers, Lance

On Sat, Dec 24, 2022 at 2:00 PM Alex @.***> wrote:

Thanks for taking the time to test things.

I tested in 3.22.1 to see if the behaviour was ok, I see that the destination point are Set in New-Brunswick, using an european crs and the layer is georeferenced in the middle of Africa in a squashed way [image: image] https://user-images.githubusercontent.com/12854129/209450856-8011022c-6087-40c7-964a-4d0fe471a88a.png I don't know if this issue is due to the points being out of bound or the project itself, or if there's truly something wrong going on with the georeferencer...

— Reply to this email directly, view it on GitHub https://github.com/qgis/QGIS/issues/51299#issuecomment-1364583115, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANZ4CPJ6XWS5BGCPFIZWXX3WO5P55ANCNFSM6AAAAAATID6C4Q . You are receiving this because you authored the thread.Message ID: @.***>

[roya0045]

That makes sens, I just forgot it reused the last crs chosen and I used that one for tests. My mistake, but with UTM 20N it lands in South America In the same sqasqued shaped as my screenshot. There's indeed something weird going on with the results.