catch and handle topology exceptions when splitting geometries

[tyrasd]

Description

After #272 (version 0.6.0), topology exceptions thrown during the intersection calculations in the GeometrySplitter class are not (always) catched anymore. This solves the problem by adding an additional try-catch block and returning an empty geometry if a topology exception is occurring.

Checklist

• My code follows the code-style rules, and I have checked on the static analyses and benchmark (if applicable) results
• I have commented my code
• I have written javadoc (required for public methods)
• I have added sufficient unit tests
• I have made corresponding changes to the documentation
• I have updated the CHANGELOG.md
• I have adjusted the examples or created an issue in the corresponding repository
• I have adjusted the benchmark or created an issue in the corresponding repository

[FabiKo117]

We used to say that with the OSHDB the user has access to erroneous OSM data as well, including features that were falsely tagged, or also had a broken geometry. How would this be affected with this fix here? Could someone still perform an analysis looking at such data that has/had some issues regarding its topology through the OSHDB?

[tyrasd]

We used to say that with the OSHDB the user has access to erroneous OSM data

I'm not sure where exactly and in which context we said that, but certain data problems are just too grave to be able to access via the oshdb-api – entities with no or invalid coordinates, for example. The issue with topology exceptions is that these come from an external library (JTS), which the oshdb-api needs for performing geometry operations like clipping. When JTS refuses to do that (because the OSM data is too broken), there's little alternatives at the moment for us. I once proposed to evaluate a different algorithm for clipping in #214, which might be more robust, but that's definitely out of scope of this PR.

What I think we always promised is that the oshdb-api would not crash, even when confronted with broken/invalid OSM data, see e.g. our unit test. This PR simply restores the behavior from version 0.5 again.

Could someone still perform an analysis looking at such data that has/had some issues regarding its topology through the OSHDB?

Yes, for example by using a big enough bounding box, so that clipping doesn't affect the elements one is interested in. Or by using a custom TagInterpreter, or by using the low level data access of the OSHDB instead of the oshdb-api.

[FabiKo117]

I see.. and yes of course we can only deal with what JTS can deal with in that matter. The workaround with just using a bigger bbox would already be sufficient I guess.

Do we potentially have to add another test or extend one of the existing ones to also cover this specific issue? Because you say that it was something that was working as intended in v0.5.

[joker234]

looks good to me. Only the question by @FabiKo117 is still an open question I would be interested in:

Do we potentially have to add another test or extend one of the existing ones to also cover this specific issue? Because you say that it was something that was working as intended in v0.5.

[tyrasd]

Do we potentially have to add another test or extend one of the existing ones to also cover this specific issue?

Unfortunately, it's hard to find data which triggers this bug in our limited test data set. 😬