"cycleway" field: fix multiselections tag corruption + make field reusable #9423
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
reducing duplication of code, and brings missing features to the directional version of the field
because the common tag vs. left/right tag situation can be different for different entities in the multiselection, the approach to merge/split/update the tags needs to be made on a per entity basis this introduces a new way to specify tag changes: a callback function which is called for each to be modified entity
instead of `"strings": { "options": { "<tag-value>": "<translatable-string>", …` it is now also supported to have:
```
"strings": {
"options": {
"<tag-value>": {
"title": "<translatable-string>",
"description": "<translatable-string>"
},
…
```
tyrasd
added
bug-release-blocker
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This addresses an important bug fix and makes the field more flexible to use
the bug
Under some (not very obscure or rare) conditions, when the cycleway field was used to edit a multi selection, the operation resulted in a (partial) corruption of the selected entities. For example:
When now setting the "Right side" value to something like
shared_lanethe result is the following:Note how way 1's "Left side" was silent changed from
notolane. Instead one would expect this:This bus was cased because for a multiselection the previous selection only looked at the first selected entity to find out what to do with the not-user-modified tag. Because the common tag vs. left/right tag can be mapped different for different entities in the multiselection, the approach to merge/split/update the tags needs to be made on a per entity basis. The fix for this introduces a new way to perform tag change action: a callback function which is called for each to be modified entity.
the enhancement
This is mostly inspired by openstreetmap/id-tagging-schema#674, which would benefit from a field which can edit a directional (
*:forward/backward) tag.directionalCombo(keepingcyclewayfor backwards compatibility), and replacing hardcoded occurances of thecyclewaytag key with the one supplied by the preset field.nonevalue: Previously anycycleway:<direction>=nonewas silently removed from the tags which doesn't make sense for two reasons: a) the documented tag value isnoand b) it should be possible to map the absence of a cyclewaycyclewayand acycleway:directiontag are present, previously the field used the "common" tag value (i.e. the value of thecyclewaytag). Now this ambiguous tagging is represented as “multiple values” in the editor.comboui field under the hood, which reduces duplication in the code and brings the field up to par with regular combo fields: features like autosuggestions from taginfo are now available also for this fieldcombofields can now display fields withstringswhich include adescriptionhover text in addition to the tag's label.