Recognise and use parking:both and cycleway:both

[PattaFeuFeu]

Issue description

When setting Parking or Bike lanes on a way, they are set as parking:left+parking:right, and cycleway:left+cycleway:right even if both sides have the same value.

Similarly, even if a way already has parking:both and/or cycleway:both set, Go Map!! doesn’t recognise that and shows both tags as unset, allowing you to set them. If you do, they are again set as *:left and *:right.

Way tags	Common tags: Bike lanes	Common tags: Parking

Use case

When using Go Map!!, I most often use the “Common tags” view for the usually interesting tags for that specific node or way. For ways, Parking and Bike lanes are available in the common tags view for easy setting. I often set values there for the left and right side of a way only to later find out through Osmose’s issue list that there are now duplicate tags because Go Map!! didn’t parse the *:both tags in a way that they are shown for both the *:left and *:right variant.

Proposal

Same as iD, Go Map!! should

1. internally parse parking:both as parking:left and parking:right to show already existing values in the handy Common tags view for Parking (and Parking orientation). Same for cycleway:both.
2. if setting both values for parking or cycleway to the same value, they should be saved as parking:both and cycleway:both, not parking:left+parking:right / cycleway:left+cycleway:right with the same value for each

Potential issues

Duplication already exists

A way could already have e.g.

parking:left=lane
parking:right=lane
parking:both=lane

In that case, the both value should probably be used. Maybe already remove the separate values if changing parking for the way?

Conflicting values already exist

A way could already have e.g.

parking:left=no
parking:right=lane
parking:both=lane

Here, parsing could not reliably be done and both variants could be correct or wrong. An error / warning would probably make sense.

[tordans]

Two additions:

I think what you write should be true for all presets of the type directionalCombo https://github.com/ideditor/schema-builder?tab=readme-ov-file#combodropdown-fields This new type was introduced only a short while back to handle those left/right/both taggings.

This is the implementation of this field in iD. This preset type used to be called cycleway.

Another things for the cycleway tag there is the issue of the two variants cycleway and cycleway:both with no clear definition of them being the same. I am working on a proposal to clarify this situation; more at https://github.com/openstreetmap/id-tagging-schema/issues/1025#issuecomment-2198457359

[PattaFeuFeu]

I think what you write should be true for all presets of the type directionalCombo ideditor/schema-builder#combodropdown-fields This new type was introduced only a short while back to handle those left/right/both taggings.

Oh, yeah, definitely! So far, I only found those two to be an issue for my tagging usage but I’m open to extend this issue into a general “support directionalCombo type fields” ticket.

Another things for the cycleway tag there is the issue of the two variants cycleway and cycleway:both with no clear definition of them being the same.

Hah, didn’t know that. Thanks for the info and the link! I’ll read up on what you proposed.

[bryceco]

Thanks for the comment @tordans, my first question was whether this was something that could be made more general rather than coding for a specific tag.

[tordans]

Yes, it's a good first step. There are quite a few things that are missing, yet in the tagging schema to really model the more complex tagging schema like the parking:* schema. Things like sub-tags that should only show when a primary side-tag was selected and such. But it is a huge help already.

I hope to start a effort to get more of this more detailed left/right data into the presets. There are some thought on this in https://github.com/openstreetmap/id-tagging-schema/issues/1202 .

[bryceco]

Fixed to work with directionalCombo.