This generalizes the oneway arrow logic for adding SVG markers along a
line. Using that functionality, certain tags get arrows on their
right-hand side, indicating which side is "inside", e.g. the
right-side of a cliff is the lower side.
The list of tags considered to be sided (unless there's a
two_sided=yes tag) is:
- natural=cliff
- natural=coastline
- barrier=retaining_wall
- barrier=kerb
- barrier=guard_rail
- barrier=city_wall
- man_made=embankment
The triangles attempt to be reminiscent of the triangles used for
rendering cliffs on OSM (and elsewhere). The different tags get
different renderings (e.g. colors that match the main way, and
different spacings). In addition, natural=coastline is special-cased
to have blue markers (despite having a green way), to emphasise that
the "inside" of a coastline is the water.
Fixes https://github.com/openstreetmap/iD/issues/1475.
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
Some highlights
- `getSiblingAndChildVertices` are expensive, so they're saved and called less frequently
- draw touch targets for all the visible vertices
- remove redundant css classes and `setClass` function
This is more work to further isolate the layers that entities draw to.
It makes it easier to debug what is going on, and can eventually lead to
deferred drawing, if each draw function is in its own place and not dependant
on anything else.
I've started to replace the vertex-hover with an explicit layer for touch
targets.
Also had to change a lot of the svg tests, which are really brittle.
Things would happen like - the surface would be created, it would kick of a
deferred redraw, which would notice that the zoom was 0 and call
editOff, which would remove the osm layers that were just created and
that the tests were trying to draw to. These tests need proper zoom and
projection otherwise nothing works.
(re: #4271, #3636)
- better classification of "interesting" vertices
(include tagged, selected, or child of selected)
- now we can draw labels on selected lines again (revert #3636)
because the labels will avoid the vertices
- if debugging is on, draw a collision box for the mouse
(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
(closes#3986)
Root cause was the vertex shadow strokes were too big, esp on endpoints.
For normal lines 16px stroke width centers on the line, but for vertices
it extends beyond the vertex radius, stealing clicks.
Also switched some "globals" to module variables in draw.js
