#13591 closed defect (fixed)
[Patch] Change in multipolygon is not recognized by MultipolygonCache
Reported by: | GerdP | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 16.10 |
Component: | Core | Version: | |
Keywords: | template_report | Cc: |
Description
What steps will reproduce the problem?
- Load attached unglue.osm
- Select the node where the inner and outer ring intersect
- Press 'G' to unglue, a popup says "Unglueing effected one relation" (which is correct)
- Select the node, keep left mouse button pressed and move the node a bit to the north
- Select the rightmost way
- Select the unglued node, keep left mouse button pressed and move the node close to the other
one from step 4
- Press "M" to merge the nodes and therefor close the outer ring.
- Press "Shift+V" to run validator
What is the expected result?
no warning message
What happens instead?
Warning "Multipolygon is not closed (1)"
Please provide any additional information below. Attach a screenshot if possible.
When I open the relation in the relation editor and change the order of the ways and save that the validator no longer complains. I think the problem here is that the MultipolygonCache is not updated when the nodes are merged in step 7.
I'll try to find a fix for this.
URL:http://josm.openstreetmap.de/svn/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2016-09-06 00:16:07 +0200 (Tue, 06 Sep 2016) Build-Date:2016-09-05 22:21:00 Revision:10966 Relative:URL: ^/trunk Identification: JOSM/1.5 (10966 en) Windows 10 64-Bit Memory Usage: 2402 MB / 5461 MB (2214 MB allocated, but free) Java version: 1.8.0_102-b14, 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_20160908_153418.jfr] Dataset consistency test: No problems found Plugins: + FastDraw (32938) + apache-commons (32699) + buildings_tools (32944) + ejml (32680) + geotools (32813) + jts (32699) + o5m (32857) + opendata (32898) + pbf (32865) + poly (32699) + reverter (32796) + utilsplugin2 (32815) Map paint styles: + https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1
Attachments (2)
Change History (6)
Changed 7 years ago by
Attachment: | unglue.osm added |
---|
comment:1 Changed 7 years ago by
Summary: | Change in multipolygon is not recognized → Change in multipolygon is not recognized by MultipolygonCache |
---|
Changed 7 years ago by
Attachment: | 13591.patch added |
---|
comment:2 Changed 7 years ago by
Summary: | Change in multipolygon is not recognized by MultipolygonCache → [Patch] Change in multipolygon is not recognized by MultipolygonCache |
---|
I've found a fix, see attached patch. The problem always occurs when the nodes of multipolygon way are changed so that an inner or outer ring which was unclosed is now closed. The patch detects this and removes the polygon from the cache to make sure that it is recalculated with next use.
comment:4 Changed 7 years ago by
Milestone: | → 16.10 |
---|
Thank you for the patch, but also for showing me that Shift+V
runs the validator, and M
merges the solely selected node into a very close one.
No idea how to fix this. Here is what I found:
The
UnGlueAction
somehow creates aTagsChangedEvent
for the two outer ways, and this triggers acall of
MultipolygonCache.removeMultipolygonFrom(Relation r, Collection<Map<Relation, Multipolygon>> maps)
which means thepolygon is calculated again next time and the field
Multipolygon.openEnds
is filled.The
MergeNodesAction
doesn't trigger such a call. TheMultipolygonTest
usesMultipolygon.getOpenEnds()
and sees out-aged data.