Render cyclist waiting aid side arrow#12374
Conversation
…e when the direction is given
|
A bunch of examples around the intersection cycleways: https://pr-12374--ideditor.netlify.app/#map=20.00/52.20125/20.93626 |
|
at least for me this direction arrow is confusing is it showing where aid is located? or is showing direction of cyclist that would use it? something else? |
|
It's showing both. The preset specifies this: 
Regardless, this was already implemented before - I didn't change its appearance, only fixed the logic for this case. It's already implemented on all features using 
|
k-yle
left a comment
k-yle
left a comment
There was a problem hiding this comment.
thanks for the PR! I think this is a nice improvement
(although i really regret not fixing the poor tag definition when we realised this issue 2 years ago - now it's way too late)
| resolver.parentWays(this).some(way => !way.isOneWayForwards()) | ||
| this.tags.side !== 'both' && | ||
| this.tags.direction !== 'forward' && | ||
| this.tags.direction !== 'backward' |
There was a problem hiding this comment.
what do you think of this case? (direction=both + side=right)
- Is it logically invalid?
- or does it mean that the handrail in on your right-hand side in both directions? If yes, that would mean that
side=right=side=both😆
There was a problem hiding this comment.
Hmm, I can see how this can be considered technically logically valid - whichever direction you use, the handrail is always on your right indeed.
But that's not enough information for visuals. Like, there's no way to disambiguate and render combinations of side arrows for two-directional features without additional assumptions. Like, for one, we would have to consider the driving side of the way, which is by the way left-hand side here, so side=right = side=inner or something...
This feels like a lot of consideration for a very niche application. Personally, I would just not bother rendering any side arrow stuff for such cases for now. As a mapper, I would be mapping these as 2 nodes.
There was a problem hiding this comment.
In parrallel, I think we should update id-tagging-schema and add a prerequisite tag for the side field:
"prerequisiteTag": {
"key": "direction",
"values": ["forward", "backward"]
},This will avoid confusion about the rendering logic, since impossible situations will not be allowed by iD's UI.
this is blocked by openstreetmap/id-tagging-schema#2255
4 participants
This PR allows the side arrow to render for cyclist waiting aids when unambiguous, i.e.
directionis given:This makes mapping the
sideless confusing, especially since waiting aids use a different meaning of "side".Original PR where rendering exception occurred #10303. Some relevant side-related comments and discussion at #10128. In short: the proposal used a non-standard meaning of
side; it could've been changed, but wasn't; now waiting aids have unique meaning ofside.The comment in code previously implied that it is impossible to determine the side arrow because the proposal's use of
sideis ambiguous. However, that is not technically correct. Thesidehere means "relative to cyclist" (unlike other features where it is "relative to way"). So it is not ambiguous if the direction of the waiting aid is known. This is basically what this PR implements - if thedirectionis known, then thesideis not ambiguous, therefore the arrow can be rendered. The caveat is to flip it around if thedirection=backward. The way's actual direction is ignored/irrelevant.The code previously also assumed that this wouldn't be ambiguous for one-way ways - but it is actually ambiguous in those cases too (e.g. road with
oneway=yes,oneway:bicycle=noand waiting aid in the "opposite" direction). In fact, the code always showed the side arrow based on the way's direction, regardless if thedirectionwas actually set, leading to a case where it would be wrong:Thankfully, this would only be wrong in that specific rare condition, so I doubt there is any significant number of mistagged features due to this.
I think the intent here was that iD could use way directionality like it does for other features that use
side, but that assumption doesn't really work. Like, the meaning ofsideis not wrong for waiting aids - it's different. Anyway, I removed this way "sidedness" assumption based on the way being one-way. I think it's best that the mapper just specifiesdirectionin those rare cases so nothing has to be assumed. I don't think iD should hard-code (any more) assumptions.Also, technically the case where
side=bothis also unambiguous, becausedirectiondoesn't matter - it's both sides however you look at it. So I included this case too (although the preset doesn't even show that option). There are apparently cases like that, e.g. example - mapillary. So it will renderside=bothpretty much always:No LLM code used in this one.