`highway=cyclist_waiting_aid` `side` gets reversed with the way about id HOT 8 CLOSED

I think it's early enough that we should just redefine the side tag for waiting aids. There are only 430 nodes with highway=cyclist_waiting_aid and side=*. Of the 430, I mapped 384 of them, and I'm happy to review the side of each one.

That leaves only 46 features that someone else needs to review. Worst case a fixme tag could be added to those 46 nodes.

Redefining the tag seems like a better option than permanent confusion about how to handle this tag in each editor...

from id.

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)

from id.

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?

from id.

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".

from id.

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 😜

from id.

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.

from id.

• 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.

from id.

Just in case anybody needs some inspiration :-). My current solution to the issue is to reverse the tag except if the node in questions matches (JOSM filter/search language):

highway=cyclist_waiting_aid -child (type:way highway: (oneway? OR oneway="-1"))

which neatly takes care of the oneway aspect.

from id.