Let's say we have a tertiary road with the following tags:
highway=tertiary
maxspeed=60
surface=gravel
smoothness=intermediate
While the maxspeed tag tells us the legal speed limit, the surface and
smoothness tags have much more effect on the real-world speed of a car.
We should process the maxspeed tags first, and then update the road's
forwards/backwards speeds according to any surface and smoothness tags.
For our hypothetical road the process in the car.lua profile now goes
like this:
1. Get default speed from profile (tertiary = 40 on line 150 of car.lua)
2. Change speed to 60 using maxspeed tag (WayHandlers.maxspeed function
in way_handlers.lua, lines 434-447)
3. Change speed to 40 using surface tag (WayHandlers.surface function
in way_handlers.lua, lines 360-363)
4. Check speed according to smoothness tag --- but because it's higher
than the speed according to the surface tag, leave the speed
unchanged (WayHandlers.surface function again, lines 368-371)
<ec36319232/profiles/car.lua (L150)>
<ec36319232/profiles/lib/way_handlers.lua (L354-L372)>
Note in step 3 above the speed's only changed from 60kph to 40kph
because it's a lower value. If the surface speed was higher than than
the previous value, the speed would remain unchanged. Another example:
highway=tertiary
maxspeed=60
surface=compacted
smoothness=intermediate
Here, although the profile's speed for compacted is 80, it would stay at
the lower value of 60 (see way_handlers.lua, lines 360-363).
<ec36319232/profiles/lib/way_handlers.lua (L360-L363)>
Let's say we have a tertiary road with the following tags:
- maxspeed=60
- surface=gravel
- smoothness=horrible
The maxspeed tag tells us the legal speed limit, but the surface and
smoothness tags have much more effect on the real-world speed of a car.
In the default car profile, the gravel surface sets a driving speed of
40kph, and the horrible smoothness sets a driving speed of 10kph. It
seems to me that the tags should be processed in this order:
1. maxspeed
2. surface
3. smoothness
That is, maxspeed can be overridden by the surface tag, which can in
turn be overridden by the smoothness tag. In the case of our secondary
road, it would start with a driving speed of 60kph (from maxspeed),
which would be reduced to 40kph (from surface), and end at 10kph (from
smoothness).
However, before this change, the maxspeed tag is processed *after*
surface and smoothness: our road starts with a driving speed of 40kph
(from surface), it's reduced to 10kph (from smoothness), and then
*increased* to 60kph (from maxspeed).
This change alters the processing order so that maxspeed is processed
first, giving it the lowest priority of these three tags.
OSM data contains many mistakes that tag kerbs as highway barriers
when instead they are only describing highway crossings.
This PR updates the default car profile to handle these mistakes
and unblock routing on the affected highways.
Bundling node-pre-gyp was only needed for node v4 and earlier.
Remove it to avoid errors like:
> npm ERR! enoent ENOENT: no such file or directory, rename '/home/circleci/project/node_modules/node_or_tools/node_modules/abbrev' -> '/home/circleci/project/node_modules/node_or_tools/node_modules/.abbrev.DELETE'
More context: https://github.com/mapbox/node-pre-gyp/issues/260#issuecomment-407222286
Removes the breaking libosrm API change by adding the old interface to
the new. This does not introduce any new breaks.
The downside of this is that it allows for multiple ways to
return JSON responses.
When using non-default constructors for the API parameter classes,
vector arguments like coordinates and hints are copied at least once
(twice when passed as lvalue arguments).
Enable perfect forwarding of BaseParameter arguments and
pass-by-value in the constructor that uses the argument. This
ensures we copy at most once (zero for rvalue arguments).
Regardless of any copy elision on the returned pair value, the
duration and distance results are always copied.
Fix this by passing rvalue references to std::make_pair.
Currently OSRM only supports turn restrictions with a single via-node or one
via-way. OSM allows for multiple via-ways to represent longer and more
complex restrictions.
This PR extends the use of duplicate nodes for representng via-way turn
restrictions to also support multi via-way restrictions. Effectively, this
increases the edge-based graph size by the number of edges in multi via-way
restrictions. However, given the low number of these restrictions it
has little effect on total graph size.
In addition, we add a new step in the extraction phase that constructs
a restriction graph to support more complex relationships between restrictions,
such as nested restrictions and overlapping restrictions.
* Use Nan:: getters and setters for node 12/14 compatibility
* Drop support for publishing node 8 bindings, add publishing support for node 12, 14
Co-authored-by: Daniel Patterson <danpat@danpat.net>
