Also stringify the note id (because existing notes from OSM are this way)
Also make sure comments is initialized as an Array not an Object
Also clarify some of the tests
This commit includes a bunch of minor things:
- change keyboard shortcut to 'E' to not conflict with anything
- move `disabled` check from operation into action and simplify
- use `actionMoveNode` to place the detached node at the mouse cursor
- disable the operation if the node is connected to hidden features
- lots of code simplification
- make the icon more centered
This makes the osmNote work a bit more like other osm objects in iD.
- When working with the osm objects, we'll treat them as immutable.
So all modifications will be through the update method:
e.g. can do this in a repl, like chrome devtools console:
> n = iD.osmNote()
osmNote { id: -1 }
> n = n.update({ foo: 'bar' });
osmNote { foo: "bar", id: -1, v: 1 }
- none of the other osm objects have getters, and in JavaScript all the
properties are public anyway
partially adresses bugs in #4968:
* doesn't crash anymore in complex situations (short FROM ways where both ends connect to a TO way)
* adding a only-restriction at one end of a short FROM doesn't delete restrictions on the other end of the same FROM anymore
(closes#4951)
Previously it would only count if the connecting node was the first one.
I guess I was only thinking about oneways only the day I wrote that code.
(closes#4844)
The maxDistance was previously hardcoded to 30 meters.
Now we pass it in as a parameter when creating the intersection.
But we need to honor that same maxDistance later when walking the graph
to find turns from.
(I decided that the larger context of the intersection is important and
shouldn't be hidden from the user)
Also
- show detail slider only if the intersection is complex
- hide the restriction editor completely if there is no real intersection
(e.g. junction of `highway=path`)
This is the part of the algorithm where trivial sections get trimmed
from the vgraph. Removing a vertex from `vertexIds` means "stop checking
this one". But there were some situations where it could get removed
twice, so we now just verify that `vertexId` is actually in the array
before calling `splice`.
(re #4589)
Strongly prefer to generate a forward path that preserves the order
of the members array. For multipolygons and most relations, member
order does not matter - but for routes, it does. If we started this
sequence backwards (i.e. next member way attaches to the start node
and not the end node), reverse the initial way before continuing.
