Modify

Opened 10 months ago

Last modified 2 weeks ago

#16006 new defect

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

Reported by: eladner Owned by: GerdP
Priority: normal Milestone: 18.12
Component: Core Version:
Keywords: template_report, multipolygon Cc:

Description (last modified by Klumbumbus)

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.

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

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.

Attachments (3)

example.png (69.1 KB) - added by eladner 10 months ago.
example showing some of the defects. MP highlighting is subtle because it was water. zoom in and it's more apparent.
example.osm (7.9 KB) - added by eladner 10 months ago.
reworked the example as an OSM file and easier to see.
SplitOnIntersectionsAction.java.patch (2.5 KB) - added by GerdP 4 months ago.

Download all attachments as: .zip

Change History (14)

Changed 10 months ago by eladner

Attachment: example.png added

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

Changed 10 months ago by eladner

Attachment: example.osm added

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

comment:1 Changed 10 months ago by Klumbumbus

Description: modified (diff)

comment:2 Changed 4 months ago by Don-vip

Keywords: multipolygon added

comment:3 Changed 4 months ago by 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.

comment:4 Changed 4 months ago by 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.

comment:5 Changed 4 months ago by 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?

comment:6 Changed 4 months ago by 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).

Changed 4 months ago by GerdP

comment:7 Changed 4 months ago by GerdP

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

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.

comment:8 Changed 4 months ago by Don-vip

Milestone: 18.09

comment:9 Changed 2 months ago by Don-vip

Milestone: 18.0918.10

comment:10 Changed 6 weeks ago by Don-vip

Milestone: 18.1018.11

comment:11 Changed 2 weeks ago by Don-vip

Milestone: 18.1118.12
Owner: changed from team to GerdP

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain GerdP.
as The resolution will be set.
to The owner will be changed from GerdP to the specified user.
The owner will change to eladner
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from GerdP to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.