Opened 3 years ago
Last modified 3 months ago
#20054 new enhancement
Overlapping areas: Allow areas inside areas sharing segments
Reported by: | skyper | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core validator | Version: | |
Keywords: | template_report overlap area inside | Cc: | Don-vip, dieterdreist |
Description (last modified by )
What steps will reproduce the problem?
- 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.
- 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
Attachments (7)
Change History (22)
comment:1 Changed 3 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 3 years ago by
Component: | Core → Core validator |
---|
Changed 3 years ago by
Attachment: | josm_area_inside_area_shared_segment.osm added |
---|
comment:3 Changed 3 years ago by
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.
Changed 3 years ago by
Attachment: | josm_area_inside_area_shared_segment-mod.osm added |
---|
slightly modified
comment:4 Changed 3 years ago by
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.
comment:5 Changed 3 years ago by
Yes, simply moving a node seems to quite validator. Means this is a bug.
Changed 3 years ago by
Changed 3 years ago by
Changed 3 years ago by
comment:6 Changed 3 years ago by
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.
comment:7 Changed 3 years ago by
Cc: | Don-vip added |
---|
@Vincent: Do you know how to find out if this is a known java bug?
comment:8 Changed 3 years ago by
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.
comment:9 Changed 3 years ago by
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.
comment:10 follow-up: 11 Changed 3 years ago by
the test is about areas inside areas
No, it's about crossing/overlapping areas
comment:11 Changed 3 years ago by
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.
Changed 2 years ago by
Attachment: | 20054-simple-sample.osm added |
---|
very simple example which produces wrong "overlapping areas" message
Changed 2 years ago by
Attachment: | 20054.patch added |
---|
comment:12 Changed 2 years ago by
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.
comment:15 Changed 3 months ago by
Cc: | dieterdreist added |
---|
simple example