Some polygon intersections are ignored

[GerdP]

What steps will reproduce the problem?

1. Run validator on the attached osm file

What is the expected result?

Validator should report "Overlapping Identical Natural Areas" for the two rectangles in the upper left area like for those on the right.

What happens instead?

The rather large overlap in the upper left area is ignored, we also allow to create a multipolygon
and if you verify that mp the overlap is detected because a different test is used.

Please provide any additional information below. Attach a screenshot if possible.

I think there are two reasons:

• First is that Geometry.polygonIntersection(Area a1, Area a2, double eps) use Rectangle instead of Rectangle2D
• Second is that the default value 1 for eps is far too high, no matter if the area is in EastNorth or LatLon. My understanding is that the eps value should be chosen so that we ignore really small overlaps which could disappear after rounding to OSM precision, so maybe 1e-7 for LatLon areas.

I am still trying to find out the proper value for EastNorth.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-03-31 21:17:00 +0200 (Sun, 31 Mar 2019)
Build-Date:2019-03-31 20:25:18
Revision:14945
Relative:URL: ^/trunk

Identification: JOSM/1.5 (14945 de) Windows 10 64-Bit
OS Build number: Windows 10 Home 1803 (17134)
Memory Usage: 370 MB / 1820 MB (160 MB allocated, but free)
Java version: 1.8.0_201-b09, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080
VM arguments: [-XX:StartFlightRecording=name=MyRecording2,settings=d:\dbg\gerd.jfc, -XX:FlightRecorderOptions=defaultrecording=true,dumponexit=true,dumponexitpath=e:\ld\perf_20190416_100731.jfr]
Dataset consistency test: No problems found

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.

[GerdP]

Please review!
Another problem that appeared while testing:
When areas intersect at different places each intersection area might be very small but the rectangle of the intersection area can be large. The attached patch fixes this as well.
The patch changes

• the default threshold value for intersection from 1.0 to 0.01
• the meaning of the threshold. It implements a more sophisticated test to check the intersection area. I think it is better to check width and height instead of the product of both (the old meaning). Even better would be to calculate the real area, but that is error prone because of rounding problems.
• MultipolygonTest to use the new default
• WaySegment fields are final (not directly related to this ticket)

[GerdP]

added unit test, removed debug code

[GerdP]

Problem case small overlap with clearly crossing ways

[GerdP]

unit test didn't match data in overlap-v-shape.osm

[GerdP]

Please load overlap-v-shape.osm and zoom to the outer right and left nodes. There are two small overlaps but clearly crossing ways.
Without the patch JOSM shows Warnings for overlapping areas, but this warning disappears when you merge the two points on the left.
With patch it will ignore the overlaps in both situations because both are smaller than the epsilon value.

The only way to improve that is to use a very small epsilon like 1e-10.
@Vincent: You introduced this eps with 1.0 in r5522. Do you remember why?
I think I remember that sometimes the method java.awt.geom.Area.intersect(Area rhs) calculates small intersections because of rounding errors, but never with such a large error.

[GerdP]

In 15008/josm:

fix #17614:

• don't test integer bounding box of intersection area, use doubles
• in case of multiple intersections, check each individual intersection
• introduce new constant INTERSECTION_EPS_EAST_NORTH, the value 1e-4 is just a reasonable small value, might be decreased
• improve javadoc to make clear that east/north space is assumed
• small refactorings to fix SonarLint issues

[Don-vip]

Replying to GerdP:

@Vincent: You introduced this eps with 1.0 in r5522. Do you remember why?

It was probably enough to fix the samples I had in #7034 and #8067.