Make extent optional in GDAL tools, where possible

[ekcomputer]

What is the bug or the crash?

When using gdal_polygonize via the "Rasterize (Vector to Raster)" geoprocessing tool, an Output extent is required and there are three options (map canvas, from a layer, or draw). All of these Output extent methods produce a bounding box in the proper text box in the geoprocessing window. However, when the project SRS differs from the input layer SRS, the coordinates for this box are given in the project CRS (and noted in brackets afterwards, i.e. [ ESRI:102001] ), but there is no flag for gdal_rasterize to note the different CRS. The coordinates simply are used with the -te option in the GDAL call. Using the -a_srs flag only controls the output SRS, not the SRS used to interpret the output bounding box coordinates.

Steps to reproduce the issue

1. Note uploaded sample files (and unzip them): GLOWABO_YF_comparison.zip - vector dataset in EPSG:4326 GLOWABO_YF_comparison_albers.zip - vector dataset in EPSG:102001

2. Set CRS to ESRI:102001

3. Run Rasterize (Vector to Raster) tool as follows: The -a_srs flag for output SRS makes no difference in the results.

4. Note auto-populated GDAL command line call: gdal_rasterize -l GLOWABO_YF_comparison -burn 1.0 -ts 3000.0 800.0 -a_nodata 99.0 -te -2365593.1907 3495948.8892 -1644215.0343 3945175.3144 -ot Byte -of GTiff -a_srs ESRI:102001 GLOWABO_YF_comparison.shp C:/Users/ekyzivat/AppData/Local/Temp/processing_QAcCiu/d4ae4ea4cd874051bdfe1ca5f4ba6fed/OUTPUT.tif

5. Results should show pixelated lakes for every lake in the input vector dataset; however it is all nodata because gdal interpreted the coordinates as coming from the SRS of the input vector, even though QGIS filled them in in the project CRS.

6. Correct results can be obtained by either setting the project CRS to EPSG:4326, or running on the re-projected file GLOWABO_YF_comparison_albers.zip

Versions

QGIS version 3.16.12-Hannover QGIS code revision be6cb030 Compiled against Qt 5.15.2 Running against Qt 5.15.2 Compiled against GDAL/OGR 3.3.2 Running against GDAL/OGR 3.3.3 Compiled against GEOS 3.10.0-CAPI-1.16.0 Running against GEOS 3.10.0-CAPI-1.16.0 Compiled against SQLite 3.35.2 Running against SQLite 3.35.2 PostgreSQL Client Version 13.0 SpatiaLite Version 5.0.1 QWT Version 6.1.3 QScintilla2 Version 2.11.5 Compiled against PROJ 8.1.1 Running against PROJ Rel. 8.1.1, September 1st, 2021 OS Version Windows 10 Version 2009 Active python plugins db_manager; MetaSearch; processing

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

I would suggest auto-converting the bounding box coordinates to match the input vector layer. Then gdal will receive the output coordinates in the CRS it is expecting.

Alternatively, you should be able to make the required "Output extent" field optional, since the GDAL -te option is also optional.

If these changes can't be made, you could make a note that the "Output extent" SRS must match the input layer SRS.

In terms of other documentation, you could also note that no re-projection is supported (same as the GDAL command).

[gioman]

@ekcomputer for non core algorithms is expected to be everything in the same CRS (inputs, parameters, etc.).

[ekcomputer]

Ah, okay. I have been using QGIS every day for a year, and didn't realize this. Probably because I am always working with the same projection. Thanks for pointing it out. Please consider my requests for making the extent optional and adding to the documentation from within the geoprocessing window. I think they would help prevent further confusion.

Alternatively, you should be able to make the required "Output extent" field optional, since the GDAL -te option is also optional. If these changes can't be made, you could make a note that the "Output extent" SRS must match the input layer SRS. In terms of other documentation, you could also note that no re-projection is supported (same as the GDAL command).

[DelazJ]

Just for reference, there's a mention at https://docs.qgis.org/testing/en/docs/user_manual/processing/toolbox.html#a-note-on-projections

[agiudiceandrea]

@ekcomputer please see https://github.com/qgis/QGIS/pull/47205.