[Patch] converting to multipolygon too aggressive

[dieterdreist]

When you have a (closed) way with the tag
barrier=wall
height=1

and you hit ctrl+b to make a multipolygon from it, it will keep the wall tag on the way but move the height to the multipolygon relation. IMHO when hitting ctrl+b it should either move all tags, or none, with a preference to none.

[skyper]

Related to or duplicate of #18019.

[GerdP]

it should either move all tags, or none, with a preference to none.

Not sure if I got that right. Do you mean: It should move all when there is no conflict or - like in your case - a linear tag? Or should it never move? The latter is already implemented with preference multipoly.movetags. Change it to false to disable the move.

[anonymous]

Thinking about it, with the experience I have made in the past time, I agree that moving the tags is often very helpful and exactly the desired behaviour.
On the other hand, some tags clearly should not be moved (those refering to line objects like barrier!=hedge (also hedge was changed in carto to line only some time ago, so maybe it is suffient to check for the barrier key) and some more. And for properties it will not be sure where they should go when there are both kind of tags (linear and not), while otherwise they will go where the rest goes.

Maybe the best would be to ask the user when in question? I would expect the ambivalent cases to be few, so maybe it is not worth it?

[skyper]

It should not move any tag, by default, if there is a linear tag or a single conflict.

Optionally, there could be a tags conflict dialog offered, but this dialog has to offer all keys and at least display their values.

Once again, a simple ignore list (multipoly.lineartagstokeep) does not work as we need to define key-value combinations and even tag combinations to separate linear from area tags. See #18019 and e.g. highway=service with/without area=yes. Maybe the same definitions as validator's "overlapping ways" can be used.

[GerdP]

It should not move any tag, by default, if there is a linear tag or a single conflict.

We have to find out which conflicts need special handling. One example is source, probably fixme, note and others should never be moved to the relation and thus should not create conflicts. My approach here would be to use the method
AbstractPrimitive.getUninterestingKeys()

I see no way to produce a complete list of tags which mean that the way is a linear object, but yes, the "overlapping ways" test has a similar problem.

Looking at the given example with height It requires expert knowledge to decide that this tag describes the details of the barrier=wall. In combination with building=yes it might well be wanted to have height in the multipolygon relation.

A conflict dialog might not work well when you create a multipolygon from many ways with different tags, but I have to experiment with that.

[skyper]

The conflicting tags/memberships dialog should work, but without the membership part and with setting to show all tags and not any of the two possible filters available/activated.

[skyper]

Replying to GerdP:

It should not move any tag, by default, if there is a linear tag or a single conflict.

We have to find out which conflicts need special handling. One example is source, probably fixme, note and others should never be moved to the relation and thus should not create conflicts. My approach here would be to use the method
AbstractPrimitive.getUninterestingKeys()

I do not think it is a good idea to rip tags apart automatically. All above mentioned tags are no problem if the value is identical, though, some might better fit to the ways or both the MP and the ways.

There are just too many common tags like operator and name but also surface or material which can be a problem.

[GerdP]

Looked at this again. In fact the "Update Multipolygon" action is even worse as it might drop tags like addr:housenumber:

1. Have two buildings with similar tags but different addr:housenumber.
2. Create a multipolygon from one of them
3. Add the other building to the selection and use Ctrl+Shift+B to update the multipolygon.

After this the multipolygon has the addr:housenumber from the first way and the other addr:housenumber is gone. This is a clear error.
Edit: Sorry, found this with tested. It was already fixed, see #20110

[GerdP]

I have no good solution for this until now. A new dialog would add a lot of complexity, so I'd really like to avoid that.
I am currently testing 19594.patch​ which implemtens this approach:

Add a new preference multipoly.no-movetag-on-conflict=true. This prohibits the movement of any tags if

• any conflicting tag value is found or
• if not all common tags are moved, e.g. because one is in the list given by preference multipoly.lineartagstokeep

Besides that highwayis added to the default for preference multipoly.lineartagstokeep.

Edit: There is probably more to do for Join overlapping Areas action. Unit test JoinAreasActionTest fails and I am not sure if the expected result is really OK.