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.
