TIN interpolation return nodata

[j3r3m1]

What is the bug or the crash?

I am currently facing an issue in an other plugin (UMEP-dev/UMEP#704), itself running the "qgis:tininterpolation" with a specific dataset. In most cases, it works well and return the expected results but in some other situations the result return nodata for all pixels and I cannot explain it.

Steps to reproduce the issue

Here is an example of dataset creating the bug: test.zip

Here is the settings used to run the algorithm:

processing.run("qgis:tininterpolation",
 {'INTERPOLATION_DATA':'/tmp/test.gpkg|layername=urock_output::~::0::~::5::~::0',
'METHOD':0,
'EXTENT':'909898.389300000,910721.734300000,6460253.712500000,6461079.670900000 [EPSG:2154]',
'PIXEL_SIZE':3,
'OUTPUT':'/tmp/final.tif'})

Versions

<style type="text/css"> p, li { white-space: pre-wrap; } </style>

QGIS version	3.38.0-Grenoble	QGIS code branch	Release 3.38
Qt version	5.15.8
Compiled against Python	3.12.4	Running against Python	3.12.7
Compiled against GDAL/OGR	3.9.1	Running against GDAL/OGR	3.9.2
PROJ version	9.4.1
EPSG Registry database version	v11.006 (2024-03-13)
GEOS version	3.12.2-CAPI-1.18.2
Compiled against SQLite	3.46.0	Running against SQLite	3.47.0
PDAL version	2.7.2
PostgreSQL client version	unknown
SpatiaLite version	5.1.0
QWT version	6.3.0
QScintilla2 version	2.14.1
OS version	Ubuntu 22.04.5 LTS
Active Python plugins
firstaid	3.0.3
plugin_reloader	0.9.3
lizmap	4.2.4
processing_umep	2.1.1
pluginbuilder3	3.2.1
OSMDownloader	1.0.3
coolparkstool	0.0.3
quick_map_services	0.19.34
ede_interpolation	0.3
QuickOSM	2.2.3
processing	2.12.99
MetaSearch	0.3.6
grassprovider	2.12.99
db_manager	0.1.20

QGIS version 3.38.0-Grenoble QGIS code branch [Release 3.38](https://github.com/qgis/QGIS/tree/release-3_38) Qt version 5.15.8 Compiled against Python 3.12.4 Running against Python 3.12.7 Compiled against GDAL/OGR 3.9.1 Running against GDAL/OGR 3.9.2 PROJ version 9.4.1 EPSG Registry database version v11.006 (2024-03-13) GEOS version 3.12.2-CAPI-1.18.2 Compiled against SQLite 3.46.0 Running against SQLite 3.47.0 PDAL version 2.7.2 PostgreSQL client version unknown SpatiaLite version 5.1.0 QWT version 6.3.0 QScintilla2 version 2.14.1 OS version Ubuntu 22.04.5 LTS

Active Python plugins
firstaid
3.0.3
plugin_reloader
0.9.3
lizmap
4.2.4
processing_umep
2.1.1
pluginbuilder3
3.2.1
OSMDownloader
1.0.3
coolparkstool
0.0.3
quick_map_services
0.19.34
ede_interpolation
0.3
QuickOSM
2.2.3
processing
2.12.99
MetaSearch
0.3.6
grassprovider
2.12.99
db_manager
0.1.20

Supported QGIS version

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

New profile

• I tried with a new QGIS profile

Additional context

No response

[agiudiceandrea]

The "TIN Interpolation" processing algorithm (qgis:tininterpolation) is not a GDAL algorithm.

Anyway, I can confirm the issue also running QGIS 3.40.3 and QGIS 3.41.0-Master edc5453 on Windows 10 (OSGeo4W).

It looks like the issue occurs depending on the order of the points in the layer.

For example, the randomorder.zip layer, which contains the same features of the provided layer but in a different order (it was generated from the provided layer using the "Order by expression" processing algorithm and the randf(0, 1) expression), makes the "TIN Interpolation" processing algorithm correctly output a TIN interpolated raster layer in about 5 seconds

while the provided layer makes the "TIN Interpolation" processing algorithm incorrectly output a TIN interpolated raster layer with only nodata values and the process takes about 10 minutes.

[j3r3m1]

Thank you @agiudiceandrea it works perfectly for the case proposed and this trick clearly improves the performance of the process.