`highway=cyclist_waiting_aid` `side` gets reversed with the way

[RudyTheDev]

When a way is reversed and there is a highway=cyclist_waiting_aid (openstreetmap/id-tagging-schema#1066 / openstreetmap/id-tagging-schema#1069) with a side value, then this value also gets "reversed". However, side represents the side of the waiting aid from the cyclist's perspective, not from the way's perspective, so this actually sets an incorrect value.

For example, add highway=cyclist_waiting_aid + direction=forward + side=right to a way's node. Then reverse the parent way. Observe that direction=backward got swapped correctly, but also side=left got swapped, which is now on the incorrect side.

[SupaplexOSM]

To avoid making things too easy:

• If it's a oneway cycleway/path, the side flip would be OK, because iD assumes that the direction of travel also changes in this case (and does not become oneway=-1).
• However, if it is a oneway road that can also be used by cyclists in the opposite direction, the side flip would be wrong, as cyclists can continue to ride in the previous direction.

I'm sorry that the tagging has such a pitfall in this case. (This issue is also mentioned in this forum thread)

[tyrasd]

oh… I had not thought of that.

This might be pretty hard to handle 100% correctly. 😬 But how likely is it that this will actually be a real problem in practice? I mean, given that these features are by definition always placed in front of certain obstacles like intersections: When the direction of travel of, say, a oneway bikepath is flipped in reality, then that would mean that previously existing waiting aids are now all placed in locations where they are not useful anymore (e.g. right after intersections instead of right before them). So… realistically, the waiting aids would have been moved in reality as well, meaning that they would have to be fully remapped accordingly anyway. 🤔 Right?

[RudyTheDev]

Is this the only feature that uses side this way? May be it's better to either change the tag or make it way-dependent before "it's too late". If all editors are flipping side by default, may be it's a bad idea to set a precedent for exceptions. I had assumed tag flipping was hard-coded per feature, depending on what it means. But I guess it had always meant "side from way perspective".

[tyrasd]

AFAICS, the wiki does not document any uses of the side tag other than for the cyclist waiting aids (as seen in the Key:side page which only redirects to the waiting aid page). However, the tag is informally relatively heavily in use in combination with mapping traffic sign nodes (see taginfo) (where the left/right directions are presumably be meant to be interpreted relative to the direction of the way).

The usual convention in OSM is that left/right are describing the sides of a way relative to the mapped direction of the way. Thus, iD will flip left/right values of any tag (with a few exceptions), in order to not be limited to a limited fixed list of tags and/or presets. What would probably be needed for this are two new values which would indicate sides relative to where the (road) user is facing. Perhaps something like port/starboard 😜

[SupaplexOSM]

Initially, the use of the side tag in context of waiting aids was also considered in line direction, but it turned out that this can easily be misunderstood by mappers (see this example). The idea was then to use it from the cyclist's perspective in case of waiting aids. Due to the missing documentation of other uses of side, this difference in use emerged.

The assumption in case of waiting aids was, that direction of travel/movement-dependent use results in more correct/less incorrect data. Possible mistakes due to direction flips should be the absolute exception (especially as waiting aids are often on oneway paths, where this problem does not exist when flipping). But of cause, this makes things hard for editor developers.

[simonpoole]

• If it's a oneway cycleway/path, the side flip would be OK, because iD assumes that the direction of travel also changes in this case (and does not become oneway=-1).

That would seem to be iffy, the whole issue is that the side of the rest from the cyclists perspective has nothing to do with the way direction, and that somebody surveying the way correctly could get the side of the rests right and the way direction wrong and many other possible combinations.

Note that there are additional complications if the rest is co-mapped with a traffic_sign object.