Overlapping areas: Allow areas inside areas sharing segments

[skyper]

What steps will reproduce the problem?

1. Have an area with an area inside, sharing a segment but not crossing. I have a building-MP inside an amenity, see josm_area_inside_area_shared_segment.osm​.
2. Run validator

What is the expected result?

No warning

What happens instead?

Info warning: Overlapping Areas

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

These overlaps like a building inside an amenity are correct. There is no other way to map it than having shared segments.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-11-08 17:34:30 +0100 (Sun, 08 Nov 2020)
Revision:17304
Build-Date:2020-11-09 02:30:51
URL:https://josm.openstreetmap.de/svn/trunk

[skyper]

simple example

[skyper]

According to trunk/resources/data/validator/geometry.mapcss:

area:closed:areaStyle ⧉ area:closed:areaStyle {
  throwOther: tr("Overlapping Areas");
}

So this test simply checks area inside area but the warning is in my eyes irritating.

[GerdP]

slightly modified

[GerdP]

I think what you see is the effect of the strange definition of "insideness" in java shapes, maybe combined with rounding errors. My modified example should either give the same info (or better both should not) but results are different.

[skyper]

Yes, simply moving a node seems to quite validator. Means this is a bug.

[GerdP]

Yes, it's a bug, but probably not one that we can solve. JOSM calculates the intersection of the areas using the method
java.awt.geom.Area.intersect(Area rhs).

        Area inter = new Area(a1);
        inter.intersect(a2);

Later it checks if the intersection equals the original area, and this returns false for your example and true for mine.
The reason is that the intersect method produces two extra points with nearly 0 distance. I've created some debug code to visualize the different shapes, see attached gpx files. If you compare a2.gpx with inter.gpx in a diff program you find the extra points. This bug exists as long as I am working with this class and I am pretty sure that it is known. No idea how to find out. If anybody thinks it can help I can write a standalone java code to prove it.

[GerdP]

@Vincent: Do you know how to find out if this is a known java bug?

[skyper]

Still do not understand what this rule should flag. The message says Overlapping Areas but the test is about areas inside areas. But there is no problem with a building inside an amenity.

[GerdP]

The test doesn't care about the type of the areas. For real overlaps it just means that two areas cover the same place. Nobody says that this is wrong. On the other hand we don't have a rule for each combination of areas that must not overlap, so this is a one for all rule.

[GerdP]

the test is about areas inside areas

No, it's about crossing/overlapping areas

[skyper]

Replying to GerdP:

the test is about areas inside areas

No, it's about crossing/overlapping areas

I see, real overlap but not touching. Thanks.

[GerdP]

very simple example which produces wrong "overlapping areas" message

[GerdP]

The patch fixes both problems but requires additional - typically slow - calculations. Possible alternative would be to replace the area.equals() tests completely by these additional tests. Have to do some tests reg. performance.
With the patch some crossing areas are no longer found.

[GerdP]

Ticket #20911 has been marked as a duplicate of this ticket.

[GerdP]

Ticket #22815 has been marked as a duplicate of this ticket.