TIN Interpolation - output raster format and size issues

[Brent-Edwards]

Describe the bug

1. Produces an ArcInfo ASCII Grid, but defaults to tif extension.

2. The rows/cols and pixel sizes (x/y) are not respected - ex. with the default 0.10 size, the output raster reports:
   Origin
   283796,5.04147e+06
   Pixel Size
   0.09977998600000000107,-0.09982621899999999382

3. Break and structure lines are not respected - see TIN Interpolation Issue  #27048

How to Reproduce

QGIS and OS versions

QGIS version
3.8.3-Zanzibar
QGIS code revision
685d8b1
Compiled against Qt
5.11.2
Running against Qt
5.11.2
Compiled against GDAL/OGR
2.4.1
Running against GDAL/OGR
2.4.1
Compiled against GEOS
3.7.2-CAPI-1.11.0
Running against GEOS
3.7.2-CAPI-1.11.0 b55d2125
PostgreSQL Client Version
10.8
SpatiaLite Version
4.3.0
QWT Version
6.1.3
QScintilla2 Version
2.10.8
Compiled against PROJ
5.2.0
Running against PROJ
Rel. 5.2.0, September 15th, 2018
OS Version
Windows 10 (10.0)

Additional context

[elpaso]

Can you please attach a test project and data and a step-by-step procedure to reproduce?

[elpaso]

Btw, 3.8 is EOL, please confirm that this is still a bug in master (you can test the nightly versions) and/or in 3.4.x.

[Brent-Edwards]

As per @elpaso's request:

Here's the test project and data:
qgis_interp_bug_31970.zip

And the steps to produce it. Note that the extent is calculated from the pts layer. I've also tried rounding these values to solve the strange x/y resolution creep to no avail:

I do not recall the rows/cols and pixel sizes issue (issue 2 in my previous post) in versions prior to 3.6. The dialog/options regarding these parameters changed as well. See - https://github.com/qgis/QGIS/commit/84d155eaf0467204aa087b78c8b5d7a0f3d1c9bc

Issues 1 (format versus extension) and 3 (treatment of break/structure lines) seem to have always been present.

Thanks for any insight!

[gioman]

1. Produces an ArcInfo ASCII Grid, but defaults to tif extension.

the original core C++ plugin outputted ASC, while Processing now outputs by default TIFFs, I guess that when the tool was ported to QGIS it was assumed that the output of the algorithm was TIF.

[gioman]

3\. Break and structure lines are not respected

I always assumed that structure lines are closed lines, break are not. And when you have a layer with both, use break lines.

[gioman]

Here's the test project and data:
qgis_interp_bug_31970.zip

the attached project has

a point layer, that has not "val" column (as visible in your screenshot"

a polygon layer (not a line one) that I don not understand how it can be used in the TIN tool (if the TIN tool is not supposed to be used with polygons layers, then we should not show them in the tool GUI).

[gioman]

2\. 0.09977998600000000107,-0.09982621899999999382

the extent of the output and the pixels size are likely to not match perfectly, so there must be some rounding...

[Brent-Edwards]

Here's the test project and data:
qgis_interp_bug_31970.zip

the attached project has

a point layer, that has not "val" column (as visible in your screenshot"

a polygon layer (not a line one) that I don not understand how it can be used in the TIN tool (if the TIN tool is not supposed to be used with polygons layers, then we should not show them in the tool GUI).

Here's a new project file with the "val" column and the break lines as lines. See the red line in the "output" group (fid = 13) that crosses the input break lines.

qgis_interp_bug_31970_v2.zip

[Brent-Edwards]

2\. 0.09977998600000000107,-0.09982621899999999382

the extent of the output and the pixels size are lokely to not match perfectly, so there must be some rounding...

This is a valid point; however, to honor the pixel size (ex. 0.25) the tool could simply round the xmin/ymin coordinates DOWN to the nearest whole pixel size and the xmax/ymax UP to the nearest whole pixel size. When doing this manually through the extent parameter, the values are not honored. Padding with extra pixels (rows/columns) is not possible either.

[gioman]

o honor the pixel size (ex. 0.25) the tool could simply round the xmin/ymin coordinates DOWN to the nearest whole pixel size and the xmax/ymax UP to the nearest whole pixel size

this seems a good idea, but it would be a feature request (file it if you think so).

When doing this manually through the extent parameter, the values are not honored

I can't confirm this, at least accordingly to a quick test I just did

[Brent-Edwards]

When doing this manually through the extent parameter, the values are not honored

I can't confirm this, at least accordingly to a quick test I just did

Thanks for the reply! This is easy to confirm as stated in my original bug submission - 2. rows/cols and pixel sizes (x/y) are not respected - ex. with the default 0.10 size, the output raster reports:
Origin
283796,5.04147e+06
Pixel Size
0.09977998600000000107,-0.09982621899999999382

Also, as stated previously, I do not recall the rows/cols and pixel sizes issue in versions prior to 3.6. The dialog/options regarding these parameters changed as well. See - 84d155e.