[Patch] Using 'split adjacent ways' on multipolygons is unpredictable.

[eladner]

What steps will reproduce the problem?

1. create a multi-segment multipolygon
2. draw a segment internally from a node on one way to a node on another way
3. Execute Split Adjacent Ways (ctl-alt-shift-P)

What is the expected result?

segments are split at the internal way and still members of the multipolygon.

What happens instead?

sometimes (not all the time) one portion of a segment split by the adjacent way is removed from the multipolygon.

Sometimes, it will remove an attribute off one of the ways.

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

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-02-23 00:01:20 +0100 (Fri, 23 Feb 2018)
Build-Date:2018-02-22 23:03:41
Revision:13450
Relative:URL: ^/trunk

Identification: JOSM/1.5 (13450 en) Linux Ubuntu 16.04.3 LTS
Memory Usage: 1205 MB / 7282 MB (900 MB allocated, but free)
Java version: 1.8.0_161-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
Dataset consistency test: No problems found

Plugins:
+ AddrInterpolation (34061)
+ CommandLine (33984)
+ Create_grid_of_ways (33856)
+ FastDraw (33731)
+ FixAddresses (33963)
+ OpeningHoursEditor (33876)
+ PicLayer (34021)
+ SimplifyArea (33918)
+ alignways (33784)
+ apache-commons (33668)
+ buildings_tools (34040)
+ dataimport (33581)
+ download_along (33710)
+ ejml (32680)
+ ext_tools (33889)
+ geotools (33958)
+ gpsblam (33776)
+ importvec (33902)
+ jts (32699)
+ log4j (32699)
+ merge-overlap (34056)
+ opendata (34072)
+ reltoolbox (33708)
+ reverter (34036)
+ splinex (33844)
+ turnrestrictions (33780)
+ utilsplugin2 (33991)
+ waydownloader (33910)

Tagging presets:
+ https://josm.openstreetmap.de/josmfile?page=Presets/OneClick&zip=1

Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/LessObtrusiveNodes&style&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Fixme&style&zip=1

Last errors/warnings:
- W: Invalid jar file ''<josm.pref>/plugins/opendata.jar.new'' (exists: false, canRead: false)
- W: No configuration settings found.  Using hardcoded default values for all pools.

[eladner]

example showing some of the defects. MP highlighting is subtle because it was water. zoom in and it's more apparent.

[eladner]

reworked the example as an OSM file and easier to see.

[GerdP]

I don't know if this has ever worked. The current code creates two ChangeCommand instances for the MP, both referring to the original relation. Each replaces one way with the the two new chunks.

When you 1st select the northern split node and press P to split one way, next select the southern split node and press P again,
the 2nd action "sees" the already modified relation and you get the expected result.

When you select both split nodes and press P a warning message "The selected nodes do not share the same way." is shown.
I think something like this should also happen in this case.

[eladner]

But unexpected things happen. Both pieces of a split way should have any tags that the previous whole way had. And if a way is in a multi-poly, both pieces should be in the MP after it's split.

In the diagram, the splits weren't two successive splits on the same set of geometry, but two different splits on identical copies of the geometry. In some cases, parts of the split way are kicked out of the MP. In others, it's still in the MP, but stripped of any previous tags.

[GerdP]

I was not able to reproduce the case that a way loses tags. Your example contains two MP, in the right one the upper way is not tagged as highway=footway. Maybe this caused the confusion?

[eladner]

You're correct. I couldn't reproduce the "way loses tags" part of this ticket either. I think what's happening on the right side is that the top way isn't tagged and initially is painted as part of the leisure:park. When the way is split and part of it is kicked out of the relation, it looks like it's losing it's style/tags when in reality, it never had any. It only loses it's MapCSS because it got kicked out of the relation.

Still, though, selecting the diagonal way, then Ctrl-Alt-Shift-P produces odd results (and non-deterministic results). On two different reloads, I clicked on the left diagonal, then Ct-Al-Sh-P and one time, part of the footway is kicked out of the MP (the side to the right of the diagonal on the top) - one time, part of the tertiary highway on the bottom is kicked out of the MP (also, the side to the right).

So I guess the ticket should be amended to just "when splitting an MP with Ctrl-Alt-Shift-P, some parts of the split ways get removed from the relation".

Expected result: when you split a way that's in a relation, both parts should be in the relationship after the split, no matter the split method.

The use case where I notice this mostly is drawing in swamp/wetlands around a river basin. Draw a way that usually starts on a multi-polygon waterway:riverbank, and usually connects back to the same, select it, ctrl-alt-shift-P to split the river side, then select the pieces and make into a multi-poly then tag as a wetland. Sometimes pieces of the river multipolygon get kicked out of the MP and have to be re-added (a pain, when doing this over a large area and complicated multiploygons).

[GerdP]

OK. I've attached a patch that implements a check for this condition. I think the problem occurs whenever multiple ways are split and
at least two are members of the same relation. Note that
When this is the case, multiple split way actions are generated and a popup is shown with the text
"Two or more affected ways are members of the same relation. Multiple actions are created for this split."

BTW: I thought that Alt+X (Split Object) might be the better choice for this but it doesn't seem to work with MPs.

[GerdP]

Work around as described is implemented with ​[o34780:34781].

Maybe the problem should be solved in SequenceCommand so that it somehow handles the case when the same object is referenced in multiple sub commands.

[GerdP]

Improved solution is implemented with ​​[o34790:34791].
SplitWayCommands are executed immediately so that they always see the latest version of the relations. In the end, the commands are recombined to one sequence if more than one split was generated. So warning popup is no longer needed :)