#4842 closed defect (fixed)
Combine ways silently combines when tag is not present on one way but present on the other
Reported by: | AM909 | Owned by: | team |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Core | Version: | tested |
Keywords: | combine tag | Cc: | AM909 |
Description (last modified by ) ¶
If you have a way with layer=1 and another way with no layer tag, and you combine them, the conflict dialog comes up but just says "no conflicts". The new way will have layer=1, which may be incorrect.
I can't think of any cases where it should do this. There are probably some "who cares" cases (like created_by), but it's still not technically correct.
Change History (15)
comment:1 by , 15 years ago
Keywords: | combine tag added |
---|---|
Priority: | normal → major |
comment:2 by , 15 years ago
comment:3 by , 15 years ago
Cc: | added |
---|---|
Version: | → tested |
This happens only when you have checked the "Show tags with multiple values only" checkbox at the top of the conflict dialog. It apparently is not considering "no key" as a value different than key=* when it counts how many values there are in the selection (but it should).
Additionally, when it brings up the conflict dialog with "no conflicts" in this case, the checkboxes at the top are not present, so you need to create conflicting tags and then try to combine them in order to change the settings of those checkboxes, which is not ideal - they should appear even in the "no conflicts" case.
Confirmed present in r3329.
follow-up: 5 comment:4 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → needinfo |
Sorry. Can't reproduce here at all. Please make a step-for-step description.
Note that no conflicts are produced, when a way is totally untagged.
comment:5 by , 14 years ago
Replying to Am909:
Replying to stoecker:
This happens only when you have checked the "Show tags with multiple values only" checkbox at the top of the conflict dialog. It apparently is not considering "no key" as a value different than key=* when it counts how many values there are in the selection (but it should).
Additionally, when it brings up the conflict dialog with "no conflicts" in this case, the checkboxes at the top are not present, so you need to create conflicting tags and then try to combine them in order to change the settings of those checkboxes, which is not ideal - they should appear even in the "no conflicts" case.
Sorry. Can't reproduce here at all. Please make a step-for-step description.
At least the problem mentioned by Am909 still exists. Once you have checked on of the two chechboxes on top this setting is stored and you do not get any information about it on the next connect, if there are no unfiltered differences.
Please always show the two checkboxes on top to get the information about the filter and be able to switch back to no filter. (uncheck the boxes).
Thanks
comment:6 by , 14 years ago
As said I was unable to reproduce, so you do something different than I do. I need a better description.
comment:7 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | needinfo → new |
Not the best example but you should get the clue.
- combine the two ways and check both checkboxes on top.
- undo
- combine the two ways -> only differences in relation membership are listed. There are no checkboxes on top and if there is a tag in without a conflict on one way, you will not get any info.
- to uncheck the boxes again you have to create a conflict on a tag.
comment:11 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Now it raises conflicts even with untagged objects.
I have an node with addr:housenumber=19 as tag and part of a associatedStreet relation and merge it with a node id:0 with no tages but part of a closed way and I get the tag conflict dialogue shown.
follow-up: 13 comment:12 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
The bug has been introduced in r5132 and isn't related to this fix.
follow-up: 14 comment:13 by , 13 years ago
comment:14 by , 13 years ago
Replying to skyper:
Thanks, next time I will open a new ticket if I am unsure.
No problem. :-)
I'm happy to hear your opinion on comment:8:ticket:7513
Ticket #5113 has been marked as a duplicate of this ticket.