Join Areas: Tags and Membership from uninvolved objects copied

[skyper]

What steps will reproduce the problem?

1. Have three closed ways, two of them overlapping and the third one with different tags or memberships than the other two. See attached file​.
2. Select all three ways
3. Join overlapping areas

What is the expected result?

The tags and memberships of the involved ways are merged to the (new) way

What happens instead?

All tags and memberships of all selected ways are merged to the (new) way, including tags and memberships of selected objects which were not joined as they do not overlap.

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

Please, use only the tags and memberships of the involved objects and skip the other, thanks.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-02-03 22:02:21 +0100 (Mon, 03 Feb 2020)
Revision:15813
Build-Date:2020-02-04 02:30:59
URL:https://josm.openstreetmap.de/svn/trunk

[skyper]

example file

[GerdP]

I don't understand what should be changed. Can you attach another file with the expected result?

[skyper]

result example

[skyper]

I attached the result example file​.

The way made out of the two overlapping ways should only get the tags of these two ways but not the tags from the third way which is left unchanged.

Maybe, a notification, if some ways were not used is useful, too.

[GerdP]

Other actions like "Combine Way" or "Create circle" show only a notification when the selection is not usable. I'd prefer this reaction.

[GerdP]

I first thought that JOSM could check if the result is a single way, but that might not be wanted. Please check attached files. With all 4 buildings selected the current result is that both joined areas have the same tags.
If I got you right you would want the result in join-areas-4-2-res.osm instead? Not sure how many users would be confused with this change.
So, maybe just a notification when the result is not a single way? Something like "Please verify result: Multiple areas with the same tags"

[skyper]

I am fine with only a notification if the result is multiple areas but, please, always exclude the tags from the object which were not used. #18597 is not an advantage in this case, so enabling #7513 for experts might be useful.

Replying to GerdP:

Other actions like "Combine Way" or "Create circle" show only a notification when the selection is not usable. I'd prefer this reaction.

Wait a minute. "Combine Way" does only care about ways but will use all ways or notifies without action. "Create circle" is very strict and allows only a few selections where the whole selection is used otherwise notifies without action. So "Join Areas" is quite special. Do not know any action, like it, that is choosing the objects to use out of selection.

[GerdP]

I've not yet found a good solution for this. The current algo works like this:
1) check if any intersection between the selected ways exists, stop if none is found
2) check if tag conflicts exists. This is done with the standard CombinePrimitiveResolverDialog which returns a list of commands to change the ways, maybe after asking for user confirmation. The returned commands are executed, in your example that means that all three ways have the same tags before anything else is done.

So, if the later processing shows that the nodes of one or more ways are not changed, the tags of those ways are already changed.
Your idea reg. #7513 could help but only when you don't expect any tag changes. If you expect them you probably don't hesitate to press OK.
I can try to code a check which would show a notification when the result contains multiple areas AND tags were merged.

[GerdP]

The patch implements the check and shows a notification for the examples.
Selected ways were not joined to a single area but have the same tags now.
Please verify no errors have been introduced.

Please let me know what you think, maybe suggest better text.
I probably have to add more code to handle cases where relations were created or modified.

[skyper]

Wonder if it is possible to keep the tags of the involved ways as list and the ids of the ways for each segment and when combining the segments use the lists of tags and the oldest not yet used id. For mulipolynomes this might be tricky.

Actually, caching the ids with its tags and using the cache when combining the segments should do the job, if you know the former way id of the segments.

[GerdP]

The question is what result you want to get when you combine 3 or more ways, each possibly having different tags and result is not a single closed way. You seem to expect that JOSM decides that you accidentially selected the way 89152803 and ignore your selection?

[skyper]

Replying to GerdP:

The patch implements the check and shows a notification for the examples.

Selected ways were not joined to a single area but have the same tags now.
Please verify no errors have been introduced.

Are there no confirmation dialogs in normal mode like combine way, anymore, and the Tags/Membership Conflict Dialog will still open ?

Better wording ?

Selected ways were not joined to a single area but all tags and memberships were merged (copied).
Please verify no errors have been introduced.

Replying to GerdP:

The question is what result you want to get when you combine 3 or more ways, each possibly having different tags and result is not a single closed way. You seem to expect that JOSM decides that you accidentally selected the way 89152803 and ignores your selection?

Yes, I expected that untouched objects are complete ignored and only tags/memberships from the actually combined objects are merged. So if the result is two modified objects and one untouched the two modified objects get only the tags/memberships of their ancestors.

I can live with the warning, though.

[GerdP]

Replying to skyper:

Are there no confirmation dialogs in normal mode like combine way, anymore, and the Tags/Membership Conflict Dialog will still open ?

Not sure what you mean. In what situation? The patch doesn't change this part of the program.
Sometimes the Conflict dialog is very confusing, see new ticket #18744.

[skyper]

Ok, forget it.