Modify

Opened 22 months ago

Last modified 10 months ago

#19594 assigned defect

[Patch] converting to multipolygon too aggressive

Reported by: dieterdreist Owned by: GerdP
Priority: normal Milestone:
Component: Core Version: latest
Keywords: multipolygon create move tags Cc:

Description

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.

Attachments (1)

19594.patch (2.2 KB) - added by GerdP 17 months ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 22 months ago by skyper

Keywords: create added

Related to or duplicate of #18019.

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

comment:3 Changed 19 months ago by GerdP

Owner: changed from team to GerdP
Status: newassigned

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

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

Last edited 19 months ago by skyper (previous) (diff)

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

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

comment:8 in reply to:  6 Changed 19 months ago by 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.

Last edited 19 months ago by skyper (previous) (diff)

comment:9 Changed 18 months ago by 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

Last edited 18 months ago by GerdP (previous) (diff)

Changed 17 months ago by GerdP

Attachment: 19594.patch added

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

Last edited 17 months ago by GerdP (previous) (diff)

comment:11 Changed 10 months ago by skyper

Summary: converting to multipolygon too aggressive[Patch] converting to multipolygon too aggressive

Modify Ticket

Change Properties
Set your email in Preferences
Action
as assigned 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 dieterdreist
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket

Add Comment


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

 
Note: See TracTickets for help on using tickets.