Support rendering direction on vertices (stop sign, traffic_signals, etc)
#4602
Conversation
|
An arrow is kinda confusing to me. Is that the direction of travel or the direction the sign would be facing? |
Yeah, this is a hard problem. Currently, the arrowhead faces whatever the direction tag says: "Forward" or "Backward" - so that's "direction of travel". Even those words are not great - I don't think an untrained mapper would really be able to understand this concept, or even why stop signs (and even moreso traffic signals) would need a direction. The help text is not very helpful either.
I'd definitely welcome some ideas on how to make this easier. |
|
Some other design thoughts.. whatever we do needs to:
|
bhousel
force-pushed
the
direction_vertices
branch
from
67d7c5b to
b79b6ca
Compare
|
@iandees I do kind of like the viewfield a little better, what do you think?
|
|
Yea, that makes more sense I think. I was also going to suggest something like that but with a flat line perpendicular to the incoming way representing the top of the sign/signal. |
Sometimes people tag all-way stop signs at the junction node, othertimes people tag all-way stop signs at the stop sign location. What we're doing here is: - if `stop=all` tagged at the junction, show viewfield in all directions - if `stop=all` tagged at the sign location, show viewfield according to `direction=` tag
(styling marker fill in svg is not currently supported)
|
So this functionality is turning out to be pretty cool. I have directions rendered for a bunch of things now (street signs, cameras, etc). The main issue remaining is that a point with directions disappears when dragged.
I know why - it's because vertices aren't displayed during a drag, which is also #3003. |
(re: #3003 / #4602) For now, drawHover is commented out. Still not sure what I will do with it. This means that things flicker a bit when dragging, also connecting nodes (and closing lines) does not currently work. There was lot going on preventing the vertices from rendering while dragging. 1. `modeDragNode` needed a proper `selectedIDs()` function that works like other modes.. Many other places in iD (including the vertex renderer) call `context.selectedIDs()`.. This means that `modeDragNode` needs a new function `restoreSelectedIDs()` to do what `selectedIDs()` was previously doing (a place to store selectedIDs so that we can reselect those entities after the user is done dragging a node in select mode) 2. Just so many things in svg/vertices.js - siblingAndChildVertices was missing some things for points that we render as vertices (points in wireframe, points with directions) - the sibling vertices weren't being included in the `filter` function, so would disappear when doing differenced/extent redraws - probably some other things
- `nodes` are for osm nodes - `points` are the projected locations of those node `loc` in screen space
(it's easier to just class the surface, and won't interfere with snapping)
Test for self-intersecting areas in both drag_node and draw_way
(this can get a bit expensive for large/complex multipolygons)
This makes the code a bit more consistent and lets us avoid some hacky and probably non-performant things: - abusing CSS classes in the draw/drag datum functions (classed `.target`) (is this thing target? just check d.properties) - regexing the id for `-nope$` (is this thing a nope target? just check d.properties) - using context.hasEntity to get a the real entity (is this thing a real osmEntity? just check d.properties) - fixes code like the restriction editor which uses fake ids for split ways
(fixes test and allows hover on the area fills again)
|
Happy New Year! Time to merge this thing already! 🎉🎆🎊🍾 It will show up in http://preview.ideditor.com/master shortly, and I encourage anyone who is interested to try it out there... |
|
Hi, I like the new viewfield for direction but aren't forward and backward reversed? |
I don't think they are reversed. For example, a stop sign that affects forward travel will be pointed backwards so the cars can see it:
But if you found a situation that we are rendering incorrectly, please open an issue and me know! |
|
2018-02-20 11:49 GMT-03:00 Bryan Housel <[email protected]>:
I like the new viewfield for direction but aren't forward and backward
reversed?
I don't think they are reversed. For example, a stop sign that affects
forward travel will be pointed backwards so the cars can see it:
Thanks for your quick answer. Your explanation is clear but the value used
for direction and the viewfield shown confuse me. If the stop sign points
backwards relatively to the way direction and I'm mapping its direction
(where it faces to), why tag it with 'forward' as in this example and not
'backward'?
In your example, the viewfield looks backwards (I think), what is OK, after
all the stop sign faces backwards, but the value for direction is
'forward'. What am I missing?
…-- Fidelis Assis
|
Oh yeah, I left out an important detail in that screenshot above. The See:
The main reason that I started rendering these viewfields is because it's nearly impossible (especially for casual mappers) to understand how the direction apply to a way. |
|
2018-02-20 14:32 GMT-03:00 Bryan Housel <[email protected]>:
If the stop sign points
backwards relatively to the way direction and I'm mapping its direction
(where it faces to), why tag it with 'forward' as in this example and not
'backward'?
Oh yeah, I left out an important detail in that screenshot above. The
direction=forward/backward tag works relative to the direction *that the
way is drawn*, not the direction of the sign.
OK, I understand that. Just to make myself clearer, let's consider a oneway
road with a stop sign (or a traffic calming - that was my initial
motivation, I was confused when checking a few tagged with forward). On a
oneway road, all stop signs and traffic calmings face backwards because the
drawing direction is the same as the traffic flow (perhaps a few old
exceptions). So, I was thinking they, if tagged with direction (unnecessary
for one-way roads anyway, also for two-way roads when affect both
directions), the value should be *backward*. But the viewfield in this case
shows the opposite direction.
In the example below, both traffic calmings were tagged with forward,
probably because the mapper wanted to align the viewfield correctly. Again,
in this case the direction isn't necessary.
Ex:
https://www.openstreetmap.org/edit?node=349338170#map=19/-23.02126/-43.44967
I extract speedcams for GPS from OSM. If 'forward' is the right value in
these cases I'll have to change how I calculate direction when it matters
(ex: traffic calming or speed sensor acting on a single direction on a
two-way road).
A funny thing about these tags - if you reverse the way, iD also needs to
(and does) reverse the direction=* tag.
Nice. Does it also reverse if the value is in degrees?
See:
- https://wiki.openstreetmap.org/wiki/Key:direction#
Forward_and_backward
- https://wiki.openstreetmap.org/wiki/Tag:highway=stop#
Tagging_minor_road_stops
The main reason that I started rendering these viewfields is because it's
nearly impossible (especially for casual mappers) to understand how the
direction apply to a way.
Yes, I think it's a very helpful facility. Thanks for adding it!
…-- Fidelis
|
(updated: scope creep)
Something I threw together today - I still might adjust the marker style a bit, and I'm not 100% sure if it handles all of the tag cases correctly.
highway=stopwithdirection=forward/direction=backwardThis is what it does for
stop=allordirection=both