Incomplete results when specifying certain bpoly which share an edge with OSM features

[SlowMo24]

Looking at https://www.openstreetmap.org/way/180085127/history the object changed on the 2020-05-04.

When using one bpoly the object is returned on the 2020-05-04 and 2020-05-05. The same is true when requesting using two bpolys.

way/180085127 is also present in the response when requesting at the 2020-05-04 when using 7 bpolys but not on the 2020-05-05.

The following file contains the curl requests as well as the input and output to verify this bug (thanks to @rtroilo ): insufficient return.zip

[rtroilo]

could maybe related to issue #1

[tyrasd]

@SlowMo24 can you provide a (simple :pray: ) API request link which triggers this bug?

[rtroilo]

@tyrasd see the attached zipfile "insufficient return.zip"

[SlowMo24]

could maybe related to issue #1

@rtroilo I don't think so because the bug persists if I remove the only overlapping bpoly (way/168019944)

@SlowMo24 can you provide a (simple pray ) API request link which triggers this bug?

@tyrasd what would need simplification? Last time I checked I could not create a URL via swagger as it complained about the length of the url containing the polygons.

But I could pinpoint it down to one polygon that triggers the error (way/169133616). Please find an updated file attached: insufficient return_update.zip

[tyrasd]

Sorry, I somehow overlooked the link to the zip file at first glance. With "simple" I meant a minimal example, reduced to the absolute minimum input data needed to trigger the bug. I know that it's not always easy to provide such an example. Thanks for the second example.

[SlowMo24]

just for clarification: the file contains three curl requests that only differ by their bpoly parameter. Each is run for the two mentioned timestamps. All bpolys contain the geometry of way/180085127 and therefore way/180085127 should be returned for each of them. Yet it is missing on a distinct timestamp-bpoly combination.

[tyrasd]

I was able to reduce the input data to the following more easily to handle geojson: https://gist.github.com/tyrasd/c9e769288539821d93d3f62eae66d446#file-in_buggybpoly_modified-geojson

as one can see very clearly, the second polygon in bpolys shares the border with the to be expected but missing output feature.

My educated guess would be that the cause for this is actually related to #1: a topology exception probably occurs during a JTS operation. Upgrading to a newer JTS version might fix this issue, see https://lin-ear-th-inking.blogspot.com/2020/10/overlayng-lands-in-jts-master.html for more.

//edit: To clarify: I'm not saying that it is OK that a topology exception triggered by one of the input polygons cause a feature to disappear completely from the output. The code should to be made more robust to handle such situations more gracefully!

[SlowMo24]

thats what I expected :-)

[tyrasd]

can you please open an issue at the OSHDB repository for this?

[SlowMo24]

Just to emphasise the severity this bug can have depending on the setup: I assume (havn't checked though) it to be accounable for a considerable part of that bar at 0:

The chart shows the area tags decreased through edits on landuse polygon on the 2020-05-04 in Germany where 0 -> completely vanished, 1-> did not decrease at all.

[tyrasd]

I'm not saying that it is OK that a topology exception triggered by one of the input polygons cause a feature to disappear completely from the output. The code should to be made more robust to handle such situations more gracefully!

Actually, after giving it a second thought, I think it might not be possible to make "our" code more robust to avoid this problem. It depends on where exactly in the code the exception is happening: If it is already happening in a part of the areaOfInterest checks, then there is not much we can do to circumvent this, except for upgrading to a newer JTS version and hope they have fixed the problem.

[bonaparten]

see GIScience/oshdb/#351