Unglue ways: False positives about affected relations

[skyper]

What steps will reproduce the problem?

1. Have a way (A) with three nodes and member of a relation and another way (B) connected at the middle node without membership, see attached file​
2. select middle node and way A
3. unglue ways

What is the expected result?

No info warning

What happens instead?

Info warning about affected relation.

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

Please, do not show this warning if the selected node is a middle node of the selected way and the other way is not member of the relation.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-02-02 18:47:18 +0100 (Sun, 02 Feb 2020)
Revision:15810
Build-Date:2020-02-03 02:30:51
URL:https://josm.openstreetmap.de/svn/trunk

[skyper]

example file

[GerdP]

WIP : There are more cases to fix in this action.

[GerdP]

suppress warning notification for parent relation when unglued node is not first or last node of modified way

[skyper]

I would say if neither the selected node nor the selected way is part of the relation suppress any warning even for end nodes.

For the node problem see #6836.

[GerdP]

Do you think about the case 18670-sample.osm when the node at the western end of the from way is selected for unglue?

[skyper]

Replying to GerdP:

Do you think about the case 18670-sample.osm when the node at the western end of the from way is selected for unglue?

I was thinking about the situation splitting the way with three nodes of josm_unglue_relation.osm​ at the middle node and then unglueing but this is working already.

Your example is valid, though.

[GerdP]

I wonder how we should detect that a change of the way doesn't effect the relation. It requires knowledge about the relation type (=lots of code) to decide that a relation is not affected by the change.
Example: The relation might be a type=multipolygon. In that case the notification makes sense if the from way was selected, else see #19042.
Also, when I unglue a way from a via node and the way is not member of the turn restriction it might still mean that the turn restriction is obsolete (as in the attached sampe). The current tested version r16239 doesn't produce a warning for this case, it just asks if the via role should be copied (unless we apply the patch for #6836).

I'd say: Better safe than sorry.
A improvement would be to change the text in the notification:

        final String msg1 = trn("Unglueing affected {0} relation: {1}", "Unglueing affected {0} relations: {1}",
                size, size, Utils.joinAsHtmlUnorderedList(affectedRelations));

I would change that to

        final String msg1 = trn("Unglueing possibly affected {0} relation: {1}", "Unglueing possibly affected {0} relations: {1}",
                size, size, Utils.joinAsHtmlUnorderedList(affectedRelations));

and try to show the notification also for the parent relations of the involved node(s).

[skyper]

+1 for adjusting the warning (for now).

Something was changed as josm_unglue_relation.osm​ works as expected (r16243).

I do not know any relation which is changed/damaged if the middle node of a member way is deleted unless that node is also member of the relation.

There is a difference between modifying/damaging a relation and making a turn-restriction obsolete. For the later a validator warning could be enough and no real damage is possible if there is no option to adjust the membership.

Relations with via members always need a special treatment as you need to look at the way and its end nodes and only warn if both, the way and its child end node, are members. Split-way does handle it but unglue not.

[GerdP]

Replying to skyper:

+1 for adjusting the warning (for now).

Something was changed as josm_unglue_relation.osm​ works as expected (r16243).

No, I still get the notification.

I do not know any relation which is changed/damaged if the middle node of a member way is deleted unless that node is also member of the relation.

I also don't know any, but I only know MP and those relations which affect routing well as they are handled by mkgmap.

There is a difference between modifying/damaging a relation and making a turn-restriction obsolete. For the later a validator warning could be enough and no real damage is possible if there is no option to adjust the membership.

OK

Relations with via members always need a special treatment as you need to look at the way and its end nodes and only warn if both, the way and its child end node, are members. Split-way does handle it but unglue not.

[GerdP]

18670.3.patch improves the way selection if only a node is selected for unglue and changes the message as suggested.
It still produces a few false positives reg. the notification.

[skyper]

Replying to GerdP:

Replying to skyper:

Something was changed as josm_unglue_relation.osm​ works as expected (r16243).

No, I still get the notification.

Strange, I do not get it neither with r16251 nor r15937.

[GerdP]

Make sure that you select the longer way and the node

[skyper]

Sorry, you are right.

[GerdP]

Relations with via members always need a special treatment as you need to look at the way and its end nodes and only warn if >both, the way and its child end node, are members. Split-way does handle it but unglue not.

Working on this. Struggling with the case that the relation has via way(s), not nodes.

[GerdP]

BTW: split-way doesn't seem to handle via ways. When I split one the relation is not updated.

[GerdP]

suppress warning notification for some parent relation types ("restriction", "connectivity", "destination_sign") when they are not affected

[GerdP]

still doesn't work when node between two via ways is unglued. Just found that case in #9008

[GerdP]

also handles the case that a via way is unglued

[GerdP]

In 16300/josm:

fix #18670, #19042: Unglue ways: False positives about affected relations

• avoid to warn about possibly broken turn restrictions when we can make sure they are not broken
• when no way is selected, try to find one that produces fewer updates

TODO: handle dataset without download areas

[GerdP]

In 16303/josm:

see #18670: fix error introduced with r16300
Ungluing an unconnected tagged node (e.g. natural=tree) caused exception instead of "not glued to anything" message

[Klumbumbus]

Milestone renamed

[skyper]

r16300 caused a regression if the node has tags and only one parent, see #19352.

[skyper]

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