Enhance the `directionalCombo` to support `sidewalk=both|left|right`

[tordans]

In openstreetmap/id-tagging-schema#454 (comment) we came to the conclusion to add support to display sidewalk data on highway values.

There are three tagging schema in use. We support two already, but need to add the third one (which is in use 2.248.360 times).

In #9587 the directionalCombo was improved to support two of the variations. We now want to add the third which only applies to the sidewalk tag.

• Support sidewalk=both => and display it as sidewalk=yes (which is sidewalk:both=yes)
• Support sidewalk=left => and display it as sidewalk:left=yes + sidewalk:right=no
• Support sidewalk=right => and display it as sidewalk:left=no + sidewalk:right=yes

[lumikeiju]

Support sidewalk=both => and display it as sidewalk=yes (which is sidewalk:both=yes)
Support sidewalk=left => and display it as sidewalk:left=yes
Support sidewalk=right => and display it as sidewalk:right=yes

Either I'm not fully understanding this, or it is a move backwards.

The old, inferior tagging schema (which this seems to enforce?):
sidewalk=left means sidewalk:left=yes and sidewalk:right=no
sidewalk=right means sidewalk:left=no and sidewalk:right=yes
sidewalk=both means sidewalk:both=yes
sidewalk=no (and sidewalk=none) means sidewalk:both=no
sidewalk=yes is unclear.

In this kind of menu, where left and right are both always shown:
Left Side = None + Right Side = None should result in the sidewalk:both=no tag being applied to the way.
(same for both Yes)

Left Side = Yes + Right Side = None should result in the sidewalk:left=yes and sidewalk:right=no tags being applied.
(same for the reverse)

Left Side = None + Right Side = <empty> should result in only the sidewalk:left=no tag being applied.
(same for the reverse)

Why display or apply sidewalk=yes in any case?

---

For cycleway=*, selecting a way with cycleway=left shows this, which doesn't make any sense:

It should display Left Side = Yes + Right Side = No and upgrade the tags to sidewalk:left=yes and sidewalk:right=no

However, as it is now (iD 2.32.0) ... if I change Right Side = left to Right Side = None then the way is left with the tags cycleway:left=left + cycleway:right=no which is clearly wrong.

It does not make sense to me to expand a broken cycleway-tagging feature to include sidewalks...

(or I just misunderstand :D)

[tordans]

@lumikeiju let us try to keep the tagging discussion in openstreetmap/id-tagging-schema#454 and use this issue focused on the technical side to add the capability to handle a third tagging variation to the directionalCombo field.

sidewalk=right means sidewalk:left=no and sidewalk:right=yes
…

Your are right, I updated my issue description. Thanks for catching this.

Left Side = None + Right Side = None should result in the sidewalk:both=no tag being applied to the way.
…

The question to pick sidewalk:both=no or sidewalk=no is what we are writing about in openstreetmap/id-tagging-schema#454. Please lets keep those discussions separate. We don't gain anything from restarting the tagging discussion here. I already showed over there that I personally agree with this (but don't see the wind blowing this way, yet) and added my suggestions on how to proceed and why.

Left Side = Yes + Right Side = None should result in the sidewalk:left=yes and sidewalk:right=no tags being applied.
…

That is what is going to happen; it is how the field already works.

For cycleway=*, selecting a way with cycleway=left shows this, which doesn't make any sense:
…

We never considered cycleway=left|right as a tagging variation that we support. I never saw it recommended in the Wiki or somewhere and the tagging is super low https://taginfo.openstreetmap.org/keys/cycleway#values (left: 559, right: 1 083, both: 831). We could either have this new feature handle those cases or add a deprecation rule to update them given the different situation from sidewalks.

However, as it is now (iD 2.32.0) ... if I change Right Side = left to Right Side = None then the way is left with the tags cycleway:left=left + cycleway:right=no which is clearly wrong.

The directionalCombo field allow to add any value (like most fields in iD). left in Right Side = left is an unknown value on one that is not recommended by the dropdown. I don't consider this a bug but the result of what happens when someone leaves the paved road that the UI provides.

[uw-amy-bordenave]

There is still the issue of the directionalCombo introducing errors in the form of incorrect tags when the *=both tag is present and a side's value is updated.

cycleway=both only has 837 uses (TagInfo), but sidewalk=both has 1,357,050 (!) uses (TagInfo), so this issue can't be dismissed as easily as for cycleway=*.

Example: When the "Left Side" is updated using the dropdown to "None", iD creates the incorrect tag cycleway:right=both.

For a snapshot of these types of errors at time of writing, I downloaded the results of this Overpass query:
way[~"sidewalk:left|sidewalk:right|sidewalk:both|cycleway:left|cycleway:right|cycleway:both"~"left|right|both"];

And, once loaded in JOSM, searched: ".*:left|.*:right|.*:both"~"left|right|both"

There's only 134 cases as of 2025-04-30, but I expect that number would skyrocket if this is added without a fix.

[tordans]

There is still the issue of the directionalCombo introducing errors in the form of incorrect tags when the *=both tag is present and a side's value is updated.

I still agree that ideally we would handle this error better. But I also still argue that this could be something to be addressed in a follow up PR because I do not agree that the "number would skyrocket" because mappers see the effect and result of their clicking right away. I want to stress the importance of iterative changes again. We postponed any improvements in this area for years which results in worse data. Even if this where to become a huge issue like eg @uw-amy-bordenave assumes we can address it later in a follow up change and we can also easily select the data to clean it up (eg MapRoulette like this one).

For clarity, this is the click by click steps that mappers will see:
(Again, using the cycleway field because when I run the code of this PR I don't have the changes from the tagging schema handy.)

1. Start
   
2. Click
   
3. This is where we assume that mappers will stop, not see the obvious error and not continue. Will they really? I agree, some will, but most will continue
   
4. Click
   
5. Result
   

---

But I don't want to argue too much to keep it as is, if someone can pick up this PR and fix the missing changes, that would be ideal. I for now will wait for feedback from Martin on how to best address this issue in code.