OSRM Improvements - Building Supply DK

OSRM Improvements
Package A:
Tests and Cleanup
Weights
Pushing Bikes
Improved Instructions
Package B:
Multiple Profiles
Roadwork
Hills
Squares
Turn Penalties
Tests and Cleanup
All existing cucumber tests should pass, focus on end-user
functions.
Boost test framework added, 75% code coverage, focus on
low-level functionality.
Boost test framework.
All existing cucumber tests should pass, focus on end-user functions.
Boost test framework added, 75% code coverage, focus on low-level
functionality.
To ensure code quality and increase confidence in OSRM, tests are
great.
The existing cucumbers tests should pass and more could be added
to cover more of the OSRM API. Things that make cucumber tests
run faster will make it more convenient to run tests often. A way to
reload data without restarting OSRM-routed might be one way to
achieve this. Allocating less RAM might be another.
Adding a more low-level C++ test suite based on something like Boost
test framework might be worth investigating.
Moving forward, we suggest a workflow where new revisions are
only pushed to the master branch after verifying that all tests pass.
Adding new features should include adding relevant tests.
A bit of code cleanup will help improve overall quality, and also make
it easier for others to read the code and contribute to the project.
Commented-out code sections should be removed, very long
BILAG 2
25.10.2012
Cykelsekretariatet
Islands Brygge 37
Postboks 450
2300 København S
Telefon
+45 3366 3433
Mobil
+45 2972 3788
E-mail
emil.tin@tmf.kk.dk

functions perhaps split into more manageable sub functions with
descriptive names, etc.
Weights
LUA scripts for parsing tags and computing edge weights,
travel times, way names, mode of travel (walk/bike/ferry),
turn penalties, signal penalties, etc.
Ability to call back to C++ to access data on heights, roadwork,
etc.
Language support in the LUA scripts.
LUA scripts for parsing tags and computing edge weights, travel
times, way names, mode of travel (walk/bike/ferry), etc.
Ability to call back to C++ to access data on heights, roadwords, etc.
Support for different languages in the LUA scripts.
We need a flexible way to adjust the attractiveness (impedance) of
individual ways depending on a variety of OSM tags. The mechanism
should be independent of speeds. For example, paths in parks could
be preferred over streets, even though the speed is the same, or
even a bit slower.
A LUA script extension that allows custom parsing of tags would be a
great way to achieve such flexibility, as long as it doesn’t cause
processing of OSM data to be too slow.
A script solution would also make it possible to lift some of the
profile-specific code out of OSRM itself and into the relevant profiles.
Examples uses:
prefer streets with bike lanes or tracks
Prefer streets that are part of green cycle routes or cycle
super-paths.
prefer streets with asphalt over cobblestones
Prefer ways in parks (how – the info is not in the ways itself?)
prefer intersections with green waves for bicycles (we can tag
those in OSM)
for a 'kids friendly' profile: prefer crossing big roads at
intersections with signal lights.
Up-vote or down-vote specific locations depending on purely
subjective criteria – just a nice place for biking!
Pushing Bikes
Ability to handle pushing of bikes in the LUA scripts.
Side 2 af 5

Clear indication of pushing of bikes on the map (different
color) and in the instructions.
We want the route planner to suggest routes that include stretches
of pushing the bike, when it offers a significant shortcut.
Pushing of bikes can occur both on paths where bicycling is not allow,
like pedestrian streets, and against one-ways.
Pushing of bikes should occur at a customizable speed (typically at
pedestrian speed). In the case of one-ways, there would be different
speeds when passing the same streets in opposite directions (biking
and pushing).
We need to clearly indicate on the map the parts of the route where
you need to push your bike (perhaps with a different colour on the
map), and show a notice in the route description.
Perhaps the route instructions could indicate the transport mode of
each section (bike/push/ferry)? The information could be set for each
edge when pre-processing the data.
Improved Instructions
OSRM should provide even better instructions, especially in areas
with many unnamed ways.
When there is no name, the way type should be used to provide a
more meaningful description, for example ”turn left on footpath”,
instead of just ”turn left”.
Multiple stretches of the same type should be combined when
relevant, so the user don’t get a string of plain 'continue' instructions.
Different wording could perhaps be used when you need to 'cross the
bridge', 'pass through the tunnel' or 'cross the square.
If a script-based tag parsing system is implemented, would it make
sense that the script could also be used to customize the
instructions? That way instruction could be modified different for
each transport mode. This is just an idea.
Multiple Profiles
OSRM should provide a way of handling multiple profiles. We need to
offer the user different modes, for example:
Side 3 af 5

icycle: normal bicycle mode
cargo bike: avoid narrow passages, steps, steep ramps/hills
night: avoid parks and unlit streets, closed gates
We can help develop the details of the profiles, but need OSRM to
support multiple profiles in a practical way, without having to run
multiple instances of osrm-routed.
It should also be easy to reprocess the data for all profiles at the
same time.
Roadwork
Some short-lived data doesn’t fit well in OSM, but could be very
useful in routing. Roadwork is a good example. Events like
marathons, street parties are also relevant.
Data would include start and end date/time, and probably some
information about how it affects various traffic modes, like delay,
detour, danger, etc.
We can generate a data file with information about ongoing
roadwork. Such data would probably be oriented towards day, rather
than hours or real-time. The data will probably be located using
street addresses.
OSRM should be able to load this data and use it to adjust routing.
We need to figure out suitable data formats etc.
Perhaps some pre-processor could load the roadwork/events data,
and add tags to the OSM data. For example, a way might be tagged
with ’roadwork=yes, delay=20s’. The extractor could then handle
those tags as needed.
Another option might be that the tag parser would load the data and
use it directly.
Hills
We have a detailed height model that we would like to be able to
load into OSRM.
How to use information about hills should be up to the new tag
parser. For example, it might be more important for cargo bikes than
for normal bikes, and only have a small effect on electric bikes (or
cars).
Side 4 af 5

Height data, roadwork, events, etc are all examples of non-osm data.
It might be useful to consider some common infrastructure for
handling such data.
Squares
Crossing squared could be more elegant. The current solution simply
follows the edge of the square. It would be cool if OSRM was able to
cut across squares in a more realistic fashion.
This would probably require adding some number of artificial paths
criss-crossing the square. Perhaps it would be possible to use
standard geometric sub-division algorithms to find a good balance
between number of paths added, and distance saved.
Turn Penalties
OSRM should be intelligent about turns. People prefer a route with
fewer turns, and also prefer right turns over left turns (in countries
with right-side driving). The sharper a turn is, the less attractive it is.
Winding roads are slower than straight roads, even if they’re at the
same length. Overall routes with fewer turns are easier to remember
and follow, and are often faster.
Hopefully we can get Copenhagen University involved in establishing
a good model for this, but it still needs to be implemented into
OSRM.
We implemented a simple turn penalty formula, which seems to
work quite well. We need to either have this merge into the master,
or come up with something better.
Side 5 af 5