What do you think about a parameter IGNORE_INVALID, off by default like here
143cfab?

This way, a user has to consciously accept that he wants invalid geometries to be ignored or preprocess his data.

Personally I think that we should maintain same behavior for all Processing algorithms, including 3rd party backends. If one want to check/fix/reproject/etc layer before actual analysis, Processing provides all necessary tools for this: scripts, models and hooks.

@alexbruy @alexbruy Hi Alex and Matthias. I also think that fixing tools must be left separate from actual geoprocessing tools. The real issue here are tools that return wrong almost silently (logs are not very useful for the vast majority of users) because of geometry errors. Unfortunately we still have even worst cases: qgis tools returning silently wrong results even when input layers are ok.

@alexbruy what do you think about the approach in 143cfab?

@m-kuhn I think it is ok. But on other hand we can use this approach only with native algs. GDAL, SAGA and other algs will lack this feature and confuse users.

@volaya what is your opinion?

@alexbruy is there a proper solution that works with 3rd party algs as well?

@m-kuhn AFAIK there is no proper solution for this. Only workaround: export layer in compatible format excluding invalid geometries if checkbox is checked. But this will increase analysis time considerably and this again can be done with models/scripts/pre-execution hook without altering algorihtms code

I think that the more atomized the alg collection is, the better. If one needs to have several operations performed (clean + process), then the modeler can be used to wrap them. Easier algorithms are more useful and better to maintain.

@volaya I think we all agree on that part.

The question is what to do by default with input data that produce erroneous output.

• Write something to the log and continue (producing erroneous output).
• Abort algorithm with an error (unless the user consciously opted in to ignore such errors).