Make entry points of individual pipeline stages responsible for
configuring the task scheduler with requested number of threads
passed in corresponding configuration bundle (ie. follow extractor).
Rename module partition to partitioner.
This cultivates naming used in existing modules like extractor,
customizer, etc. - noun vs verb (word partition is both though).
* set and store highway and access classification for the turn function
* expose highway turn classification and access turn classification and speed to the lua profile turn function
* expose whether connection road at turn is incoming or outgoing
* add lua tests for exposed information to turn function
* update docs about attributes in process_turn
* add turn_classification info to docs
* adding warning if uturn and intersection dont match
* handle u turns that do not turn into intersection[0]
* split OSM link generation in an accessible coordinate function
As a form of smoothing we use the previous speed value instead.
This makes sense because the zero duration segments have to be very
short, potentially also zero length.
Pool instance has been removed from Reader ctor parameters
list in PR #4438, presumably unintentionally.
It is required to prevent potential deadlock during
Pool shutdown as explained in PR #4452.
For intersection at https://www.openstreetmap.org/node/65299217
`are_parallel` in MergableRoadDetector::HaveSameDirection is false
for South Van Ness Avenue with 150 meters
When doing the new Lua version refactor we changed the expectation to
use `continue uturn` instead of making a whole circle in the roundabout
as the original test case. This was only the shortest path since there
was no roundabout penalty.
- separates node-based graph creation and compression from edge-based graph creation
- moves usage of edge-based node data-container to pre-processing as well, unifying access to node-based data
- single struct instead of separate vectors for annotation data in engine (single place of modification)
There is no possibility until multiple-weights are implemented
to break tie in the contraction and the direct shortest path plugin
as duration is not computed during contraction.
This must be fixed after multiple-weights implementation
by using `std::tie(weight, duration)` pairs everywhere.
Advantages:
* Allows to use Pool configured with user-preferred number of threads.
* If libosmium used in a shared library, this helps to prevent potential
deadlock during Pool shutdown at (after) shared library unloading.
See https://github.com/osmcode/libosmium/pull/214
Requires libosmium 2.13.0
Default-constructed objects of (boost::heap) handle_type are singular,
including the wrapped handle_type::iterator.
Apparently, MSVC iterator debug facilities strictly require that
one singular instance is compared to another singular instance.
It is not possible to get check-comparabe iterators of non-singular
and singular instances as owning container will always mismatch.
This reverts commit 4686272f87.
Unfortunately, this doesn't work alongside `node-pre-gyp` - in fresh installs, the binary
files are not yet downloaded when npm tries to create symlinks, leading to an error.
- refactor conditional restriction handling to not use external data (first OSM nodes on ways)
- BREAKING: changes internal file format of osrm.restrictions
- add support for general conditional penalties based on edge-based nodes (requires unique edges between nodes)
Unify CMAKE_CXX_COMPILER_ID tests without quoting/bracketing
the variable to use implicit expansion.
Replace STREQUAL with MATCHES to avoid policy warning about
attempt to expand "MSVC" variable, where it literal is intended.
If Visual C++ _ITERATOR_DEBUG_LEVEL > 0, then
accessing std::array<char[N], M> elements via reference to const
causes compilation error:
...\msvc\14.10.25017\include\array(181): error C2440: 'return': cannot convert from 'const char *' to 'const char (&)[256]'
Alternative workaround is to remove const qualifier from the GetClassName method.
Makes turn restrictions into dedicated structures and diferentiates between them via a variant.
Ensures that we do not accidentally mess up ID types within our application.
In addition this improves the restriction performance by only parsing all edges
once at the cost of (at the time of writing) 22MB in terms of main memory usage.
The viaroute plugin always expects a route to be there potentially
with invalid edge weight to represent no-route-found. By switching
to the many-route-result for the mld alternatives algorithm we might
return an empty many-route-result invalidating the post-condition.
9fd2348c6 Release v2.11.3
ed708286e Fix namespace.
835df8a7f Fix multipolygon assembler.
0979ab529 Fix areas assembler algorithm.
801f84c62 Bugfix: Invalid use of iterators.
f85653820 Read OPL file correctly even if trailing newline in file missing.
a31571c0f Release v2.11.2
a3903b368 Use minimum size of 64 bytes for buffers.
b86bafefe Release v2.11.1
32ebf736c Updated change log.
632ea5198 Bugfix: Call get_creator_function() in main thread.
ddc79eee7 Add test for not correctly handled unsupported_file_format_error.
86197a14f Bugfix: Terminate called on full buffer.
4340be8ad Fix the Filter::count() method.
git-subtree-dir: third_party/libosmium
git-subtree-split: 9fd2348c6956b6e1b930b50850e99eb31207ed50
Building `node-osrm` from source requires nan, node-cmake and
node-pre-gyp npm packages already \*. In order to bootstrap we
bundle these dev packages in the bundle we publish to npm.
\* See `src/nodejs/CMakeLists.txt`
Check `npm pack` - we now expect to see a `node_modules` directory
with nan, node-cmake, and node-pre-gyp already there.
This adds the ability to mark ways with a user-defined
class in the profile. This class information will be included
in the response as property of the RouteStep object.
Add the good default options as recommended by GitHub.
Helps to work around issues when using hybrid environments like
the Bash On Windows (see #4228).
PR uses TBB internal atomic's for atomic CAS on non-atomic data
Corresponding PR https://github.com/Project-OSRM/osrm-backend/pull/4199
Other options:
* use sequential update
* use an internal packed vector lock -> makes packed vector non-movable
* use boost.interprocess atomics implementation -> outdated and only 32 bit version
* use glib atomic's -> requires new dependency
* wait for https://isocpp.org/blog/2014/05/n4013 as_atomic
* use c11 _Atomic and atomic_compare_exchange_weak -> not possible to mix c++11 and c11
* use builtin functions gcc __sync_bool_compare_and_swap and msvc _InterlockedCompareExchange64 -> possible, but requires proper testing
boolean CompareAndSwapPointer(volatile * void * ptr,
void * new_value,
void * old_value) {
if defined(_MSC_VER)
if (InterlockedCompareExchange(ptr, new_value, old_value) == old_value) return false;
else return true;
elif (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__) > 40100
return __sync_bool_compare_and_swap(ptr, old_value, new_value);
else
error No implementation
endif
}
* use Boost.Atomic -> requires new dependency
WordT local_lower_word = lower_word, new_lower_word;
do
{
new_lower_word = set_lower_value<WordT, T>(local_lower_word,
lower_mask[internal_index.element],
lower_offset[internal_index.element],
value);
} while (!boost::atomics::detail::operations<sizeof(WordT), false>::compare_exchange_weak(
lower_word,
local_lower_word,
new_lower_word,
boost::memory_order_release,
boost::memory_order_relaxed));
- template function for tile functionality with edge finder operator
- refactors unit tests into single function (reduce code duplication)
- adds unit tests for core-ch
The alpha constant is for the local optimality T-Test threshold.
Before we used epsilon for the T-Test threshold, but the epsilon
constant is meant to be used for the stretch test(s) only.
This changeset fixes the local optimality T-Test and uses the
epsilon constant for the two stretch tests:
- We test the stretch for the total route against epsilon and
- We test the detour against the epsilon now, too
We can discuss if the second stretch test should actually use
epsilon, too, or a adapted value of it - but definitly not alpha.
The new numbering uses the partition information
to sort border nodes first to compactify storages
that need access indexed by border node ID.
We also get an optimized cache performance for free
sincr we can also recursively sort the nodes by cell ID.
This implements issue #3779.
- Adding sides parameter into base parameters, it can take the values SIDE, OPPOSITE or DEFAULT.
- Adding url parser for "sides" parameter, url values are "s" for SIDE, "o" for OPPOSITE and "d" for DEFAULT, example : "sides=s;s".
- Checking parameters, if "sides" parameter is used, the number of parameter is the same as number of location.
- Create a phantom to start at side driving or Opposite side driving.
Signed-off-by: FILLAU Jean-Maxime <jean-maxime.fillau@mapotempo.com>
(i.e. stuff that's stored in our datafiles). Keep those checks for user-supplied values
(i.e. coordinates coming from files during preprocessing, or coordinates supplied by users
during requests)
This fixes issues #3952. The new approach pre-computes masks for fast
access. Since elements can potentially span multiple words we need masks
and offsets for each upper and lower word.
Due to a bug in the C++14 standart the mask computation is not
recognized as constexpr, but would work on C++17.
* optionally include condition and via node coords in InputRestrictionContainer
* only write conditionals to disk, custom serialization for restrictions
* conditional turn lookup, reuse timezone validation from
extract-conditionals
* adapt updater to use coordinates/osm ids, remove internal to external map
* add utc time now parameter to contraction
* only compile timezone code where libshp is found, adapt test running
* slight refactor, more tests
* catch invalid via nodes in restriction parsing, set default cucumber
origin to guinée
* add another run to test mld routed paths
* cosmetic review changes
* Simplify Timezoner for windows build
* Split declaration and parsing parts for opening hours
* adjust conditional tests to run without shapefiles
* always include parse conditionals option
* Adjust travis timeout
* Added dummy TZ shapefile with test timezone polygons
* [skip ci] update changelog
We failed to check if we could actually find phantom nodes for all
coordinates in the table plugin, leading to corrupt internal state.
```
curl 'http://localhost:5000/table/v1/car/7.4151,43.7305;7.4222,43.7368?radiuses=0;'
```
```
[assert][140505627227904] /tmp/osrm-backend/include/engine/routing_algorithms/routing_base.hpp:68
in: void osrm::engine::routing_algorithms::insertNodesInHeap(osrm::engine::SearchEngineData<osrm::engine::routing_algorithms::ch::Algorithm>::ManyToManyQueryHeap&, const osrm::engine::PhantomNode&) [with bool DIRECTION = false; osrm::engine::SearchEngineData<osrm::engine::routing_algorithms::ch::Algorithm>::ManyToManyQueryHeap = osrm::util::BinaryHeap<unsigned int, unsigned int, int, osrm::engine::ManyToManyHeapData, osrm::util::UnorderedMapStorage<unsigned int, int> >]: phantom_node.IsValid()
terminate called without an active exception
```
this allows to keep a single Algorithm template parameter in internal
interfaces as
template <typename Algorithm>
search(SearchEngineData<Algorithm> &,
const datafacade::ContiguousInternalMemoryDataFacade<Algorithm> &, ...)
Does not run the nodejs tests in sanitized builds. We'd have to
export LD_PRELOAD='/usr/lib/x86_64-linux-gnu/libasan.so.2'
the asan lib. But it seems like our Clang from mason does not like the
system's libasan. Also we'd need a suppression file for v8 and node.
for edges with the split flag false and in_backward_direction true
if in_forward_direction is also true backward segments can be incorrectly duplicated
Recent improvements to OSRM have led to a lot of changes to the Lua scripting interface, and refactoring of the default profiles makes them slightly more abstract and difficult to grok for those writing profiles from scratch.
This is therefore an attempt to fully document the attributes that can be read and set from Lua profiles. I've done it from my own understanding and from reading the source, but I may well have missed things or mistaken them!
The Map Matching plugin currently has issues with:
- high frequency traces and (performance)
- blobs, think noise at traffic signals (correctness)
This changeset implements trace-tidying transparently for the user.
We hopefully will see both performance gains as well as better matches!
This graph enables efficient boundary edge scans at each level.
Currenly this needs about |V|*|L| bytes of storage.
We can optimize this when the highest boundary nodes ID is << |V|.
Leaving log files opened was intentional to avoid missing output
that can appear `child.on('exit',...)`.
With this approach cucumber tests hit locally maximum number
of opened files, because node.js keeps all log files opened.
This commit removes all occurences of unconnected boundary nodes
and switches to the simple heuristic of picking U for the forward
and V for the backward node. This performs better than several
fancy heuristics.
By default, ExtractorConfig::requested_num_threads is Zero,
which is an invalid value for tbb task scheduler.
If user does not specify value greater than Zero, then
use tbb::task_scheduler_init::automatic.
Here's all I could get out of a instrumented `osrm-partition`; debug build,
with all the bells and whistles I could think of to make it more verbose:
```
==17928==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1560 byte(s) in 3 object(s) allocated from:
#0 0x7f4244185b30 in operator new[](unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cc:62
#1 0x7f4242a788b3 (/usr/lib/libtbb.so.2+0x208b3)
SUMMARY: AddressSanitizer: 1560 byte(s) leaked in 3 allocation(s).<Paste>
``
Symbolizing the address results in
```
echo "/usr/lib/libtbb.so 0x7f4242a788b3" | llvm-symbolizer
_fini
```
Looks like a crt finalizer => static global dtor "leaking" from tbb.
Which turned out to be a missing `tbb::task_scheduler_init` on our end:
> Using task_scheduler_init is optional in Intel® Threading Building
> Blocks (Intel® TBB) 2.2. By default, Intel TBB 2.2 automatically creates
> a task scheduler the first time that a thread uses task scheduling
> services and destroys it when the last such thread exits.
https://www.threadingbuildingblocks.org/docs/help/hh_goto.htm?index.htm#reference/task_scheduler/task_scheduler_init_cls.html
Without an explicit instanz the first call to a tbb algorithm seem to initialize
a global scheduler singleton which then "leaks" until the program exits.
Phew.
Implements parallel recursion for the partitioner
Fixes osrm-extract's -dump-partition-graph: accept no further tokens
References:
- http://www.boost.org/doc/libs/1_55_0/doc/html/boost/program_options/bool_switch.html
Pulls parameters through to make them configurable from the outside
Defaults are equivalent to:
./osrm-partition \
berlin-latest.osrm \
--max-cell-size 4096 \
--balance 1.2 \
--boundary 0.25 \
--optimizing-cuts 10
Fixes parallel_do call for Intel TBB 4.2 (Trusty): no range-based overload
Extends explanation for recursive bisection ids
Cleans up Bisection State
Removes license boilerplate from partitioner config
Sorts Spatially and picks Sources and Sinks
Uses sets for sources and sinks for now; see how large they will get
Runs n cuts in parallel changing the slope and uses the best
Clarifies balance <-> ratio naming
* Implements Random Access Iterator Facade for EdgeIDIterator
* Makes StaticGraph Node and Edge requirements explicit
* Cleans up Bisection Graph, Node and Edge
* Cleans up GraphView
- moves collapse into a dedicated set of functions / files
- make collapse scenarios distinct (slight performance cost)
- reduce verbosity for short name segments (now actually working, was supposed to do so before)
start assigning turn locations to test / further locations
add locations/make roads not overlapping - staggered
larger grid size for utf tests (new name)
This commit fixes issue #3588 "OSRM uses man_made=bridge lines to
route?" with exclusion of 'brigde' tag analisys from all profiles to
disable routing on bridges countours (with no highway tags)
Quick follow up for https://github.com/Project-OSRM/osrm-backend/pull/3570:
there is no reason not to build the `osrm-components` tool by defualt.
Backwards compatible. Users still specifying the option will see:
> Manually-specified variables were not used by the project:
> BUILD_COMPONENTS
c1f34c4 Release v2.11.0
d3b72e0 Updated change log.
2982b8d Update embedded Protozero to version 1.5.1.
cc1ab2a Add non-const WayNodeList::operator[].
3da372e Add missing example to examples/README.md.
30604ba Add OSMIUM_USE_SLOW_MERCATOR_PROJECTION define.
47a92e0 Clearer CheckOrder handler doc.
f11106d Formatting fixes.
a870737 Use faster implementation of web mercator projection.
041bb42 Test cleanups.
8933bc5 Cleanup *Map::get() functions.
6b989ca Document that (Multipolygon)Collectors only work with unique Ids.
8fb5bd2 Updated included Protozero to version 1.5.0.
76e153d Removed Makefile.
35d7ec9 Update copyright date.
a7f8126 Rename guard define to common scheme.
a923c69 Cleanup I/O tests.
d353993 Add Map::get_noexcept() method for all index maps.
94fa5ac Add const overload for mmap_vector_base::operator[].
3cf9184 Add default constructed "invalid" Coordinates.
358f170 Add Tile constructor from web mercator coordinates.
006aa4c Add index::RelationsMap(Stash|Index) classes.
9cc842e Updated catch to v1.5.9.
bd8c3b6 Use initializer_list trick instead of recursive template.
2c82a6f Merge pull request #183 from daniel-j-h/rvalue-apply
0bf5404 Implements rvalue handler support for apply, resolves#180.
ccaab08 Merge pull request #182 from AMDmi3/freebsd-endianess
bffe626 Handle endianess on FreeBSD properly
7250222 Code formatting and test cleanup.
6652436 Merge pull request #179 from oxidase/add_match_key_std_regex
afadf5b Rename centroid variables and function in example.
8355284 Add envelope() functions to NodeRefList, Way, and Area.
fc83d2e Remove unnecessary include.
9ddd00e Add match_key<std::regex> tag
9c54a53 Update README. Moved some infos to manual.
89a90a6 Update readme and developer docs.
c3446ec Simplify subitem iteration code and made it more flexible.
542b07c Add some static_asserts.
f0fd690 Memory reporting on M68k doesn't work properly.
e8957c6 Compare doubles in test using Approx().
58ae4a6 Add amenity_list example.
53783f8 Fix doxygen config for reproducible builds.
de4e52d Release v2.10.3
0cc42a2 ObjectPointerCollection constructor can't be noexcept.
4472dfb Round out ObjectPointerCollection implementation and test it.
28cb35d Build with XCode 8 and GCC 6 on travis.
03e3e66 Upgrade to new protozero version 1.4.5.
2102c2f Add assertion in queue handling code.
git-subtree-dir: third_party/libosmium
git-subtree-split: c1f34c45507e233a2b9028663906679c610fe179
If originalEdges gets initialized with 1 << 28, it will overflow and
thereby be set to 0.
Which defeats the point of checking for overflows in the first place.
LLVM 3.9.1 is now packaged in mason: https://github.com/mapbox/mason/issues/308
Upgrade our Clang compiler to the latest stable release.
Keeps clang-format at 3.8.1 for consistency.
This disables the `-flto` LTO flag by default since we're seeing
segfaults in compiler lto plugins, binutils and linker errors again and
again for various clang / gcc / binutils combinations.
Pass `-DNEBALE_LTO` to `cmake` in order to re-enable LTO.
LTO situation in short:
- LTO does not work at all for gcc<4.9
- With gcc>=4.9 the "slim" LTO format is getting used dumping IR
- Older binutils need LTO plugins which know how to read this IR
- Recent binutils handle this format all by themselves
- LLVM is more or less the same with some Clang versions segfaulting
If you need the performance benefit of LTO, make sure your compiler and
binutils are up to date and see for yourself if LTO builds work for you.
References:
- https://gcc.gnu.org/wiki/LinkTimeOptimizationFAQ
- https://github.com/Project-OSRM/osrm-backend/pull/3481#issuecomment-270618997
- https://github.com/Project-OSRM/osrm-backend/issues/3501
- https://github.com/Project-OSRM/osrm-backend/issues/3441
(and a ton of other LTO tickets if you search for them)
Lane Anticipation currently triggers on quick steps with lanes. This
changeset makes the "quick" part more dynamic by taking lanes left and
right of the turn into account. The reasoning for this is as follows.
The user can drive on the leftmost or rightmost lane and has to cross
all lanes left or right of the turn, respecitvely.
We scale our threshold appropriately, which now means the threshold
describes the duration the user needs for crossing _a single lane_.
Note: this is a heuristic and assumes the worst case. Which in my
opinion is fine to do since triggering Lane Anticipation in complex
scenarios is desirable.
This keep the metadata reader flag disabled by default unless explicitly specified.
Signed-off-by: FILLAU Jean-Maxime <jean-maxime.fillau@mapotempo.com>
adjust to generalFindMaximum function
moved parallel detection to ratio/absolute based regression testing
considerably improved detection quality using normalised regression lines
only follow initial direction/narrow turns for parallel detection
rename intersection (engine version) to IntermediateIntersection
follow coding convention for existing functions, move invalidate into routeStep
moved elongate into route step
move forward-step-signage into route step
replace post-processings `forwardInto` with `RouteStep` functionality. Don't change maneuver in step
separete declaration and implementation
Adds an `generate_hints=false` option which lets us skip generating and
emitting hints for Waypoints. This can be used to decrease the response
size when the user does not need hints anyway.
We should think about making `false` the default here in v6.
This change fixes two bugs:
1. A dead-lock that occurs between osrm-datastore and libosrm when an
old dataset is free during a data update. This happened because the
mutexes where acquired in a different order.
2. A region is deleted eventhough it is still in use. This happens when
libosrm gets overtaken by osrm-datastore, so the new dataset is in
the same region the old one was.
instead of artificially removing lanes from a roundabout, we don't assing them in the first place.
this also prevents a problem where we would end up collapsing turns with lanes in a roundabout
These kind of roundabouts came up during Lane Handling for roundabouts.
They're called Turbo-roundabouts or Turbine-roundabouts and are very
popular e.g. in Germany and the UK.
Seems like our roundabout handler sometimes is getting confused.
Trying to figure out why, and codifying some scenarios for cucumber.
References:
- https://github.com/Project-OSRM/osrm-backend/pull/2693
removes duplicated includes
removes unused includes
eliminates dedicated toolkits that resulted in circular dependencies
moves functionality close to data, where possible
Usage:
struct MyIntersection : EnableIntersectionOps<MyIntersection> {
};
Done.
We require MyIntersection having at least the member attributes from
IntersectionViewData but don't enforce a inheritance hierarchy.
Changes the processing order in the edge based graph factory.
Instead of iterating over all outgoing edges in order, we compute the edge
expanded graph in the order of intersections.
This allows to remember intersection shapes and re-use them for all possible ingoing edges.
Also: use low accuracry mode for intersections degree 2 intersections
We can use lower accuracy here, since the `bearing`
after the turn is not as relevant for off-route detection.
Getting lost is near impossible here.
d5ecf4d Release v2.10.2
7c04564 Update embedded protozero to version 1.4.4.
e209d81 Write code for 64bit systems, so it compiles on 32bit w/o warning.
640217c Fix buffer overflow.
8b4620f Release v2.10.1
38bf3ab Update protozero to 1.4.3.
f81b3c6 Fix IdSet on 32 bit.
5ff4753 Workaround so the test works on 32bit systems.
7542694 Include our endian.hpp before using the endianness test macros.
git-subtree-dir: third_party/libosmium
git-subtree-split: d5ecf4df90e2995c816886d2a002c3d3de7062ee
40c4a48 Release v2.10.0
6addb2e Search for protozero also in the place where libosmium was found.
9c0d4bb Consistently use lhs and rhs as parameter names in operators etc.
6179759 Update change log.
894eb7d Explicitly use size_t to get no narrowing conversions.
e549e73 Fix CMake config for index_lookup.
ccf0bc2 Fix bug where some compilers deduce the wrong type.
fc3507d Cleaned and documented index example and renamed to osmium_index_lookup.
d3c3036 Rename serdump example to dump_internal and document it.
0e9822e Also forward set_uid_from_signed() function.
29ef95c Rename build_taglist function because it was to similar to build_tag_list.
c088dd0 Move static constant out of class so clang will compile it.
606cdc4 Fix CMake build script: Path for finding libosmium.
65f91fe Removed unused typedef.
07174f5 Use condition_variable to tell producer when thread queue is not full.
b35e957 Some code cleanup in XML parser.
c703dff Fix problem with MemberMeta.
1ccbbef Refactoring CompressionFactory.
6561bd6 Use our own exception type for map factory errors.
56e31fa Throw not_found error directly instead of using helper function.
28230c3 Test empty value for node location store, reorganize tests.
2ba316c Reorganize and fix projection tests.
f949485 Don't run quite as many tests with projections because they are slow.
1bad16d Add information about build environment to benchmark output.
99617bb Change proj_geojson benchmark into mercator benchmark.
553b946 Allow optional parameters on Reader in any order.
dcc3d8f Factor out some common code.
004d8cd Fix forwarding constructor.
9702978 Fix metadata check.
6cfb6c4 Faster implementation of decode_dense_nodes without reading metdata.
4ba4638 Add additional read_metadata parameter to other Reader constructors.
d005937 Optionally ignore metadata when reading file.
63961da Mark all CRC32 update functions as noexcept.
cc4ca75 Refactor set_user() function to speed it up.
38d19dc Update comments with file sizes. OSM has grown...
f7d0824 Add new benchmark that shows performance when main thread is busy.
25070dc Use const ref params.
88e8d96 Mark add_user() as deprecated.
f58d9db Refactor some low-level collection code to clean up code.
4680def Add example showing how to create OSM data out of thin air.
d42fd50 Add an example showing how tags in OSM files can be changed.
49bf5bc Add additional constructors to Builders taking a reference to parent.
7b91d63 Change Builder::add_item() to take a reference instead of pointer.
2957e48 Some cleanup of examples.
d0b458d Calculate size of object at compile time.
3fbb6e7 Use explicit cast.
1851f3d Remove a test that depends on math details.
f6a0802 Various cleanups of example programs.
ba4921f Rename add_user() to set_user().
d7637c9 Various cleanups related to builders.
07827bc Fix add_user().
9a5b395 Also refactor OSMObjectBuilder like ChangesetBuilder before.
b1f423c Use call chaining on the builder.
e49473d Get rid of ObjectBuilder class.
67d70b9 Refactor ChangesetBuilder::add_user().
8199c33 Make ChangesetBuilder derive directly from Builder.
61d1b67 Simplify some code.
d38467a Change derivation hierarchy of some builder classes.
b52f8af Refactor Builder code.
d012bfa Refactored some code setting attributes on objects using builder instead.
6a05f60 Also forward set_removed function from builders.
8d63b7d Return *this from Builder setter functions and test it.
72a1266 Update catch.hpp to newest version.
3424a74 Check GEOS version is <= 3.5.
aee9f9d Cleanup test code.
aef198c Improved asserts in Buffer.
a98b9bf Code cleanup in tests.
a150466 Use GDAL/OGR instead of GEOS to test our WKB implementation.
b04a525 Refactor test.
39aa932 Refactored test_factory_with_projection so it works without GEOS.
648f43a Remove unused dependency on geos from tile test.
f1748ae Add setters to Builder classes forwarding to underlying objects.
8166879 In debug mode check that Builders are correctly called and destructed.
1c4257e Call commit() on buffer only after all builders are destructed.
2618636 Add functions to check availability of relation members.
b45a4d9 Mark RelationMember::set_ref() as deprecated.
7886771 Move "basic" and "buffer" tests to "osm" and "memory", respectively.
b664685 Use functions instead of macros in location test for faster compile.
b4929ac Add more tests for number parser.
02662a7 Merge pull request #171 from lonvia/fix-long-exponentials
5344a6c fix parsing of numbers in e-notiation with many post-comma digits
3aeaff3 Add some typedefs to NodeRefList and memory::Collection.
e750665 Add iterators to IdSetSmall and add docs and tests to IdSet classes.
50ecb2a Add more features to IdSetDense, including unset and iterator.
e3dec78 Make IdSet virtual base class with two implementations.
8ea0153 Use C array instead of std::array in IdSet and clear explicitly.
3ba9905 Deprecate osmium::index::BoolVector in favour of new IdSet.
453d1ca Add osmium::index::IdSet.
c78254e Add function to (temporarily) disable the progress bar.
4d88a9f Better document osmium::io::Header class.
320e3af Look for protozero includes in CMake config.
838d25e Allow optional checking for libosmium version number in CMake config.
6ce60c1 Fix entity_bits static_assert() tests.
f054731 Update change log.
77ac4c2 Make sleep duration for full queues much smaller.
7e39c01 Make some entity_bits functions constexpr.
69ea72f Fix ~ operator on entity_bits and more tests for entity bits.
dafe4cf Update embedded Catch unit test header to version 1.5.7.
a41c832 Fixed parsing of location coordinates starting with decimal dot.
6523bae README cosmetics.
229acac Add tests for some examples.
f1e753d Merge pull request #163 from sebastic/executable-not-elf-or-script
ccea2d5 Remove executable bit from .cpp files.
af77fb4 Changelog formatting fixes.
git-subtree-dir: third_party/libosmium
git-subtree-split: 40c4a48f88d25edace6f0b9e079c306308c7760b
58ae447 bump to v0.1.1
c5ef33f rename llvm 4.x to 4.0.0 [skip ci]
5d5d26b add llvm 4.x based sub-packages
9708680 only set LIBCXX_ENABLE_STATIC_ABI_LIBRARY for linux [skip ci]
6918fb0 install LLVMgold.so on linux [skip ci]
ab20ff7 binutils: using 'all-gold' breaks make install on linux [skip ci]
cb8b15f fix binutils install [skip ci]
df77b02 properly set LLVM_BINUTILS_INCDIR value [skip ci]
295d4db binutils gold fixes [skip ci]
ac85676 enable LLVMgold.so for linux [skip ci]
acc4249 add binutils 2.27
16d4452 add lldb and llvm-cov 3.8.1 packages
757b908 remove patching no longer needed [skip ci]
69415b5 better fix for statically linking/linked libc++ with llvm 3.8.1 [skip ci]
43933ed Added mesa-13.0.0-glx (non-CXX11ABI)
2bb81cc Added mesa-13.0.0-glx
d70e3ef LLVM_EXTERNALIZE_DEBUGINFO is osx specific
ba737bf llvm 3.8.1 linux build fixes
4279f58 Updates for mesa 13.0.0
d544278 Revert typo in mason.sh
03ecb2c Add mesa 13.0.0 (Gallium-OSMesa)
0997905 Add expat 2.2.0
f41eb6d mason.cmake: multiple static libs also need to be split
c9fcd1a add lldb to llvm 3.8.1 [skip ci]
6d8e16c minor llvm/clang++ improvements
b2bdb33 Add note that we need to create a github release [skip ci]
git-subtree-dir: third_party/mason
git-subtree-split: 8df14782dda0c2c7314b5c6dba98e9e36a67eedc
# The first commit's message is:
Add support for building against mason-provided deps
# This is the 2nd commit message:
back to just one travis job: linux/release
# This is the 3rd commit message:
remove pkg-config debugging [skip ci]
# This is the 4th commit message:
use clang++ 3.8.1 for mason builds since 3.8 is what we have been using
- Travis: Upgrade clang from 3.8.0 to 3.8.1 (provides smaller package for faster downloading)
- Travis: Makes BUILD_COMPONENTS an option
- Followup after #3130 (Boost_LIBRARIES variable no longer exists)
From stxxl FAQ: "you should not share a data structure between
threads (without implementing proper locking yourself)."
The access to name_char_data can be implicitly parallelized
if _GLIBCXX_PARALLEL is defined and invalidate local-thread iterators.
- Builds up ENGINE_LIBRARY_LISTING correctly to pass to pkg-config
- Previous behavior had major flaw and would result in paths in libosrm.pc like: "-L-L"
when the data was "-L/path -lfoo" or just "-lpthread" with no -L/path. It only worked correctly for static libraries
- Refactors to call find_package for boost in one place (helps prepare for upcoming mason PR)
Removes CompressedEdges from the extractor and shared data format by
directly serializing vectors of node ID's, forward weights and reverse
weights for each node-based-edge
Refs #2575
This PR adds more advanced coordinate extraction, analysing the road
to detect offsets due to OSM way modelling.
In addition it improves the handling of bearings. Right now OSM reports
bearings simply based on the very first coordinate along a way.
With this PR, we store the bearings for a turn correctly, making the
bearings for turns correct.
* cucumber test scenarios, #3027
* post review comments
* two tests are still failing
* fixed one test
* passing tests
* cleaner code refactor
* possible sceanrios for destination:ref:forward/backward
* added code for direction:ref:forward/backward, tests pass
* changelog
* store direction in variable
* added tags to taginfo
* fixed dumb error
* use boolean flags
* null pointer checks
* hopefully better null pointer checks
This switchtes the data even if there are requests still running on the
old data. osrm-datastore then waits until all of these old requests have
finished before freeing the old regions.
This also means that osrm-datastore will return with an error if there
is a data update currenlty in progress.
Changes the internal representation of compressed geometries to be a
single array shared between forward and reverse geometries that can be
read in either direction. Includes a change on
extractor::OriginalEdgeData to store via_geometry ids that indicate
which direction to read the geometry for that edge based edge.
Closes#2592
Technically speaking we're changing the `libosrm` API.
But since we're only lifting restrictions by marking the API threadsafe,
we should be fine here.
80df1d6 Release v2.9.0
110dc5c Update change log.
6ad5829 Better handling of areas with duplicate segments.
f5985ed Better exception message for invalid areas.
fa09300 Explicit cast to make intent clear.
6f9b522 Fix name of struct stat on Windows.
6b0a47b Clean up code in data tests.
aa1226c Fix progress bar.
3663a19 Extend ProgressBar class so that it works with multiple files.
40c4d5a Add version of file_size() taking a file name.
43a2fac Merge pull request #162 from osmcode/windows-build-scripts
cc2305d [skip travis] 1st iteration of new build scripts
7abe4e1 Clean up disk location cache examples.
48841d5 Update change log.
cf854e9 Change timestamp parser.
01aa8c7 Add examples osmium_pub_names and osmium_road_length.
483c9f2 Benchmark code cleanup.
3ffea2d Cleaned up some test code.
80f0ff7 Explicit conversion from int to bool.
0ba5918 Write space after progress bar to defend against glitches in output.
8584423 Change progress bar to take max_size on construction.
d2c7585 Only call gzoffset when compiling with zlib > 1.2.4.
1b417e5 Add support for a progress report in osmium::io::Reader().
3b4c8c8 Minor cleanup of appveyor config.
d787e25 Fix OPL parser: Relation member without role at end of line.
53ca080 Make lots of variables const.
d776ab2 Add to change log.
eec3b62 Properly initialize m_data field.
cc607e1 Take argument by const ref.
be1e346 Remove unused function.
2a356ee Make lots of one-argument constructors explicit.
adca74f Add comments to and cleanup up examples.
381e535 Simplify WKB code.
b49efd8 Fix opl_parse_changeset_id() return type.
bb52e57 Use uint64_t for line count and column to be on the safe side.
243f6a7 Use parentheses to make sure the right precedence is used.
5a7648e Consistently catch by const ref unless var needs to be non-const.
e3be990 Avoid some warnings.
c436d92 Do not include unistd.h on Windows.
95b228c Add dummy function to avoid warnings.
f276ca3 Fixed includes and changelog update.
8c54bd9 Change timestamp error message.
27e1d5c Add OPL parser.
1d2caab Add more includes to osm.hpp to make usual osmium use simpler.
9d88361 More tests for area CRC.
4f8964d Initialize Item::m_diff member on construction.
f2b648b Parse coordinates in scientific notations ourselves.
b01323f More include fixes.
69f39d4 Fix some includes.
156536d Make padded_length a plain function, not a template function.
65cd1dc Extend functions to set Location lon/lat.
98b7b17 Update to protozero 1.4.2.
a6420cf Add diff indicator to items and use for diff opl and debug output.
0ef02a3 Add workaround for YCM.
3a986f4 Update protozero version.
5245c5b Document osmium_count example program and add memory usage output.
796ca13 Document handler class.
2ba1c1f Add example for mercator projection and tiles.
201f744 Restrict tiles to zoom <= 30.
202291d Add member_type_string class.
494ed6e Cleaned up Tile tests.
af13a8b Add documentation and range checks to Tile struct.
9df5d91 Some small changes to avoid conversion warnings.
afac031 Explicit cast to avoid warning.
8188f66 Better contribution info.
fa89d1d Fixed a problem limiting cache file sizes on Windows to 32 bit.
23a89df Remove obsolete info about versioning from CONTRIBUTING.md file.
115ae23 Release v2.8.0
4174b3c Style fix.
1795dcb Function wait_and_pop_with_timeout() is not needed any more.
4a3a71b Fix for possible threading problem.
cc85925 Updated change log.
67bc8b1 Use unordered_map instead of map in PBF string table code.
18b7b66 Set better default for string table chunk size and document it.
e6d7410 Remove dependency on sparsehash and boost program_options for examples.
14d92d6 Fix regression: Debug output of invalid location works again.
ef91ce1 Bugfix: PBF String table corruption when there are many strings.
649af78 Remove DeltaEncodeIterator completely.
56e5ac2 Function getting queue sizes from environment uses default when getting 0.
bfaab7d Add change log.
d260339 Remove use of PROTOZERO_STRICT_API macro.
c61722d Remove use of DeltaEncodeIterator simplifying code.
f7c60b6 Updates for new protozero.
0bdfb9d Updated change log.
bb56cbb Switch to newest protozero 1.4.0.
9e19a82 Add ccache support to CMake cnfig, better travis builds.
00d8868 Make I/O max queue sizes configurable via environment.
dc7e504 Remove unused debugging code.
13f66a0 Track pop() calls and queue underruns when OSMIUM_DEBUG_QUEUE_SIZE is set.
5c2e367 Add EWKT support.
8f7c7d3 Automatically set correct SRID when creating geometries.
ff11893 Better check of optional components in CMake config.
4562429 Use fallback implementation for coordinates given in scientific notation.
3bdf46e Mark enable_debug_output() as deprecated.
ea1093e Update catch unit test framework.
8623f1e Release v2.7.2
e135dd8 Fix data corruption regression in mmap based indexes.
adbd3b0 Do not output empty discussion tags in changeset XML output.
8126fbb Formatting.
c6970fd Fix coordinate output.
3471b4b Resize output string once in output_int().
0ddf0e7 Use our own function to convert integers to strings instead of printf.
f9a1dd3 Reading and writing coordinates is now independant of locale.
8104294 Use hand-crafted function for hex output (faster than printf).
0bb452a Fix links in change log.
1862d06 Release v2.7.1
8bfe2ba Release v2.7.0
c3604f3 Use 64bit counter in area stats.
9e589b3 Update gdalcpp.hpp from upstream.
fd55d9b Cleanup of OGR-related code.
d0c53e0 Fix bug: Relation wasn't found correctly from member.
24145f9 Use make_iterator helper function.
a8a287d Refactor count_not_removed function. (No template necessary.)
389332a Also print removed flag from member_meta.
5e7c5d0 Remove unnecessary overload of begin() and end() function in iterator_range.
2ec007f Do not add rings to invalid area, even if create_empty_areas is set.
fee8b73 Optionally keep type tag in area assembler. Better doc for config.
c7e1f8a Fix timer output in assembler code.
032ab40 Update change log.
dcfa439 Node location store keeps track of whether node ids are ordered.
54d5eb8 Add tests for new file based index code.
4fe5b30 Use correct empty value when initializing index.
40b5c79 Static or not static, that is the question.
aaa9b46 Open index file with minimum size, because zero-sized mmap is not allowed.
fea2337 Fix for disk-based indexes.
428a413 More tests of corner cases for id to location index.
9d2a31b Add config option to areas assembler for only creating some areas.
d11bf8d Count and report inner rings with the same tags as relation/outer rings.
bde10c4 Speed up copy of tags.
e4c9f87 Revert "Consistently remove some tags from area."
9cd7a03 Set areas assembly config setting create_empty_areas to true by default.
660fb63 Better ordering of OSMObjects.
b4199c2 Use std::strcmp instead of just strcmp.
579c34b Better field width/precision in problem reporter.
a2ebeeb Use field names with 8 characters or less in OGR problem reporter.
ef523fe Switch remaining "typedef"s to "using".
19425f8 Switching from "typedef" to "using" in geom code.
b13c2be More cases of switching from "typedef" to "using".
7f53977 Refactoring iterators: Not derived from std::iterator any more.
1922224 Consistently remove some tags from area.
295495f Fix check for detecting wrong role.
9aa6d46 Report more IDs in problem reporters.
d7a5da7 Remove now unused spike segment reporter.
0666d66 Only report duplicate segments if they belong to the same way.
9e17f89 Improved error reporting for area assembler.
e983a48 More code cleanup and docs.
927eeda Replace awkward std::pair construct by real class.
d0543b9 Various area code refactorings.
0ae8f07 Do not build areas for ways with tag area=no.
d4cabe7 Add some convenience functions to check for tags in TagList.
99f4be9 Add missing include.
a8dda78 Travis: Only run tests if build succeeded.
9db3034 Add missing "nodes" fields.
50e9fcb Report ways that are in multiple rings as errors.
58a3669 Add some paranoia asserts.
3958c1d Use iterator_range to make equal_range results easier to use.
c12c710 Add for_each_member() function to iterate over members of an mp relation.
ca35452 Change argument order in create_area() functions.
4473ae1 Keep stats on multipolygons with no tags on the relation.
12c5335 Bugfix: Check that there is a problem reporter before using it.
ec2afce Update change log.
5af2ec9 Use new area assembler interface in multipolygon collector.
73e3440 Some code cleanup in area code and new interface for calling assembler.
7737479 Add the number of nodes in area to problem reporter.
b4f9343 Use const_iterator where possible.
02372b2 Simplify code that checks for open rings.
8d6099e Pull out location_to_ring_map into details ns and add == and < ops.
1a05042 Mixed code cleanups and added comments.
4b8d1be Ignore empty role when checking inner/outer roles on multipolygons.
e22f573 Now GCC is complaining about the clang pragma...
48000c0 Add some missing includes and forward declarations.
ba9504a Workaround for bug in old libc.
a138265 Completely new algorithm for assembling multipolygons.
74054bd Add specialization of std::hash function for Location.
5ed4c90 Use newest gdalcpp.hpp with implicit transaction support.
676949e Add "locations_on_ways" support for OPL format, too.
ce05c19 Add support for reading/writing XML/PBF files with locations on ways.
62b2ee4 Fix checksum test.
bd512a8 Added "add_crc32" file option for adding CRC32 checksum to debug output.
3a100fa Incorporate locations in NodeRefs into CRC32 checksum.
ac02f86 Update catch.hpp to newest version. Removed outdated info in README.
481f48b When assembling areas ignore ways containing no or only a single node.
a0ae33a Fix unsigned overflow in pool.hpp.
91b8adf Fix undefined behaviour in WKB writer.
697f460 Check results of dynamic casts.
f1e4571 Fix from_item_type() implementation so it also works with undefined type.
65df99b Add future_queue_type alias to simplify code.
4340e4d Removed SortedQueue implementation which was never used.
cdd8f8c Add version.hpp with macros defining version of the library.
ff5d42a Update to newest gdalcpp.hpp.
a184f66 Update change log.
0ea76f7 Add osmium::Area::outer_rings() and inner_rings() functions.
b0404b7 New ItemIteratorRange class for iteration over buffers and subitems.
eff8a7c Add default type to string_to_object_id for IDs without type prefix.
e877a6f Clean up code inner vs. outer ring in geometry factory.
9224be5 Disable use of XML entities in OSM files.
9d9fa08 Output operator of location shows full precision of coordinates.
9a8e7c0 Documentation fixes.
git-subtree-dir: third_party/libosmium
git-subtree-split: 80df1d6850bdfa661587839b77dcea0ab8fc814a
Takes a stricter aproach for whitelisting / blacklisting restrictions:
- uses `restriction=`
- uses more specific `restriction:<type>=`
- uses `except=<type>` to invert
Where `type` is the type of transportation to restrict, e.g. `motorcar`.
https://github.com/Project-OSRM/osrm-backend/issues/2833
With @karenzshea's name / ref split (ref. #2857) in master we want to
make use of it and reduce `NewName` instructions when ever possible.
This is a first step towards #2744 by using the already existing name
change heuristic from the extractor now in post-processing as well.
Limitations: at the moment we don't have the `SuffixTable` in
post-processing; this would require us serializing and subsequently
deserializing the table, passing it through from the profiles to the
API.
Before we only worked on subsequent quick turns, as in:
`right, right` keeps the user on the rightmost lanes.
This changeset modifies the logic to work on any subsequent steps
that are "quick" and have lane information we can constrain later.
Because we do not have a from-lane => to-lanes mapping we take the
lanes left and right of the turn lanes into account when heuristically
assigning the leftmost / rightmost lanes.
There are some edge cases where this still does not give us the optimal
solution but it gets close to what is actually possible at the moment
without having a lane mapping in post-processing.
References:
- https://github.com/Project-OSRM/osrm-backend/issues/2625
fix rebase
Issue 2785: check gold binutils version and don't use gc-sections for versions prior 2.25
due to https://sourceware.org/bugzilla/show_bug.cgi?id=17639
readelf --debug-dump=frames build/libosrm_extract.so
Contents of the .eh_frame section:
...
readelf: Warning: Invalid length 0xfff01dd8 in FDE at 0x000020
Currently we don't route over the Golden Gate bridge by default.
This sets the value to false by default. To test the behavior for
tolls when ignored, we would need issue #2781 implemented.
Roundabout Intersections are roundabouts with up to four ways and turn
angles which makes the turns obvious, e.g. as in:
```
*
*
* * * *
*
*
```
but not
```
*
*
* * *
* *
* *
```
For Roundabout Intersections we issue instructions such as
"turn <direction>" instead of "take the <nth> exit".
At the moment we have a limit on the radius for these Roundabout
Intersections of 5 meters. Which fails to classify a wide range of
Roundabout Intersections in the US (with the US-wide streets).
This changeset removes the Roundabout Intersection radius limit:
- if the roundabout is larger than a threshold and is named we classify
it as a rotary
- if the roundabout matches our criteria for Roundabout Intersections
we classify it as a Roundabout Intersection
- else fallback to plain old Roundabout
There is a second issue with determining a roundabout's radius.
But that's for another pull request (tracking in #2716).
References:
- https://github.com/Project-OSRM/osrm-backend/issues/2716
- Clarifying guarantees between patch/minor/major versions
- Consolidating version release flow into one flow for patch/minor/major versions
- Add constraint that all minor/major released code needs to have had a release candidate before
Staggered intersection are very short zig-zags of only a few meters.
They are common in rural and exurban areas, especially in the US.
(In addition, these cases could as well be tagging issues)
We do not want to announce these short left-rights or right-lefts:
* -> b a -> *
| or | becomes a -> b
a -> * * -> b
Here is one example:
- https://www.openstreetmap.org/edit#map=20/39.26017/-84.25182
And here are two edge-cases that we don't handle at the moment:
- http://www.openstreetmap.org/edit#map=20/38.87900/-76.98519
- http://www.openstreetmap.org/edit#map=19/45.51056/-122.63462
and probably should not handle since the distance in between is
quite long (roughly 7-15 meters). For these we want to announce
two turns to not confuse the user.
Thanks to @1ec5 for raising this issue and @karenzshea for
providing additional US examples and cultural insights.
https://github.com/Project-OSRM/osrm-backend/pull/2685/files
fixes an issue where we did
elongate(fstStep, sndStep);
instead of
newStep = elongate(fstStep, sndStep);
we didn't get any warnings.
The only way to trigger a warning here is to use
```cpp
__attribute__((warn_unused_result))
```
This changeset does exactly that: for the new guidance code prone to
these kind of issue we add such an attribute to the declaration.
After half a day of looking at the tagging and the data came to the
following conclusion:
We can't keep the user to the innermost / outermost lanes depending on
the exit the route takes: we found situations where both heuristics were
wrong.
Even on popular roundabouts the tagging is often wrong or in the best
case not present at all.
There are at least two different ways to interpret roundabout
indications: 1/ where e.g. a right arrow on the lane indicates turn
restrictions for the roundabout and the need to take this lane to exit
the roundabout to the right (possibly skipping multiple exits) and 2/
where a right arrow just means this is a lane in a immediate right turn.
Example: Australia marks lanes with arrows that seem to indicate
"angles you can exit the roundabout from", for example, these two ways:
- http://www.openstreetmap.org/way/320941710
- http://www.openstreetmap.org/way/42918021
Whereas Germany marks lanes with "directions you can travel in these
lanes immediately after entering the roundabout":
- http://www.openstreetmap.org/way/52578338
These two different interpretations of how to draw the arrows on the
roads mean we have conflicting solutions to "which lanes can you use to
take exit B from entry A" based on locality.
Continuing to tag ways based on lane markings is no problem, but
unfortunately, we can't reliably resolve good advice for navigation
system users (like "use the inside lane to take the second exit at the
roundabout"), there are too many situations that would generate bad
instructions (instructions that tell users to go into a lane they
shouldn't use).
Before we asserted on unique lane indications per lane. Turns out the
OSM data contains lane strings such as:
left;left|right
Which represents two lanes as in:
<< >
|| |
The two left indications _on a single lane_ look like data issue.
And we can't represent this with our enum-approach at the moment.
We don't want to crash there, so silently swallow this and
generate a single left|right for it.
This changeset implements Lane Anticipation on roundabouts, delimited
by enter / leave step pairs. It does not handle lane anticipation
within a roundabout.
Lane anticipation happens on the granularity of a valid roundbaout:
We discard partial roundabout (enter without exit or exit without
enter) or data issues (no roundabout, exit before enter).
Related:
- https://github.com/Project-OSRM/osrm-backend/issues/2626 for lanes
within a roundabout
- https://github.com/Project-OSRM/osrm-backend/issues/2625 for handling
going straight in lane anticipation
We build `osrm_contract` (the library) linking in libtbb. We then
build `osrm-contract` (the binary) linking in `osrm_contract` (the
library).
Because we're only using TBB's `parallel_invoke` in the code for the
binary, it seems like the linker discards some symbols in the library.
Therefore we have to link libtbb for the binary again. Even worse, the
order now matters: if we first link in `osrm_contract` and then libtbb,
we're still hitting the issue re. discarded symbols.
Therefore we first link in all dependencies (libtbb, libboost*), and
only then `osrm_contract`.
Strictly speaking, we probably have to do this for all of our binary
targets, or we will hit similar issues in the future.
From
> [warn} oops
to
> [assert] /tmp/osrm-backend/src/extractor/extractor.cpp:79
> in: int osrm::extractor::Extractor::run(): false
> terminate called without an active exception
This is more of a hack but looks like the best we can do.
The reason for this is the following:
1/ we require strict mode for our v4 script
2/ v0.10 in strict mode marks 'let' as a reserved keyword,
aborting before execution any code in the script. Thus,
we can't assert e.g. on process.versions['node'] !== '4'.
Aligned blocks prevent bus errors in NEON/VFP instructions.
Block pointers are aligned to 4 bytes, that is guaranteed
by aligned mmaped-pointers, the 4 bytes size of the CANARY block and
aligned sizes of blocks.
Failing test
features/car/traffic_turn_penalties.feature:33
Tables were not identical:
from | to | route | speed | time
| a | h | ad,dhk,dhk | 63 km/h | 11.5s +-1 |
| i | g | fim,fg,fg | 59 km/h | 12s +-1 |
| (-) a | (-) e | (-) ad,de,de | (-) 57 km/h | (-) 12.5s +-1 |
| (+) a | (+) e | (+) ad,de,de | (+) 58 km/h | (+) 12.5s +-1 |
| c | g | cd,de,ef,fg,fg | 63 km/h | 23s +-1 |
| p | g | mp,fim,fg,fg | 61 km/h | 23.5s +-1 |
| a | l | ad,dhk,kl,kl | 60 km/h | 24s +-1 |
| l | e | kl,dhk,de,de | 59 km/h | 24.5s +-1 |
| g | n | fg,fim,mn,mn | 57 km/h | 25s +-1 |
* formats 'hh:mm:ss' and ISO 8601 are merged into one grammar.
* iso_8601_grammar is changed to static const.
* iso_8601_grammar supports formats P[n]DT[n]H[n]M[n]S, P[n]W,
and part of alternative PTHHMMSS and extended PTHH:MM:SS formats.
Currently supports duration and distance for each coordinate.
This is particularly useful in map-matching, comparing how
a trip progresses compared to a real GPS trace that is
map-matched.
Changes:
* LeafNode is aligned to LEAF_PAGE_SIZE.
Alignment brings 24 bytes memory overhead for 4096, but reduces
cache misses rate.
* Unused m_element_count from leaf nodes file.
The size is computed as m_leaves_region.size() / LEAF_PAGE_SIZE.
* Added try/catch for mmap exceptions messages.
candidate_cache is removed because of failing test
make util-tests && ./unit_tests/util-tests --run_test=*/construct_multiple_levels_test
first bad commit: [9692be6f50] Add cache for CandidateSegments to reduce heap worke even more
Now SegmentIndex contains leaf index, object index and fixed_projected_coordinate
In windows native strings in Lua incorrectly
interpreted because native separators must be escaped.
Use of generic strings prevent use of backslashes and
"Generic paths are portable and independent of the operating system.".
Can be used as in:
function way_function(way, result)
for node in way:get_nodes() do
local id = node:id()
io.write(">>> " .. id .. "\n")
end
-- ...
end
Warning: we do not use libosmium's location cache, therefore .location()
on the nodes will crash at runtime. Once we switch to using libosmium's
cache this should work. Until then, you can use the node id now.
To fix#2193 prefix_length member variable has been added to ParsedURL
that is set to the length of "/service/version/profile/" prefix
when the prefix is accepted by the parser.
Also BOOST_FUSION_ADAPT_STRUCT for osrm::server::api::ParsedURL
has been moved from header to url_parser.cpp to speed up compilation
of CUs that do not use the fusion adaption.
* signature changed from void() to void(engine::api::Parameters&)
* performance increase due to use "static const GrammarT" and avoid
construction and destruction of grammars during parsing
* removed code duplication in inherited grammars
* rule unlimited changed to qi::lit
* added rule size_t_
* parser accepts "&geometries=" and "&overview=" and fails at "foo"
instead of "&geometries=foo" and &overview=foo
* added expectations checks for derived grammars
* changed rules qi::list(".") to character rules '.'
Daniel's mental model, with updates from Patrick and staring at the code
(plugins/trip.cpp): Trip first snaps coordinates which in the case of
phantoms that are not only in small components with the same id
switches small components to big ones. Therefore we get either only
small or only big components. Only then the Tarjan SCC decomposes this.
Result: multiple subtrips only happen for islands or continents.
This increses query performance dramatically for queries with a lot of
coordinates. However it increases the internal memory usage of the
StaticRTree also 4x.
Also, when trimming the last step, we need to copy name values from the new next-to-last step, otherwise
we can still end up with an arrive step on a different road to the last maneuver.
StaticRTree now uses projected coordinates internally. That means we can
use a euclidean distance measure (squared distance) for sorting the
query queue.
Phew, this was painful. Turns out most hints out there on how to use the
Boost serialization iterators are wrong. Here's why:
transform_width<6, 8>
needs an input stream of length: common multiple of 6 and 8.
That is, the padding needs to happen _before_ using the provided
iterators, otherwise the behavior is undefined!
See: http://www.boost.org/doc/libs/1_60_0/boost/archive/iterators/transform_width.hpp
Thanks @mokob for pointing that out to me!
We also need to manually add as many padding chars "=" to the encoded
result as many bytes we had to append to the input to conform to the
rule above.
Decoding then knows the number of padding chars by counting for "=" and
then using it in order to split off the last bytes from the decoded
result.
- FIXED: integer overflow in `DynamicGraph::Renumber` [#5021](https://github.com/Project-OSRM/osrm-backend/pull/5021)
# 5.16.5
- Changes from 5.16.4:
- Debug:
- ADDED: Made toEdges allocation more robust and add better memory usage debugging.
# 5.16.4
- Changes from 5.16.3:
- Bugfixes:
- FIXED: Properly calculate annotations for speeds, durations and distances when waypoints are used with mapmatching [#4949](https://github.com/Project-OSRM/osrm-backend/pull/4949)
# 5.16.3
- Changes from 5.16.2:
- FIXED: Remove the last short annotation segment in `trimShortSegments` [#4946](https://github.com/Project-OSRM/osrm-backend/pull/4946)
- Performance
- FIXED: Speed up response time when lots of legs exist and geojson is used with `steps=true` [#4936](https://github.com/Project-OSRM/osrm-backend/pull/4936)
# 5.16.2
- Changes from 5.16.1:
- Bugfixes:
- FIXED #4920: Use smaller range for U-turn angles in map-matching [#4920](https://github.com/Project-OSRM/osrm-backend/pull/4920)
# 5.16.1
- Changes from 5.16.0:
- Bugfixes
- FIXED #4909: deduplication of route steps when waypoints are used [#4909](https://github.com/Project-OSRM/osrm-backend/issues/4909)
# 5.16.0
- Changes from 5.15.2:
- Guidance
- ADDED #4676: Support for maneuver override relation, allowing data-driven overrides for turn-by-turn instructions [#4676](https://github.com/Project-OSRM/osrm-backend/pull/4676)
- CHANGED #4830: Announce reference change if names are empty
- CHANGED #4835: MAXIMAL_ALLOWED_SEPARATION_WIDTH increased to 12 meters
- CHANGED #4842: Lower priority links from a motorway now are used as motorway links [#4842](https://github.com/Project-OSRM/osrm-backend/pull/4842)
- CHANGED #4895: Use ramp bifurcations as fork intersections [#4895](https://github.com/Project-OSRM/osrm-backend/issues/4895)
- CHANGED #4893: Handle motorway forks with links as normal motorway intersections[#4893](https://github.com/Project-OSRM/osrm-backend/issues/4893)
- FIXED #4905: Check required tags of `maneuver` relations [#4905](https://github.com/Project-OSRM/osrm-backend/pull/4905)
- Profile:
- FIXED: `highway=service` will now be used for restricted access, `access=private` is still disabled for snapping.
- ADDED #4775: Exposes more information to the turn function, now being able to set turn weights with highway and access information of the turn as well as other roads at the intersection [#4775](https://github.com/Project-OSRM/osrm-backend/issues/4775)
- FIXED #4763: Add support for non-numerical units in car profile for maxheight [#4763](https://github.com/Project-OSRM/osrm-backend/issues/4763)
- ADDED #4872: Handling of `barrier=height_restrictor` nodes [#4872](https://github.com/Project-OSRM/osrm-backend/pull/4872)
# 5.15.2
- Changes from 5.15.1:
- Features:
- ADDED: Exposed the waypoints parameter in the node bindings interface
- Bugfixes:
- FIXED: Segfault causing bug in leg collapsing map matching when traversing edges in reverse
# 5.15.1
- Changes from 5.15.0:
- Bugfixes:
- FIXED: Segfault in map matching when RouteLeg collapsing code is run on a match with multiple submatches
- Guidance:
- Set type of trivial intersections where classes change to Suppressed instead of NoTurn
# 5.15.0
- Changes from 5.14.3:
- Bugfixes:
- FIXED #4704: Fixed regression in bearings reordering introduced in 5.13 [#4704](https://github.com/Project-OSRM/osrm-backend/issues/4704)
- FIXED #4781: Fixed overflow exceptions in percent-encoding parsing
- FIXED #4770: Fixed exclude flags for single toll road scenario
- FIXED #4283: Fix overflow on zero duration segments
- ADDED: `tunnel` as a new class in car profile so that sections of the route with tunnel tags will be marked as such
# 5.14.3
- Changes from 5.14.2:
- Features:
- Added a `waypoints` parameter to the match service plugin that accepts indices to input coordinates and treats only those points as waypoints in the response format.
- Bugfixes:
- FIXED #4754: U-Turn penalties are applied to straight turns.
- FIXED #4756: Removed too restrictive road name check in the sliproad handler
- FIXED #4731: Use correct weights for edge-based graph duplicated via nodes.
- Profile:
- CHANGED: added Belarus speed limits
- CHANGED: set default urban speed in Ukraine to 50kmh
# 5.14.2
- Changes from 5.14.1:
- Bugfixes:
- FIXED #4727: Erroring when a old .core file is present.
- FIXED #4642: Update checks for EMPTY_NAMEID to check for empty name strings
- FIXED #4738: Fix potential segmentation fault
- Node.js Bindings:
- ADDED: Exposed new `max_radiuses_map_matching` option from `EngingConfig` options
- Tools:
- ADDED: New osrm-routed `max_radiuses_map_matching` command line flag to optionally set a maximum radius for map matching
# 5.14.1
- Changes from 5.14.0
- Bugfixes:
- FIXED: don't use removed alternative candidates in `filterPackedPathsByCellSharing`
# 5.14.0
- Changes from 5.13
- API:
- ADDED: new RouteStep property `driving_side` that has either "left" or "right" for that step
- Misc:
- ADDED: Bundles a rough (please improve!) driving-side GeoJSON file for use with `osrm-extract --location-dependent-data data/driving_side.geojson`
- CHANGED: Conditional turn parsing is disabled by default now
- ADDED: Adds a tool to analyze turn instruction generation in a dataset. Useful for tracking turn-by-turn heuristic changes over time.
- CHANGED: Internal refactoring of guidance code as a first step towards a re-runnable guidance pipeline
- ADDED: Now publishing Node 8.x LTS binary modules
- Profile:
- CHANGED: Remove dependency on turn types and turn modifier in the process_turn function in the `car.lua` profile. Guidance instruction types are not used to influence turn penalty anymore so this will break backward compatibility between profile version 3 and 4.
- Guidance:
- ADDED: New internal flag on "segregated intersections" - in the future, will should allow collapsing of instructions across complex intersection geometry where humans only perceive a single maneuver
- CHANGED: Decrease roundabout turn radius threshold from 25m to 15m - adds some "exit the roundabout" instructions for moderately sized roundabouts that were being missed previously
- Docker:
- CHANGED: switch to alpine 3.6, and use a multistage build to reduce image size
- Build:
- FIX: use LUA_LIBRARY_DIRS to propertly detect Lua on all platforms
- Docs:
- FIX: clarify description of roundabout exit instructions
- Bugfixes:
- FIXED: Fix bug where merge instructions got the wrong direction modifier ([PR #4670](https://github.com/Project-OSRM/osrm-backend/pull/4670))
- FIXED: Properly use the `profile.properties.left_hand_driving` property, there was a typo that meant it had no effect
- FIXED: undefined behaviour when alternative candidate via node is same as source node ([#4691](https://github.com/Project-OSRM/osrm-backend/issues/4691))
- FIXED: ensure libosrm.pc is pushed to the correct location for pkgconfig to find it on all platforms
- FIXED: don't consider empty names + empty refs as a valid name for u-turns
# 5.13.0
- Changes from 5.12:
- Profile:
- Append cardinal directions from route relations to ref fields to improve instructions; off by default see `profile.cardinal_directions`
- Support of `distance` weight in foot and bicycle profiles
- Support of relations processing
- Added `way:get_location_tag(key)` method to get location-dependent tags https://github.com/Project-OSRM/osrm-backend/wiki/Using-location-dependent-data-in-profiles
- Added `forward_ref` and `backward_ref` support
- Left-side driving mode is specified by a local Boolean flag `is_left_hand_driving` in `ExtractionWay` and `ExtractionTurn`
- Support literal values for maxspeeds in NO, PL and ZA
- Infrastructure:
- Lua 5.1 support is removed due to lack of support in sol2 https://github.com/ThePhD/sol2/issues/302
- Fixed pkg-config version of OSRM
- Removed `.osrm.core` file since CoreCH is deprecated now.
- Tools:
- Because of boost/program_options#32 with boost 1.65+ we needed to change the behavior of the following flags to not accept `={true|false}` anymore:
- The deprecated options `--use-level-cache` and `--generate-edge-lookup`
- Bugfixes:
- Fixed #4348: Some cases of sliproads pre-processing were broken
- Fixed #4331: Correctly compute left/right modifiers of forks in case the fork is curved.
- Fixed #4472: Correctly count the number of lanes using the delimter in `turn:lanes` tag.
- Fixed #4214: Multiple runs of `osrm-partition` lead to crash.
- Fixed #4348: Fix assorted problems around slip roads.
- Fixed #4420: A bug that would result in unnecessary instructions, due to problems in suffix/prefix detection
- Algorithm
- Deprecate CoreCH functionality. Usage of CoreCH specific options will fall back to using CH with core_factor of 1.0
- MLD uses a unidirectional Dijkstra for 1-to-N and N-to-1 matrices which yields speedup.
# 5.12.0
- Changes from 5.11:
- Guidance
- now announcing turning onto oneways at the end of a road (e.g. onto dual carriageways)
- Adds new instruction types at the exit of roundabouts and rotaries `exit roundabout` and `exit rotary`.
- HTTP:
- New query parameter for route/table/match/trip plugings:
`exclude=` that can be used to exclude certain classes (e.g. exclude=motorway, exclude=toll).
This is configurable in the profile.
- NodeJS:
- New query option `exclude` for the route/table/match/trip plugins. (e.g. `exclude: ["motorway", "toll"]`)
- Profile:
- New property for profile table: `excludable` that can be used to configure which classes are excludable at query time.
- New optional property for profile table: `classes` that allows you to specify which classes you expect to be used.
We recommend this for better error messages around classes, otherwise the possible class names are infered automatically.
- Traffic:
- If traffic data files contain an empty 4th column, they will update edge durations but not modify the edge weight. This is useful for
updating ETAs returned, without changing route selection (for example, in a distance-based profile with traffic data loaded).
- Infrastructure:
- New file `.osrm.cell_metrics` created by `osrm-customize`.
- Debug tiles:
- Added new properties `type` and `modifier` to `turns` layer, useful for viewing guidance calculated turn types on the map
# 5.11.0
- Changes from 5.10:
- Features
- BREAKING: Added support for conditional via-way restrictions. This features changes the file format of osrm.restrictions and requires re-extraction
- Internals
- BREAKING: Traffic signals will no longer be represented as turns internally. This requires re-processing of data but enables via-way turn restrictions across highway=traffic_signals
- Additional checks for empty segments when loading traffic data files
- Tunes the constants for turns in sharp curves just a tiny bit to circumvent a mix-up in fork directions at a specific intersection (https://github.com/Project-OSRM/osrm-backend/issues/4331)
- Infrastructure
- Refactor datafacade to make implementing additional DataFacades simpler
- Bugfixes
- API docs are now buildable again
- Suppress unnecessary extra turn instruction when exiting a motorway via a motorway_link onto a primary road (https://github.com/Project-OSRM/osrm-backend/issues/4348 scenario 4)
- Suppress unnecessary extra turn instruction when taking a tertiary_link road from a teritary onto a residential road (https://github.com/Project-OSRM/osrm-backend/issues/4348 scenario 2)
- Various MSVC++ build environment fixes
- Avoid a bug that crashes GCC6
- Re-include .npmignore to slim down published modules
- Fix a pre-processing bug where incorrect directions could be issued when two turns would have similar instructions and we tried to give them distinct values (https://github.com/Project-OSRM/osrm-backend/pull/4375)
- The entry bearing for correct the cardinality of a direction value (https://github.com/Project-OSRM/osrm-backend/pull/4353
- Change timezones in West Africa to the WAT zone so they're recognized on the Windows platform
# 5.10.0
- Changes from 5.9:
- Profiles:
- New version 2 profile API which cleans up a number of things and makes it easier to for profiles to include each other. Profiles using the old version 0 and 1 APIs are still supported.
- New required `setup()` function that must return a configuration hash. Storing configuration in globals is deprecated.
- Passes the config hash returned in `setup()` as an argument to `process_node/way/segment/turn`.
- Properties are now set in `.properties` in the config hash returend by setup().
- initialize raster sources in `setup()` instead of in a separate callback.
- Renames the `sources` helper to `raster`.
- Renames `way_functions` to `process_way` (same for node, segment and turn).
- Removes `get_restrictions()`. Instead set `.restrictions` in the config hash in `setup()`.
- Removes `get_name_suffix_list()`. Instead set `.suffix_list` in the config hash in `setup()`.
- Renames `Handlers` to `WayHandlers`.
- Pass functions instead of strings to `WayHandlers.run()`, so it's possible to mix in your own functions.
- Reorders arguments to `WayHandlers` functions to match `process_way()`.
- Profiles must return a hash of profile functions. This makes it easier for profiles to include each other.
- Guidance: add support for throughabouts
- Bugfixes
- Properly save/retrieve datasource annotations for road segments ([#4346](https://github.com/Project-OSRM/osrm-backend/issues/4346)
- Fix conditional restriction grammer parsing so it works for single-day-of-week restrictions ([#4357](https://github.com/Project-OSRM/osrm-backend/pull/4357))
- Algorithm
- BREAKING: the file format requires re-processing due to the changes on via-ways
- Added support for via-way restrictions
# 5.9.2
- API:
-`annotations=durations,weights,speeds` values no longer include turn penalty values ([#4330](https://github.com/Project-OSRM/osrm-backend/issues/4330))
# 5.9.1
- Infrastructure
- STXXL is not required by default
# 5.9.0
- Changes from 5.8:
- Algorithm:
- Multi-Level Dijkstra:
- Plugins supported: `table`
- Adds alternative routes support (see [#4047](https://github.com/Project-OSRM/osrm-backend/pull/4047) and [3905](https://github.com/Project-OSRM/osrm-backend/issues/3905)): provides reasonably looking alternative routes (many, if possible) with reasonable query times.
- API:
- Exposes `alternatives=Number` parameter overload in addition to the boolean flag.
- Support for exits numbers and names. New member `exits` in `RouteStep`, based on `junction:ref` on ways
-`Intersection` now has new parameter `classes` that can be set in the profile on each way.
- Profiles:
-`result.exits` allows you to set a way's exit numbers and names, see [`junction:ref`](http://wiki.openstreetmap.org/wiki/Proposed_features/junction_details)
-`ExtractionWay` now as new property `forward_classes` and `backward_classes` that can set in the `way_function`.
The maximum number of classes is 8.
- We now respect the `construction` tag. If the `construction` tag value is not on our whitelist (`minor`, `widening`, `no`) we will exclude the road.
- Node.js Bindings:
- Exposes `alternatives=Number` parameter overload in addition to the boolean flag
- Expose `EngineConfig` options in the node bindings
- Tools:
- Exposes engine limit on number of alternatives to generate `--max-alternatives` in `osrm-routed` (3 by default)
- Infrastructure
- STXXL is not required to build OSRM and is an optional dependency for back-compatibility (ENABLE_STXXL=On)
- OpenMP is only required when the optional STXXL dependency is used
- Bug fixes:
-#4278: Remove superflous continious instruction on a motorway.
# 5.8.0
- Changes from 5.7
- API:
- polyline6 support in request string
- new parameter `approaches` for `route`, `table`, `trip` and `nearest` requests. This parameter keep waypoints on the curb side.
'approaches' accepts both 'curb' and 'unrestricted' values.
Note : the curb side depend on the `ProfileProperties::left_hand_driving`, it's a global property set once by the profile. If you are working with a planet dataset, the api will be wrong in some countries, and right in others.
- NodeJs Bindings
- new parameter `approaches` for `route`, `table`, `trip` and `nearest` requests.
- Tools
-`osrm-partition` now ensures it is called before `osrm-contract` and removes inconsitent .hsgr files automatically.
- Features
- Added conditional restriction support with `parse-conditional-restrictions=true|false` to osrm-extract. This option saves conditional turn restrictions to the .restrictions file for parsing by contract later. Added `parse-conditionals-from-now=utc time stamp` and `--time-zone-file=/path/to/file` to osrm-contract
- Command-line tools (osrm-extract, osrm-contract, osrm-routed, etc) now return error codes and legible error messages for common problem scenarios, rather than ugly C++ crashes
- Speed up pre-processing by only running the Lua `node_function` for nodes that have tags. Cuts OSM file parsing time in half.
- osrm-extract now performs generation of edge-expanded-edges using all available CPUs, which should make osrm-extract significantly faster on multi-CPU machines
- Files
- .osrm.nodes file was renamed to .nbg_nodes and .ebg_nodes was added
- Guidance
-#4075 Changed counting of exits on service roundabouts
- Debug Tiles
- added support for visualising turn penalties to the MLD plugin
- added support for showing the rate (reciprocal of weight) on each edge when used
- added support for turn weights in addition to turn durations in debug tiles
- Bugfixes
- Fixed a copy/paste issue assigning wrong directions in similar turns (left over right)
-#4074: fixed a bug that would announce entering highway ramps as u-turns
-#4122: osrm-routed/libosrm should throw exception when a dataset incompatible with the requested algorithm is loaded
- Avoid collapsing u-turns into combined turn instructions
- Merged https://github.com/Project-OSRM/node-osrm into repository. Build via `cmake .. -DCMAKE_BUILD_TYPE=Release -DENABLE_NODE_BINDINGS=On -DENABLE_MASON=On`.
-`OSRM` object has new option `algorihtm="CH","CoreCH","MLD"`
- Internals
- Shared memory notification via conditional variables on Linux or semaphore queue on OS X and Windows with a limit of 128 OSRM Engine instances
- Files
- .osrm.datasource_index file was removed. Data is now part of .osrm.geometries.
- .osrm.edge_lookup was removed. The option `--generate-edge-lookup` does nothing now.
-`osrm-contract` does not depend on the `.osrm.fileIndex` file anymore
-`osrm-extract` creates new file `.osrm.cnbg` and `.cnbg_to_ebg`
-`osrm-partition` creates new file `.osrm.partition` and `.osrm.cells`
-`osrm-customize` creates new file `.osrm.mldgr`
- Profiles
- Added `force_split_edges` flag to global properties. True value guarantees that segment_function will be called for all segments, but also could double memory consumption
- Map Matching:
- new option `gaps=split|ignore` to enable/disbale track splitting
- new option `tidy=true|false` to simplify traces automatically
# 5.6.3
- Changes from 5.6.0
- Bugfixes
-#3790 Fix incorrect speed values in tile plugin
# 5.6.2
- Changes from 5.6.0
- Bugfixes
- Fix incorrect forward datasources getter in facade
# 5.6.1
- Changes from 5.6.0
- Bugfixes
- Fix #3754 add restricted penalty on NoTurn turns
# 5.6.0
- Changes from 5.5
- Bugfixes
- Fix #3475 removed an invalid `exit` field from the `arrive` maneuver
- Fix #3515 adjusted number of `nodes` in `annotation`
- Fix #3605 Fixed a bug that could lead to turns at the end of the road to be suppressed
- Fix #2844 handle up to 16777215 code units in OSM names
- Infrastructure
- Support building rpm packages.
- Guidance
- No longer emitting turns on ferries, if a ferry should use multiple docking locations
- Profiles
- Removed the `./profile.lua -> ./profiles/car.lua` symlink. Use specific profiles from the `profiles` directory.
-`properties` object has a new `weight_name` field, default value is "duration"
-`properties` object has a new `weight_precision` field that specifies a decimal precision of edge weights, default value 1
- In `way_function` the filed `forward_rate` and `backward_rate` of `ExtractionWay` can now be set.
They have the same interpretation for the way weight as `forward_speed` and `backward_speed` for the edge duration.
The unit of rate is meters per weight unit, so higher values will be prefered during routing.
-`turn_function` now does not return an integer but takes in a `ExtractionTurn` object and can modify the `weight` and `duration` fields
-`segment_function` now takes in a `ExtractionSegment` object and can modify `weight` and `duration` fields
-`properties.uturn_penalty` is deprecated. Set it in the `turn_function`. The turn type is exposed as `ExtractionTurn::direction_modifier`.
-`properties.traffic_light_penalty` is deprecated. Traffic light penalties now need to be set over in the turn function.
Each turn with a traffic light is marked with `ExtractionTurn::has_traffic_light = true`.
- Renamed the helper file `profiles/lib/directional.lua` to `profiles/lib/tags.lua` since it now provides more general tags parsing utility functions.
- The car and foot profiles now depend on the helper file `profiles/lib/handlers.lua`.
- Infrastructure
- Disabled link-time optimized (LTO) builds by default. Enable by passing `-DENABLE_LTO=ON` to `cmake` if you need the performance and know what you are doing.
- Datafile versioning is now based on OSRM semver values, rather than source code checksums.
Datafiles are compatible between patch levels, but incompatible between minor version or higher bumps.
- libOSRM now creates an own watcher thread then used in shared memory mode to listen for data updates
- Tools:
- Added osrm-extract-conditionals tool for checking conditional values in OSM data
- Trip Plugin
- Added a new feature that finds the optimal route given a list of waypoints, a source and a destination. This does not return a roundtrip and instead returns a one way optimal route from the fixed source to the destination points.
# 5.5.1
- Changes from 5.5.0
- API:
- Adds `generate_hints=true` (`true` by default) which lets user disable `Hint` generating in the response. Use if you don't need `Hint`s!
- Bugfixes
- Fix #3418 and ensure we only return bearings in the range 0-359 in API responses
- Fixed a bug that could lead to emitting false instructions for staying on a roundabout
# 5.5.0
- Changes from 5.4.0
- API:
-`osrm-datastore` now accepts the parameter `--max-wait` that specifies how long it waits before aquiring a shared memory lock by force
- Shared memory now allows for multiple clients (multiple instances of libosrm on the same segment)
- Polyline geometries can now be requested with precision 5 as well as with precision 6
- Profiles
- the car profile has been refactored into smaller functions
- get_value_by_key() is now guaranteed never to return empty strings, nil is returned instead.
- debug.lua was added to make it easier to test/develop profile code.
-`car.lua` now depends on lib/set.lua and lib/sequence.lua
-`restrictions` is now used for namespaced restrictions and restriction exceptions (e.g. `restriction:motorcar=` as well as `except=motorcar`)
- replaced lhs/rhs profiles by using test defined profiles
- Handle `oneway=alternating` (routed over with penalty) separately from `oneway=reversible` (not routed over due to time dependence)
- Properly handle destinations on `oneway=-1` roads
- Guidance
- Notifications are now exposed more prominently, announcing turns onto a ferry/pushing your bike more prominently
- Improved turn angle calculation, detecting offsets due to lanes / minor variations due to inaccuracies
- Corrected the bearings returned for intermediate steps - requires reprocessing
- Improved turn locations for collapsed turns
- Sliproad classification refinements: the situations we detect as Sliproads now resemble more closely the reality
- Trip Plugin
- changed internal behaviour to prefer the smallest lexicographic result over the largest one
- Bugfixes
- fixed a bug where polyline decoding on a defective polyline could end up in out-of-bound access on a vector
- fixed compile errors in tile unit-test framework
- fixed a bug that could result in inconsistent behaviour when collapsing instructions
- fixed a bug that could result in crashes when leaving a ferry directly onto a motorway ramp
- fixed a bug in the tile plugin that resulted in discovering invalid edges for connections
- improved error messages when missing files during traffic updates (#3114)
- For single coordinate geometries the GeoJSON `Point` encoding was broken. We now always emit `LineString`s even in the one-coordinate-case (backwards compatible) (#3425)
- Debug Tiles
- Added support for turn penalties
- Internals
- Internal/Shared memory datafacades now share common memory layout and data loading code
- File reading now has much better error handling
- Misc
- Progress indicators now print newlines when stdout is not a TTY
- Prettier API documentation now generated via `npm run build-api-docs` output `build/docs`
# 5.4.3
- Changes from 5.4.2
- Bugfixes
-#3254 Fixed a bug that could end up hiding roundabout instructions
-#3260 fixed a bug that provided the wrong location in the arrival instruction
# 5.4.2
- Changes from 5.4.1
- Bugfixes
-#3032 Fixed a bug that could result in emitting `invalid` as an instruction type on sliproads with mode changes
-#3085 Fixed an outdated assertion that could throw without a cause for concern
-#3179 Fixed a bug that could trigger an assertion in TurnInstruciton generation
# 5.4.1
- Changes from 5.4.0
- Bugfixes
-#3016: Fixes shared memory updates while queries are running
# 5.4.0
- Changes from 5.3.0
- Profiles
- includes library guidance.lua that offers preliminary configuration on guidance.
- added left_hand_driving flag in global profile properties
- modified turn penalty function for car profile - better fit to real data
- return `ref` and `name` as separate fields. Do no use ref or destination as fallback for name value
- the default profile for car now ignores HOV only roads
- Guidance
- Handle Access tags for lanes, only considering valid lanes in lane-guidance (think car | car | bike | car)
- Improved the detection of non-noticeable name-changes
- Summaries have been improved to consider references as well
- API:
-`annotations=true` now returns the data source id for each segment as `datasources`
- Reduced semantic of merge to refer only to merges from a lane onto a motorway-like road
- new `ref` field in the `RouteStep` object. It contains the reference code or name of a way. Previously merged into the `name` property like `name (ref)` and are now separate fields.
- Bugfixes
- Fixed an issue that would result in segfaults for viaroutes with an invalid intermediate segment when u-turns were allowed at the via-location
- Invalid only_* restrictions could result in loss of connectivity. As a fallback, we assume all turns allowed when the restriction is not valid
- Fixed a bug that could result in an infinite loop when finding information about an upcoming intersection
- Fixed a bug that led to not discovering if a road simply looses a considered prefix
- BREAKING: Fixed a bug that could crash postprocessing of instructions on invalid roundabout taggings. This change requires reprocessing datasets with osrm-extract and osrm-contract
- Fixed an issue that could emit `invalid` as instruction when ending on a sliproad after a traffic-light
- Fixed an issue that would detect turning circles as sliproads
- Fixed a bug where post-processing instructions (e.g. left + left -> uturn) could result in false pronunciations
- Fixes a bug where a bearing range of zero would cause exhaustive graph traversals
- Fixes a bug where certain looped geometries could cause an infinite loop during extraction
- Fixed a bug where some roads could be falsly identified as sliproads
- Fixed a bug where roundabout intersections could result in breaking assertions when immediately exited
- Infrastructure:
- Adds a feature to limit results in nearest service with a default of 100 in `osrm-routed`
# 5.3.0
- Changes from 5.3.0-rc.3
- Guidance
- Only announce `use lane` on required turns (not using all lanes to go straight)
- Moved `lanes` to the intersection objects. This is BREAKING in relation to other Release Candidates but not with respect to other releases.
- Bugfixes
- Fix BREAKING: bug that could result in failure to load 'osrm.icd' files. This breaks the dataformat
- Fix: bug that results in segfaults when `use lane` instructions are suppressed
- Changes form 5.2.7
- API
- Introduces new `TurnType` in the form of `use lane`. The type indicates that you have to stick to a lane without turning
- Introduces `lanes` to the `Intersection` object. The lane data contains both the markings at the intersection and a flag indicating if they can be chosen for the next turn
- Removed unused `-s` from `osrm-datastore`
- Guidance
- Only announce `use lane` on required turns (not using all lanes to go straight)
- Improved detection of obvious turns
- Improved turn lane detection
- Reduce the number of end-of-road instructions in obvious cases
- Profile:
- bicycle.lua: Surface speeds never increase the actual speed
- Infrastructure
- Add 32bit support
- Add ARM NEON/VFP support
- Fix Windows builds
- Optimize speed file updates using mmap
- Add option to disable LTO for older compilers
- BREAKING: The new turn type changes the turn-type order. This breaks the **data format**.
- BREAKING: Turn lane data introduces two new files (osrm.tld,osrm.tls). This breaks the fileformat for older versions.
- Bugfixes:
- Fix devide by zero on updating speed data using osrm-contract
# 5.3.0 RC3
- Changes from 5.3.0-rc.2
- Guidance
- Improved detection of obvious turns
- Improved turn lane detection
- Bugfixes
- Fix bug that didn't chose minimal weights on overlapping edges
# 5.3.0 RC2
- Changes from 5.3.0-rc.1
- Bugfixes
- Fixes invalid checks in the lane-extraction part of the car profile
# 5.3.0 RC1
- API
- Introduces new `TurnType` in the form of `use lane`. The type indicates that you have to stick to a lane without turning
- Introduces lanes to the route response. The lane data contains both the markings at the intersection and a flag indicating their involvement in the turn
- Infrastructure
- BREAKING: The new turn type changes the turn-type order. This breaks the **data format**.
- BREAKING: Turn lane data introduces two new files (osrm.tld,osrm.tls). This breaks the fileformat for older versions.
# 5.2.5
- Bugfixes
- Fixes a segfault caused by incorrect trimming logic for very short steps.
# 5.2.4
- Bugfixes:
- Fixed in issue that arised on roundabouts in combination with intermediate intersections and sliproads
# 5.2.3
- Bugfixes:
- Fixed an issue with name changes in roundabouts that could result in crashes
# 5.2.2
Changes from 5.2.1
- Bugfixes:
- Buffer overrun in tile plugin response handling
# 5.2.1
Changes from 5.2.0
- Bugfixes:
- Removed debug statement that was spamming the console
# 5.2.0
Changes from 5.2.0 RC2
- Bugfixes:
- Fixed crash when loading shared memory caused by invalid OSM IDs segment size.
- Various small instructions handling fixes
Changes from 5.1.0
- API:
- new parameter `annotations` for `route`, `trip` and `match` requests. Returns additional data about each
coordinate along the selected/matched route line per `RouteLeg`:
- duration of each segment
- distance of each segment
- OSM node ids of all segment endpoints
- Introducing Intersections for Route Steps. This changes the API format in multiple ways.
-`bearing_before`/`bearing_after` of `StepManeuver` are now deprecated and will be removed in the next major release
-`location` of `StepManeuvers` is now deprecated and will be removed in the next major release
- every `RouteStep` now has property `intersections` containing a list of `Intersection` objects.
- Support for destination signs. New member `destinations` in `RouteStep`, based on `destination` and `destination:ref`
- Support for name pronunciations. New member `pronunciation` in `RouteStep`, based on `name:pronunciation`
- Profile changes:
- duration parser now accepts P[n]DT[n]H[n]M[n]S, P[n]W, PTHHMMSS and PTHH:MM:SS ISO8601 formats.
-`result.destinations` allows you to set a way's destinations
-`result.pronunciation` allows you to set way name pronunciations
-`highway=motorway_link` no longer implies `oneway` as per the OSM Wiki
- Infrastructure:
- BREAKING: Changed the on-disk encoding of the StaticRTree to reduce ramIndex file size. This breaks the **data format**
- BREAKING: Intersection Classification adds a new file to the mix (osrm.icd). This breaks the fileformat for older versions.
- Better support for osrm-routed binary upgrade on the fly [UNIX specific]:
- Open sockets with SO_REUSEPORT to allow multiple osrm-routed processes serving requests from the same port.
- Add SIGNAL_PARENT_WHEN_READY environment variable to enable osrm-routed signal its parent with USR1 when it's running and waiting for requests.
- Disable http access logging via DISABLE_ACCESS_LOGGING environment variable.
- Guidance:
- BREAKING: modifies the file format with new internal identifiers
- improved detection of turning streets, not reporting new-name in wrong situations
- improved handling of sliproads (emit turns instead of 'take the ramp')
- improved collapsing of instructions. Some 'new name' instructions will be suppressed if they are without alternative and the segment is short
- Bugfixes
- fixed broken summaries for very short routes
# 5.2.0 RC2
Changes from 5.2.0 RC1
- Guidance:
- improved handling of sliproads (emit turns instead of 'take the ramp')
- improved collapsing of instructions. Some 'new name' instructions will be suppressed if they are without alternative and the segment is short
- BREAKING: modifies the file format with new internal identifiers
- API:
- paramater `annotate` was renamed to `annotations`.
-`annotation` as accidentally placed in `Route` instead of `RouteLeg`
- Support for destination signs. New member `destinations` in `RouteStep`, based on `destination` and `destination:ref`
- Support for name pronunciations. New member `pronunciation` in `RouteStep`, based on `name:pronunciation`
- Add `nodes` property to `annotation` in `RouteLeg` containing the ids of nodes covered by the route
- Profile changes:
-`result.destinations` allows you to set a way's destinations
-`result.pronunciation` allows you to set way name pronunciations
-`highway=motorway_link` no longer implies `oneway` as per the OSM Wiki
- Infrastructure
- BREAKING: Changed the on-disk encoding of the StaticRTree to reduce ramIndex file size. This breaks the **data format**
- Bugfixes
- fixed broken summaries for very short routes
# 5.2.0 RC1
Changes from 5.1.0
- API:
- new parameter `annotate` for `route` and `match` requests. Returns additional data about each
coordinate along the selected/matched route line.
- Introducing Intersections for Route Steps. This changes the API format in multiple ways.
-`bearing_before`/`bearing_after` of `StepManeuver` are now deprecated and will be removed in the next major release
-`location` of `StepManeuvers` is now deprecated and will be removed in the next major release
- every `RouteStep` now has property `intersections` containing a list of `Intersection` objects.
- Profile changes:
- duration parser now accepts P[n]DT[n]H[n]M[n]S, P[n]W, PTHHMMSS and PTHH:MM:SS ISO8601 formats.
- Infrastructure:
- Better support for osrm-routed binary upgrade on the fly [UNIX specific]:
- Open sockets with SO_REUSEPORT to allow multiple osrm-routed processes serving requests from the same port.
- Add SIGNAL_PARENT_WHEN_READY environment variable to enable osrm-routed signal its parent with USR1 when it's running and waiting for requests.
- BREAKING: Intersection Classification adds a new file to the mix (osrm.icd). This breaks the fileformat for older versions.
- Disable http access logging via DISABLE_ACCESS_LOGGING environment
variable.
- Guidance:
- improved detection of turning streets, not reporting new-name in wrong situations
# 5.1.0
Changes with regard to 5.0.0
- API:
- added StepManeuver type `roundabout turn`. The type indicates a small roundabout that is treated as an intersection
(turn right at the roundabout for first exit, go straight at the roundabout...)
- added StepManeuver type `on ramp` and `off ramp` to distinguish between ramps that enter and exit a highway.
- reduced new name instructions for trivial changes
- combined multiple turns into a single instruction at segregated roads`
- Profile Changes:
- introduced a suffix_list / get_name_suffix_list to specify name suffices to be suppressed in name change announcements
- street names are now consistently assembled for the car, bike and walk profile as: "Name (Ref)" as in "Berlin (A5)"
- new `car.lua` dependency `lib/destination.lua`
- register a way's .nodes() function for use in the profile's way_function.
- Infrastructure
- BREAKING: reordered internal instruction types. This breaks the **data format**
- BREAKING: Changed the on-disk encoding of the StaticRTree for better performance. This breaks the **data format**
- Fixes:
- Issue #2310: post-processing for local paths, fixes #2310
- Issue #2309: local path looping, fixes #2309
- Issue #2356: Make hint values optional
- Issue #2349: Segmentation fault in some requests
- Issue #2335: map matching was using shortest path with uturns disabled
- Issue #2193: Fix syntax error position indicators in parameters queries
- Fix search with u-turn
- PhantomNode packing in MSVC now the same on other platforms
- Summary is now not malformed when including unnamed roads
- Emit new-name on when changing fron unanmed road to named road
# 5.0.0
Changes with regard 5.0.0 RC2:
- API:
- if `geometry=geojson` is passed the resulting geometry can be a LineString or Point
depending on how many coordinates are present.
- the removal of the summary field was revered. for `steps=flase` the field will always be an empty string.
Changes with regard to 4.9.1:
- API:
- BREAKING: Complete rewrite of the HTTP and library API. See detailed documentation in the wiki.
- BREAKING: The default coordinate order is now `longitude, latidue`. Exception: Polyline geometry
which follow the original Google specification of `latitdue, longitude`.
- BREAKING: Polyline geometries now use precision 5, instead of previously 6
- BREAKING: Removed GPX support
- New service `tile` which serves debug vector tiles of the road network
- Completely new engine for guidance generation:
- Support for highway ramps
- Support for different intersection types (end of street, forks, merges)
- Instruction post-processing to merge unimportant instructions
- Improved handling of roundabouts
- Tools:
- BREAKING: Renamed osrm-prepare to osrm-contract
- BREAKING: Removes profiles from osrm-contract, only needed in osrm-extract.
- Abort processing in osrm-extract if there are no snappable edges remaining.
- Added .properties file to osrm-extract ouput.
- Enables the use of multiple segment-speed-files on the osrm-contract command line
- Profile changes:
- Remove movable bridge mode
- Add `maxspeed=none` tag to car profile.
- A `side_road` tag support for the OSRM car profile.
- Fixes:
- Issue #2150: Prevents routing over delivery ways and nodes
- Issue #1972: Provide uninstall target
- Issue #2072: Disable alternatives by default and if core factor < 1.0
- Issue #1999: Fix unpacking for self-loop nodes not in core.
- Infrastructure:
- Cucumber test suit is now based on cucumber-js, removes Ruby as dependency
- Updated to mapbox/variant v1.1
- Updated to libosmium v2.6.1
- Remove GeoJSON based debugging output, replaced by debug tiles
# 5.0.0 RC2
- Profiles:
-`properties.allow_uturns_at_via` -> `properties.continue_straight_at_waypoint` (value is inverted!)
- API:
- Removed summary from legs property
- Disable steps and alternatives by default
- Fix `code` field: 'ok' -> 'Ok'
- Allow 4.json and 4.3.json format
- Conform to v5 spec and support "unlimited" as radiuses value.
-`uturns` parameter was replaced by `continue_straight` (value is inverted!)
- Features:
- Report progress for gennerating edge expanded edges in the edge based graph factory
Everyone is invited to participate in Project OSRM’s open source projects and public discussions: we want to create a welcoming and friendly environment. Harassment of participants or other unethical and unprofessional behavior will not be tolerated in our spaces. The [Contributor Covenant](http://contributor-covenant.org) applies to all projects under the Project-OSRM organization and we ask that you please read [the full text](http://contributor-covenant.org/version/1/2/0/).
could check code format, modify a local repository and reject push due to unstaged formatting changes.
Also `pre-push` hook rejects direct pushes to `origin/master`.
⚠️ `scripts/format.sh` checks all local files that match `*.cpp` or `*.hpp` patterns.
In general changes that affect the API and/or increase the memory consumption need to be discussed first.
Often we don't include changes that would increase the memory consumption a lot if they are not generally usable (e.g. elevation data is a good example).
## Pull Request
Every pull-request that changes the API needs to update the docs in `docs/http.md` and add an entry to `CHANGELOG.md`.
Breaking changes need to have a BREAKING prefix. See the [releasing documentation](docs/releasing.md) on how this affects the version.
Early feedback is also important.
You will see that a lot of the PR have tags like `[not ready]` or `[wip]`.
We like to open PRs as soon as we are starting to work on something to make it visible to the rest of the team.
If your work is going in entirely the wrong direction, there is a good chance someone will pick up on this before it is too late.
Everyone is encouraged to read PRs of other people and give feedback.
For every significant code change we require a pull request review before it is merged.
If your pull request modifies the API this need to be signed of by a team discussion.
This means you will need to find another member of the team with commit access and request a review of your pull request.
Once your pull request is reviewed you can merge it! If you don't have commit access, ping someone that has commit access.
If you do have commit access there are in general two accepted styles to merging:
1. Make sure the branch is up to date with `master`. Run `git rebase master` to find out.
2. Once that is ensured you can either:
- Click the nice green merge button (for a non-fast-forward merge)
- Merge by hand using a fast-forward merge
Which merge you prefer is up to personal preference. In general it is recommended to use fast-forward merges because it creates a history that is sequential and easier to understand.
# Maintainer
## Doing a release
There is an in-depth guide around how to push out a release once it is ready [here](docs/releasing.md).
## The API
Changes to the API need to be discussed and signed off by the team. Breaking changes even more so than additive changes.
## Milestones
If a pull request or an issue is applicable for the current or next milestone, depends on the target version number.
Since we use semantic versioning we restrict breaking changes to major releases.
After a Release Candidate is released we usually don't change the API anymore if it is not critical.
Bigger code changes after a RC was released should also be avoided.
To quickly try OSRM use our [demo server](http://map.project-osrm.org) which comes with both the backend and a frontend on top.
For instructions on how to [build](https://github.com/Project-OSRM/osrm-backend/wiki/Building-OSRM) and [run OSRM](https://github.com/Project-OSRM/osrm-backend/wiki/Running-OSRM), please consult [the Wiki](https://github.com/Project-OSRM/osrm-backend/wiki).
For a quick introduction about how the road network is represented in OpenStreetMap and how to map specific road network features have a look at [this guide about mapping for navigation](https://www.mapbox.com/mapping/mapping-for-navigation/).
To quickly try OSRM use our [free and daily updated online service](http://map.project-osrm.org)
Related [Project-OSRM](https://github.com/Project-OSRM) repositories:
- [osrm-frontend](https://github.com/Project-OSRM/osrm-frontend) - User-facing frontend with map. The demo server runs this on top of the backend
- [osrm-text-instructions](https://github.com/Project-OSRM/osrm-text-instructions) - Text instructions from OSRM route response
- [osrm-backend-docker](https://hub.docker.com/r/osrm/osrm-backend/) - Ready to use Docker images
## Documentation
See the Wiki's [server API documentation](https://github.com/Project-OSRM/osrm-backend/wiki/Server-api) as well as the [library API documentation](https://github.com/Project-OSRM/osrm-backend/wiki/Library-api)
### Full documentation
- [Hosted documentation](http://project-osrm.org)
- [osrm-routed HTTP API documentation](docs/http.md)
The easiest and quickest way to setup your own routing engine is to use Docker images we provide.
There are two pre-processing pipelines available:
- Contraction Hierarchies (CH)
- Multi-Level Dijkstra (MLD)
we recommend using MLD by default except for special use-cases such as very large distance matrices where CH is still a better fit for the time being.
In the following we explain the MLD pipeline.
If you want to use the CH pipeline instead replace `osrm-partition` and `osrm-customize` with a single `osrm-contract` and change the algorithm option for `osrm-routed` to `--algorithm ch`.
### Using Docker
We base our Docker images ([backend](https://hub.docker.com/r/osrm/osrm-backend/), [frontend](https://hub.docker.com/r/osrm/osrm-frontend/)) on Alpine Linux and make sure they are as lightweight as possible.
Download OpenStreetMap extracts for example from [Geofabrik](http://download.geofabrik.de/)
Pre-process the extract with the car profile and start a routing engine HTTP server on port 5000
docker run -t -v $(pwd):/data osrm/osrm-backend osrm-extract -p /opt/car.lua /data/berlin-latest.osm.pbf
The flag `-v $(pwd):/data` creates the directory `/data` inside the docker container and makes the current working directory `$(pwd)` available there. The file `/data/berlin-latest.osm.pbf` inside the container is referring to `$(pwd)/berlin-latest.osm.pbf` on the host.
docker run -t -v $(pwd):/data osrm/osrm-backend osrm-partition /data/berlin-latest.osrm
docker run -t -v $(pwd):/data osrm/osrm-backend osrm-customize /data/berlin-latest.osrm
Note that `berlin-latest.osrm` has a different file extension.
SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY"Open Source Routing Machine (OSRM) is a high-performance routing engine. It combines sophisticated routing algorithms with the open and free data of the OpenStreetMap.")
message(STATUS"[Warning] FindTBB.cmake: The use of TBB_ARCHITECTURE and TBB_COMPILER is deprecated and may not be supported in future versions. Please set \$ENV{TBB_ARCH_PLATFORM} (using tbbvars.[bat|csh|sh]).")
# Jiri: It doesn't hurt to look in more places, so I store the hints from
# ENV{TBB_ARCH_PLATFORM} and the TBB_ARCHITECTURE and TBB_COMPILER
message(STATUS"[Warning] FindTBB.cmake: The use of TBB_ARCHITECTURE and TBB_COMPILER is deprecated and may not be supported in future versions. Please set \$ENV{TBB_ARCH_PLATFORM} (using tbbvars.[bat|csh|sh]).")
# Jiri: It doesn't hurt to look in more places, so I store the hints from
# ENV{TBB_ARCH_PLATFORM} and the TBB_ARCHITECTURE and TBB_COMPILER
message(FATAL_ERROR"[Mason] Package at ${_INSTALL_PATH_RELATIVE} has platform '${MASON_PACKAGE_${_PACKAGE}_PLATFORM}', but required '${MASON_PLATFORM}'")
message(FATAL_ERROR"[Mason] Package at ${_INSTALL_PATH_RELATIVE} has platform version '${MASON_PACKAGE_${_PACKAGE}_PLATFORM_VERSION}', but required '${MASON_PLATFORM_VERSION}'")
When changing guidance code, it is easy to introduce problems somewhere in the network.
To get a better feeling of how your changes impact the OSRM experience, we offer ways of generating geojson output to inspect (e.g. with Mapbox Studio).
When you do changes, make sure to inspect a few areas for the impact of the changes.
## How to use GeoJson-Debugging
This is a short guide to describe usage of our GeoJson debug logging mechanism. It is synchronized to guarantee thread-safe logging.
## Outputting into a single file
To use it, the inclusion of `geojson_debug_logger.hpp``geojson_debug_policies.hpp` from the `util` directory is required.
Geojson debugging requires a few simple steps to output data into a feature collection.
- Create a Scoped Guard that lives through the process and provide it with all required datastructures (it needs to span the lifetime of all your logging efforts)
- At the location of the output, simply call Write with your own parameters.
A guard (ScopedGeojsonLoggerGuard) requires a logging policy. Per default we provide a way of printing out node-ids as coordinates.
Make sure to give the guard a name, so it actually gets a lifetime.
The field `data-for-conversion` can be an arbitrary long set of features and needs to match the parameters used for constructing our policy (in this case `util::NodeIdVectorToLineString`).
The policy itself offers a `operator()` accepting a `vector` of `NodeID`.
For outputting data into our file (debug.geojson), we simply need to call the matching logging routine of the guard: `util::ScioedGeojsonLoggerGuard<util::NodeIdVectorToLineString>::Write(list_of_node_ids);`
(or `guard.Write(list_of_node_ids)` if you created an instance).
### Possible Scopeguard Location
Think of the scopeguard as you would do of any reference. If you wan't to access to logging during a call, the guard object must be alive and valid.
As an example: a good location to create the a scopeguard to log decisions in the edge-based-graph-factory would be right before we run it ([here](https://github.com/Project-OSRM/osrm-backend/blob/a933b5d94943bf3edaf42c84a614a99650d23cba/src/extractor/extractor.cpp#L497)). If you put `util::ScopedGeojsonLoggerGuard<util::NodeIdVectorToLineString> geojson_guard( "debug.geojson", node_coordinate_vector);` at that location, you can then print `util::ScopedGeojsonLoggerGuard<util::NodeIdVectorToLineString>::Write(list_of_node_ids);` anywhere within the `edge-based-graph-factory`.
This location would enable call for all guidance related pre-processing which is called in the edge-based-graph-factory.
Logging any turn-handler decisions, for example, would now be possible.
## Limitations
GeoJson debugging requires a single GeoJsonGuard (ScopedGeojsonLoggerGuard) for each desired output file.
For each set of template parameters, only the most recent guard will actually produce output.
The following syntax applies to all services, except as noted.
### Requests
```endpoint
GET /{service}/{version}/{profile}/{coordinates}[.{format}]?option=value&option=value
```
| Parameter | Description |
| --- | --- |
| `service` | One of the following values: [`route`](#route-service), [`nearest`](#nearest-service), [`table`](#table-service), [`match`](#match-service), [`trip`](#trip-service), [`tile`](#tile-service) |
| `version` | Version of the protocol implemented by the service. `v1` for all OSRM 5.x installations |
| `profile` | Mode of transportation, is determined statically by the Lua profile that is used to prepare the data using `osrm-extract`. Typically `car`, `bike` or `foot` if using one of the supplied profiles. |
| `coordinates`| String of format `{longitude},{latitude};{longitude},{latitude}[;{longitude},{latitude} ...]` or `polyline({polyline}) or polyline6({polyline6})`. |
| `format`| Only `json` is supported at the moment. This parameter is optional and defaults to `json`. |
Passing any `option=value` is optional. `polyline` follows Google's polyline format with precision 5 by default and can be generated using [this package](https://www.npmjs.com/package/polyline).
To pass parameters to each location some options support an array like encoding:
|bearings |`{bearing};{bearing}[;{bearing} ...]` |Limits the search to segments with given bearing in degrees towards true north in clockwise direction. |
|radiuses |`{radius};{radius}[;{radius} ...]` |Limits the search to given radius in meters. |
|generate\_hints |`true` (default), `false` |Adds a Hint to the response which can be used in subsequent requests, see `hints` parameter. |
|hints |`{hint};{hint}[;{hint} ...]` |Hint from previous request to derive position in street network. |
|approaches |`{approach};{approach}[;{approach} ...]` |Keep waypoints on curb side. |
|exclude |`{class}[,{class}]` |Additive list of classes to avoid, order does not matter. |
|class |A class name determined by the profile or `none`. |
```
{option}={element};{element}[;{element} ... ]
```
The number of elements must match exactly the number of locations (except for `generate_hints` and `exclude`). If you don't want to pass a value but instead use the default you can pass an empty `element`.
Example: 2nd location use the default value for `option`:
Finds the fastest route between coordinates in the supplied order.
```endpoint
GET /route/v1/{profile}/{coordinates}?alternatives={true|false|number}&steps={true|false}&geometries={polyline|polyline6|geojson}&overview={full|simplified|false}&annotations={true|false}
```
In addition to the [general options](#general-options) the following options are supported for this service:
|alternatives|`true`, `false` (default), or Number |Search for alternative routes. Passing a number `alternatives=n` searches for up to `n` alternative routes.\* |
|steps |`true`, `false` (default) |Returned route steps for each route leg |
|annotations |`true`, `false` (default), `nodes`, `distance`, `duration`, `datasources`, `weight`, `speed` |Returns additional metadata for each coordinate along the route geometry. |
|geometries |`polyline` (default), `polyline6`, `geojson` |Returned route geometry format (influences overview and per step) |
|overview |`simplified` (default), `full`, `false` |Add overview geometry either full, simplified according to highest zoom level it could be display on, or not at all.|
|continue\_straight |`default` (default), `true`, `false` |Forces the route to keep going straight at waypoints constraining uturns there even if it would be faster. Default value depends on the profile. |
\* Please note that even if alternative routes are requested, a result cannot be guaranteed.
**Response**
-`code` if the request was successful `Ok` otherwise see the service dependent and general status codes.
-`waypoints`: Array of `Waypoint` objects representing all waypoints in order:
-`routes`: An array of `Route` objects, ordered by descending recommendation rank.
In case of error the following `code`s are supported in addition to the general ones:
| Type | Description |
|-------------------|-----------------|
| `NoRoute` | No route found. |
All other properties might be undefined.
#### Example Request
```curl
# Query on Berlin with three coordinates and no overview geometry returned:
-`code` if the request was successful `Ok` otherwise see the service dependent and general status codes.
-`durations` array of arrays that stores the matrix in row-major order. `durations[i][j]` gives the travel time from
the i-th waypoint to the j-th waypoint. Values are given in seconds. Can be `null` if no route between `i` and `j` can be found.
-`sources` array of `Waypoint` objects describing all sources in order
-`destinations` array of `Waypoint` objects describing all destinations in order
In case of error the following `code`s are supported in addition to the general ones:
| Type | Description |
|-------------------|-----------------|
| `NoTable` | No route found. |
All other properties might be undefined.
### Match service
Map matching matches/snaps given GPS points to the road network in the most plausible way.
Please note the request might result multiple sub-traces. Large jumps in the timestamps (> 60s) or improbable transitions lead to trace splits if a complete matching could not be found.
The algorithm might not be able to match all points. Outliers are removed if they can not be matched successfully.
```endpoint
GET /match/v1/{profile}/{coordinates}?steps={true|false}&geometries={polyline|polyline6|geojson}&overview={simplified|full|false}&annotations={true|false}
```
In addition to the [general options](#general-options) the following options are supported for this service:
|steps |`true`, `false` (default) |Returned route steps for each route |
|geometries |`polyline` (default), `polyline6`, `geojson` |Returned route geometry format (influences overview and per step) |
|annotations |`true`, `false` (default), `nodes`, `distance`, `duration`, `datasources`, `weight`, `speed` |Returns additional metadata for each coordinate along the route geometry. |
|overview |`simplified` (default), `full`, `false` |Add overview geometry either full, simplified according to highest zoom level it could be display on, or not at all.|
|timestamps |`{timestamp};{timestamp}[;{timestamp} ...]` |Timestamps for the input locations in seconds since UNIX epoch. Timestamps need to be monotonically increasing. |
|radiuses |`{radius};{radius}[;{radius} ...]` |Standard deviation of GPS precision used for map matching. If applicable use GPS accuracy.|
|gaps |`split` (default), `ignore` |Allows the input track splitting based on huge timestamp gaps between points. |
|tidy |`true`, `false` (default) |Allows the input track modification to obtain better matching quality for noisy tracks. |
|waypoints | `{index};{index};{index}...` |Treats input coordinates indicated by given indices as waypoints in returned Match object. Default is to treat all input coordinates as waypoints. |
The radius for each point should be the standard error of the location measured in meters from the true location.
Use `Location.getAccuracy()` on Android or `CLLocation.horizontalAccuracy` on iOS.
This value is used to determine which points should be considered as candidates (larger radius means more candidates) and how likely each candidate is (larger radius means far-away candidates are penalized less).
The area to search is chosen such that the correct candidate should be considered 99.9% of the time (for more details see [this ticket](https://github.com/Project-OSRM/osrm-backend/pull/3184)).
**Response**
-`code` if the request was successful `Ok` otherwise see the service dependent and general status codes.
-`tracepoints`: Array of `Waypoint` objects representing all points of the trace in order.
If the trace point was ommited by map matching because it is an outlier, the entry will be `null`.
Each `Waypoint` object has the following additional properties:
-`matchings_index`: Index to the `Route` object in `matchings` the sub-trace was matched to.
-`waypoint_index`: Index of the waypoint inside the matched route.
-`alternatives_count`: Number of probable alternative matchings for this trace point. A value of zero indicate that this point was matched unambiguously. Split the trace at these points for incremental map matching.
-`matchings`: An array of `Route` objects that assemble the trace. Each `Route` object has the following additional properties:
-`confidence`: Confidence of the matching. `float` value between 0 and 1. 1 is very confident that the matching is correct.
In case of error the following `code`s are supported in addition to the general ones:
| Type | Description |
|-------------------|---------------------|
| `NoMatch` | No matchings found. |
All other properties might be undefined.
### Trip service
The trip plugin solves the Traveling Salesman Problem using a greedy heuristic (farthest-insertion algorithm) for 10 or more waypoints and uses brute force for less than 10 waypoints.
The returned path does not have to be the fastest path. As TSP is NP-hard it only returns an approximation.
Note that all input coordinates have to be connected for the trip service to work.
```endpoint
GET /trip/v1/{profile}/{coordinates}?roundtrip={true|false}&source{any|first}&destination{any|last}&steps={true|false}&geometries={polyline|polyline6|geojson}&overview={simplified|full|false}&annotations={true|false}'
```
In addition to the [general options](#general-options) the following options are supported for this service:
|roundtrip |`true` (default), `false` |Returned route is a roundtrip (route returns to first location) |
|source |`any` (default), `first` |Returned route starts at `any` or `first` coordinate |
|destination |`any` (default), `last` |Returned route ends at `any` or `last` coordinate |
|steps |`true`, `false` (default) |Returned route instructions for each trip |
|annotations |`true`, `false` (default), `nodes`, `distance`, `duration`, `datasources`, `weight`, `speed` |Returns additional metadata for each coordinate along the route geometry. |
|geometries |`polyline` (default), `polyline6`, `geojson` |Returned route geometry format (influences overview and per step) |
|overview |`simplified` (default), `full`, `false` |Add overview geometry either full, simplified according to highest zoom level it could be display on, or not at all.|
**Fixing Start and End Points**
It is possible to explicitely set the start or end coordinate of the trip.
When source is set to `first`, the first coordinate is used as start coordinate of the trip in the output. When destination is set to `last`, the last coordinate will be used as destination of the trip in the returned output. If you specify `any`, any of the coordinates can be used as the first or last coordinate in the output.
However, if `source=any&destination=any` the returned round-trip will still start at the first input coordinate by default.
Currently, not all combinations of `roundtrip`, `source` and `destination` are supported.
Right now, the following combinations are possible:
-`code`: if the request was successful `Ok` otherwise see the service dependent and general status codes.
-`waypoints`: Array of `Waypoint` objects representing all waypoints in input order. Each `Waypoint` object has the following additional properties:
-`trips_index`: Index to `trips` of the sub-trip the point was matched to.
-`waypoint_index`: Index of the point in the trip.
-`trips`: An array of `Route` objects that assemble the trace.
In case of error the following `code`s are supported in addition to the general ones:
| Type | Description |
|-------------------|---------------------|
| `NoTrips` | No trips found because input coordinates are not connected.|
| `NotImplemented` | This request is not supported |
All other properties might be undefined.
### Tile service
This service generates [Mapbox Vector Tiles](https://www.mapbox.com/developers/vector-tiles/) that can be viewed with a vector-tile capable slippy-map viewer. The tiles contain road geometries and metadata that can be used to examine the routing graph. The tiles are generated directly from the data in-memory, so are in sync with actual routing results, and let you examine which roads are actually routable, and what weights they have applied.
```endpoint
GET /tile/v1/{profile}/tile({x},{y},{zoom}).mvt
```
The `x`, `y`, and `zoom` values are the same as described at https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames, and are supported by vector tile viewers like [Mapbox GL JS](https://www.mapbox.com/mapbox-gl-js/api/).
#### Example request
```curl
# This fetches a Z=13 tile for downtown San Francisco:
The response object is either a binary encoded blob with a `Content-Type` of `application/x-protobuf`, or a `404` error. Note that OSRM is hard-coded to only return tiles from zoom level 12 and higher (to avoid accidentally returning extremely large vector tiles).
| `speed` | `integer` | the speed on that road segment, in km/h |
| `is_small` | `boolean` | whether this segment belongs to a small (< 1000 node) [strongly connected component](https://en.wikipedia.org/wiki/Strongly_connected_component) |
| `datasource` | `string` | the source for the speed value (normally `lua profile` unless you're using the [traffic update feature](https://github.com/Project-OSRM/osrm-backend/wiki/Traffic), in which case it contains the stem of the filename that supplied the speed value for this segment |
| `duration` | `float` | how long this segment takes to traverse, in seconds. This value is to calculate the total route ETA. |
| `weight ` | `integer` | how long this segment takes to traverse, in units (may differ from `duration` when artificial biasing is applied in the Lua profiles). ACTUAL ROUTING USES THIS VALUE. |
| `name` | `string` | the name of the road this segment belongs to |
| `rate` | `float` | the value of `length/weight` - analagous to `speed`, but using the `weight` value rather than `duration`, rounded to the nearest integer |
| `bearing_in` | `integer` | the absolute bearing that approaches the intersection. -180 to +180, 0 = North, 90 = East |
| `turn_angle` | `integer` | the angle of the turn, relative to the `bearing_in`. -180 to +180, 0 = straight ahead, 90 = 90-degrees to the right |
| `cost` | `float` | the time we think it takes to make that turn, in seconds. May be negative, depending on how the data model is constructed (some turns get a "bonus"). |
| `weight` | `float` | the weight we think it takes to make that turn. May be negative, depending on how the data model is constructed (some turns get a "bonus"). ACTUAL ROUTING USES THIS VALUE |
| `type` | `string` | the type of this turn - values like `turn`, `continue`, etc. See the `StepManeuver` for a partial list, this field also exposes internal turn types that are never returned with an API response |
| `modifier` | `string` | the direction modifier of the turn (`left`, `sharp left`, etc) |
## Result objects
### Route object
Represents a route through (potentially multiple) waypoints.
**Properties**
-`distance`: The distance traveled by the route, in `float` meters.
-`duration`: The estimated travel time, in `float` number of seconds.
-`geometry`: The whole geometry of the route value depending on `overview` parameter, format depending on the `geometries` parameter. See `RouteStep`'s `geometry` property for a parameter documentation.
-`weight`: The calculated weight of the route.
-`weight_name`: The name of the weight profile used during extraction phase.
| overview | Description |
|------------|-----------------------------|
| simplified | Geometry is simplified according to the highest zoom level it can still be displayed on full. |
| full | Geometry is not simplified. |
| false | Geometry is not added. |
-`legs`: The legs between the given waypoints, an array of `RouteLeg` objects.
#### Example
Three input coordinates, `geometry=geojson`, `steps=false`:
Annotation of the whole route leg with fine-grained information about each segment or node id.
**Properties**
-`distance`: The distance, in metres, between each pair of coordinates
-`duration`: The duration between each pair of coordinates, in seconds. Does not include the duration of any turns.
-`datasources`: The index of the datasource for the speed between each pair of coordinates. `0` is the default profile, other values are supplied via `--segment-speed-file` to `osrm-contract`
-`nodes`: The OSM node ID for each coordinate along the route, excluding the first/last user-supplied coordinates
-`weight`: The weights between each pair of coordinates. Does not include any turn costs.
-`speed`: Convenience field, calculation of `distance / duration` rounded to one decimal place
-`name`: The name of the way along which travel proceeds.
-`ref`: A reference number or code for the way. Optionally included, if ref data is available for the given way.
-`pronunciation`: A string containing an [IPA](https://en.wikipedia.org/wiki/International_Phonetic_Alphabet) phonetic transcription indicating how to pronounce the name in the `name` property. This property is omitted if pronunciation data is unavailable for the step.
-`destinations`: The destinations of the way. Will be `undefined` if there are no destinations.
-`exits`: The exit numbers or names of the way. Will be `undefined` if there are no exit numbers or names.
-`mode`: A string signifying the mode of transportation.
-`maneuver`: A `StepManeuver` object representing the maneuver.
-`intersections`: A list of `Intersection` objects that are passed along the segment, the very first belonging to the StepManeuver
-`rotary_name`: The name for the rotary. Optionally included, if the step is a rotary and a rotary name is available.
-`rotary_pronunciation`: The pronunciation hint of the rotary name. Optionally included, if the step is a rotary and a rotary pronunciation is available.
-`driving_side`: The legal driving side at the location for this step. Either `left` or `right`.
#### Example
```json
{
"geometry":"{lu_IypwpAVrAvAdI",
"mode":"driving",
"duration":15.6,
"weight":15.6,
"intersections":[
{"bearings":[10,92,184,270],
"lanes":[
{"indications":["left","straight"],
"valid":"false"},
{"valid":"true",
"indications":["right"]}
],
"out":2,
"in":3,
"entry":["true","true","true","false"],
"location":[13.39677,52.54366]
},
{"out":1,
"lanes":[
{"indications":["straight"],
"valid":"true"},
{"indications":["right"],
"valid":"false"}
],
"bearings":[60,240,330],
"in":0,
"entry":["false","true","true"],
"location":[13.394718,52.543096]
}
],
"name":"Lortzingstraße",
"distance":152.3,
"maneuver":{
"modifier":"right",
"type":"turn"
}
}
```
### StepManeuver object
**Properties**
-`location`: A `[longitude, latitude]` pair describing the location of the turn.
-`bearing_before`: The clockwise angle from true north to the
direction of travel immediately before the maneuver. Range 0-359.
-`bearing_after`: The clockwise angle from true north to the
direction of travel immediately after the maneuver. Range 0-359.
-`type` A string indicating the type of maneuver. **new identifiers might be introduced without API change**
Types unknown to the client should be handled like the `turn` type, the existence of correct `modifier` values is guranteed.
| `turn` | a basic turn into direction of the `modifier` |
| `new name` | no turn is taken/possible, but the road name changes. The road can take a turn itself, following `modifier`. |
| `depart` | indicates the departure of the leg |
| `arrive` | indicates the destination of the leg |
| `merge` | merge onto a street (e.g. getting on the highway from a ramp, the `modifier specifies the direction of the merge`) |
| `ramp` | **Deprecated**. Replaced by `on_ramp` and `off_ramp`. |
| `on ramp` | take a ramp to enter a highway (direction given my `modifier`) |
| `off ramp` | take a ramp to exit a highway (direction given my `modifier`) |
| `fork` | take the left/right side at a fork depending on `modifier` |
| `end of road` | road ends in a T intersection turn in direction of `modifier`|
| `use lane` | **Deprecated** replaced by lanes on all intersection entries |
| `continue` | Turn in direction of `modifier` to stay on the same road |
| `roundabout` | traverse roundabout, if the route leaves the roundabout there will be an additional property `exit` for exit counting. The modifier specifies the direction of entering the roundabout. |
| `rotary` | a traffic circle. While very similar to a larger version of a roundabout, it does not necessarily follow roundabout rules for right of way. It can offer `rotary_name` and/or `rotary_pronunciation` parameters (located in the RouteStep object) in addition to the `exit` parameter (located on the StepManeuver object). |
| `roundabout turn`| Describes a turn at a small roundabout that should be treated as normal turn. The `modifier` indicates the turn direciton. Example instruction: `At the roundabout turn left`. |
| `notification` | not an actual turn but a change in the driving conditions. For example the travel mode or classes. If the road takes a turn itself, the `modifier` describes the direction |
| `exit roundabout`| Describes a maneuver exiting a roundabout (usually preceeded by a `roundabout` instruction) |
| `exit rotary` | Describes the maneuver exiting a rotary (large named roundabout) |
Please note that even though there are `new name` and `notification` instructions, the `mode` and `name` can change
between all instructions. They only offer a fallback in case nothing else is to report.
-`modifier` An optional `string` indicating the direction change of the maneuver.
The list of turns without a modifier is limited to: `depart/arrive`. If the source/target location is close enough to the `depart/arrive` location, no modifier will be given.
| `turn` | `modifier` indicates the change in direction accomplished through the turn |
| `depart`/`arrive` | `modifier` indicates the position of departure point and arrival point in relation to the current direction of travel |
-`exit` An optional `integer` indicating number of the exit to take. The property exists for the `roundabout` / `rotary` property:
Number of the roundabout exit to take. If exit is `undefined` the destination is on the roundabout.
New properties (potentially depending on `type`) may be introduced in the future without an API version change.
### Lane object
A `Lane` represents a turn lane at the corresponding turn location.
**Properties**
-`indications`: a indication (e.g. marking on the road) specifying the turn lane. A road can have multiple indications (e.g. an arrow pointing straight and left). The indications are given in an array, each containing one of the following types. Further indications might be added on without an API version change.
OSRM can be used as a library (libosrm) via C++ instead of using it through the HTTP interface and `osrm-routed`. This allows for fine-tuning OSRM and has much less overhead. Here is a quick introduction into how to use `libosrm` in the upcoming v5 release.
Take a look at the example code that lives in the [example directory](https://github.com/Project-OSRM/osrm-backend/tree/master/example). Here is all you ever wanted to know about `libosrm`, that is a short description of what the types do and where to find documentation on it:
## Important interface objects
- [`EngineConfig`](https://github.com/Project-OSRM/osrm-backend/blob/master/include/engine/engine_config.hpp) - for initializing an OSRM instance we can configure certain properties and constraints. E.g. the storage config is the base path such as `france.osm.osrm` from which we derive and load `france.osm.osrm.*` auxiliary files. This also lets you set constraints such as the maximum number of locations allowed for specific services.
- [`OSRM`](https://github.com/Project-OSRM/osrm-backend/blob/master/include/osrm/osrm.hpp) - this is the main Routing Machine type with functions such as `Route` and `Table`. You initialize it with a `EngineConfig`. It does all the heavy lifting for you. Each function takes its own parameters, e.g. the `Route` function takes `RouteParameters`, and a out-reference to a JSON result that gets filled. The return value is a `Status`, indicating error or success.
- [`Status`](https://github.com/Project-OSRM/osrm-backend/blob/master/include/engine/status.hpp) - this is a type wrapping `Error` or `Ok` for indicating error or success, respectively.
- [`TableParameters`](https://github.com/Project-OSRM/osrm-backend/blob/master/include/engine/api/table_parameters.hpp) - this is an example of parameter types the Routing Machine functions expect. In this case `Table` expects its own parameters as `TableParameters`. You can see it wrapping two vectors, sources and destinations --- these are indices into your coordinates for the table service to construct a matrix from (empty sources or destinations means: use all of them). If you ask yourself where coordinates come from, you can see `TableParameters` inheriting from `BaseParameters`.
- [`BaseParameter`](https://github.com/Project-OSRM/osrm-backend/blob/master/include/engine/api/base_parameters.hpp) - this most importantly holds coordinates (and a few other optional properties that you don't need for basic usage); the specific parameter types inherit from `BaseParameters` to get these member attributes. That means your `TableParameters` type has `coordinates`, `sources` and `destination` member attributes (and a few other that we ignore for now).
- [`Coordinate`](https://github.com/Project-OSRM/osrm-backend/blob/master/include/util/coordinate.hpp) - this is a wrapper around a (longitude, latitude) pair. We really don't care about (lon,lat) vs (lat, lon) but we don't want you to accidentally mix them up, so both latitude and longitude are strictly typed wrappers around integers (fixed notation such as `13423240`) and floating points (floating notation such as `13.42324`).
- [Parameters for other services](https://github.com/Project-OSRM/osrm-backend/tree/master/include/engine/api) - here are all other `*Parameters` you need for other Routing Machine services.
- [JSON](https://github.com/Project-OSRM/osrm-backend/blob/master/include/util/json_container.hpp) - this is a sum type resembling JSON. The Routing Machine service functions take a out-ref to a JSON result and fill it accordingly. It is currently implemented using [mapbox/variant](https://github.com/mapbox/variant) which is similar to [Boost.Variant](http://www.boost.org/doc/libs/1_55_0/doc/html/variant.html). There are two ways to work with this sum type: either provide a visitor that acts on each type on visitation or use the `get` function in case you're sure about the structure. The JSON structure is written down in the [HTTP API](#http-api).
## Example
See [the example folder](https://github.com/Project-OSRM/osrm-backend/tree/master/example) in the OSRM repository.
## Workflow
- Create an `OSRM` instance initialized with a `EngineConfig`
- Call the service function on the `OSRM` object providing service specific `*Parameters`
Consult the [osrm-backend](https://github.com/Project-OSRM/osrm-backend) documentation for further details.
Once you have a complete `network.osrm` file, you can calculate routes in javascript with this object.
```javascript
varosrm=newOSRM('network.osrm');
```
**Parameters**
-`options`**([Object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object) \| [String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String))** Options for creating an OSRM object or string to the `.osrm` file. (optional, default `{shared_memory:true}`)
-`options.algorithm`**[String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)?** The algorithm to use for routing. Can be 'CH', 'CoreCH' or 'MLD'. Default is 'CH'.
Make sure you prepared the dataset with the correct toolchain.
-`options.shared_memory`**[Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean)?** Connects to the persistent shared memory datastore.
This requires you to run `osrm-datastore` prior to creating an `OSRM` object.
-`options.path`**[String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)?** The path to the `.osrm` files. This is mutually exclusive with setting {options.shared_memory} to true.
-`options.max_locations_trip`**[Number](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)?** Max. locations supported in trip query (default: unlimited).
-`options.max_locations_viaroute`**[Number](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)?** Max. locations supported in viaroute query (default: unlimited).
-`options.max_locations_distance_table`**[Number](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)?** Max. locations supported in distance table query (default: unlimited).
-`options.max_locations_map_matching`**[Number](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)?** Max. locations supported in map-matching query (default: unlimited).
-`options.max_results_nearest`**[Number](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)?** Max. results supported in nearest query (default: unlimited).
-`options.max_alternatives`**[Number](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)?** Max.number of alternatives supported in alternative routes query (default: 3).
### route
Returns the fastest route between two or more coordinates while visiting the waypoints in order.
**Parameters**
-`options`**[Object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)** Object literal containing parameters for the route query.
-`options.coordinates`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** The coordinates this request will use, coordinates as `[{lon},{lat}]` values, in decimal degrees.
-`options.bearings`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Limits the search to segments with given bearing in degrees towards true north in clockwise direction.
Can be `null` or an array of `[{value},{range}]` with `integer 0 .. 360,integer 0 .. 180`.
-`options.radiuses`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Limits the coordinate snapping to streets in the given radius in meters. Can be `null` (unlimited, default) or `double >= 0`.
-`options.hints`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Hints for the coordinate snapping. Array of base64 encoded strings.
-`options.alternatives`**[Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean)** Search for alternative routes. (optional, default `false`)
-`options.alternatives`**[Number](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)** Search for up to this many alternative routes.
_Please note that even if alternative routes are requested, a result cannot be guaranteed._ (optional, default `0`)
-`options.steps`**[Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean)** Return route steps for each route leg. (optional, default `false`)
-`options.annotations`**([Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array) \| [Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean))** An array with strings of `duration`, `nodes`, `distance`, `weight`, `datasources`, `speed` or boolean for enabling/disabling all. (optional, default `false`)
-`options.geometries`**[String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)** Returned route geometry format (influences overview and per step). Can also be `geojson`. (optional, default `polyline`)
-`options.overview`**[String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)** Add overview geometry either `full`, `simplified` according to highest zoom level it could be display on, or not at all (`false`). (optional, default `simplified`)
-`options.continue_straight`**[Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean)?** Forces the route to keep going straight at waypoints and don't do a uturn even if it would be faster. Default value depends on the profile.
-`options.approaches`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Keep waypoints on curb side. Can be `null` (unrestricted, default) or `curb`.
console.log(result.waypoints);// array of Waypoint objects representing all waypoints in order
console.log(result.routes);// array of Route objects ordered by descending recommendation rank
});
```
Returns **[Object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)** An array of [Waypoint](#waypoint) objects representing all waypoints in order AND an array of [`Route`](#route) objects ordered by descending recommendation rank.
### nearest
Snaps a coordinate to the street network and returns the nearest n matches.
Note: `coordinates` in the general options only supports a single `{longitude},{latitude}` entry.
**Parameters**
-`options`**[Object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)** Object literal containing parameters for the nearest query.
-`options.coordinates`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** The coordinates this request will use, coordinates as `[{lon},{lat}]` values, in decimal degrees.
-`options.bearings`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Limits the search to segments with given bearing in degrees towards true north in clockwise direction.
Can be `null` or an array of `[{value},{range}]` with `integer 0 .. 360,integer 0 .. 180`.
-`options.radiuses`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Limits the coordinate snapping to streets in the given radius in meters. Can be `null` (unlimited, default) or `double >= 0`.
-`options.hints`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Hints for the coordinate snapping. Array of base64 encoded strings.
-`options.number`**[Number](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)** Number of nearest segments that should be returned.
Must be an integer greater than or equal to `1`. (optional, default `1`)
-`options.approaches`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Keep waypoints on curb side. Can be `null` (unrestricted, default) or `curb`.
**`waypoints`**: array of [`Ẁaypoint`](#waypoint) objects sorted by distance to the input coordinate.
Each object has an additional `distance` property, which is the distance in meters to the supplied input coordinate.
### table
Computes duration tables for the given locations. Allows for both symmetric and asymmetric
tables.
**Parameters**
-`options`**[Object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)** Object literal containing parameters for the table query.
-`options.coordinates`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** The coordinates this request will use, coordinates as `[{lon},{lat}]` values, in decimal degrees.
-`options.bearings`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Limits the search to segments with given bearing in degrees towards true north in clockwise direction.
Can be `null` or an array of `[{value},{range}]` with `integer 0 .. 360,integer 0 .. 180`.
-`options.radiuses`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Limits the coordinate snapping to streets in the given radius in meters. Can be `null` (unlimited, default) or `double >= 0`.
-`options.hints`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Hints for the coordinate snapping. Array of base64 encoded strings.
-`options.sources`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** An array of `index` elements (`0 <= integer < #coordinates`) to
use
location with given index as source. Default is to use all.
-`options.destinations`**[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** An array of `index` elements (`0 <= integer <
#coordinates`) to use location with given index as destination. Default is to use all.
- `options.approaches` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Keep waypoints on curb side. Can be `null` (unrestricted, default) or `curb`.
console.log(response.durations); // array of arrays, matrix in row-major order
console.log(response.sources); // array of Waypoint objects
console.log(response.destinations); // array of Waypoint objects
});
```
Returns **[Object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)** containing `durations`, `sources`, and `destinations`.
**`durations`**: array of arrays that stores the matrix in row-major order. `durations[i][j]` gives the travel time from the i-th waypoint to the j-th waypoint.
Values are given in seconds.
**`sources`**: array of [`Ẁaypoint`](#waypoint) objects describing all sources in order.
**`destinations`**: array of [`Ẁaypoint`](#waypoint) objects describing all destinations in order.
### tile
This generates [Mapbox Vector Tiles](https://mapbox.com/vector-tiles) that can be viewed with a
vector-tile capable slippy-map viewer. The tiles contain road geometries and metadata that can
be used to examine the routing graph. The tiles are generated directly from the data in-memory,
so are in sync with actual routing results, and let you examine which roads are actually
routable,
and what weights they have applied.
**Parameters**
- `ZXY` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)** an array consisting of `x`, `y`, and `z` values representing tile coordinates like
fs.writeFileSync('./tile.vector.pbf', response); // write the buffer to a file
});
```
Returns **[Buffer](https://nodejs.org/api/buffer.html)** contains a Protocol Buffer encoded vector tile.
### match
Map matching matches given GPS points to the road network in the most plausible way.
Please note the request might result multiple sub-traces. Large jumps in the timestamps
(>60s) or improbable transitions lead to trace splits if a complete matching could
not be found. The algorithm might not be able to match all points. Outliers are removed
if they can not be matched successfully.
**Parameters**
- `options` **[Object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)** Object literal containing parameters for the match query.
- `options.coordinates` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** The coordinates this request will use, coordinates as `[{lon},{lat}]` values, in decimal degrees.
- `options.bearings` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Limits the search to segments with given bearing in degrees towards true north in clockwise direction.
Can be `null` or an array of `[{value},{range}]` with `integer 0 .. 360,integer 0 .. 180`.
- `options.hints` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Hints for the coordinate snapping. Array of base64 encoded strings.
- `options.steps` **[Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean)** Return route steps for each route. (optional, default `false`)
- `options.annotations` **([Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array) \| [Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean))** An array with strings of `duration`, `nodes`, `distance`, `weight`, `datasources`, `speed` or boolean for enabling/disabling all. (optional, default `false`)
- `options.geometries` **[String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)** Returned route geometry format (influences overview and per step). Can also be `geojson`. (optional, default `polyline`)
- `options.overview` **[String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)** Add overview geometry either `full`, `simplified` according to highest zoom level it could be display on, or not at all (`false`). (optional, default `simplified`)
- `options.timestamps` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)<[Number](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number)>?** Timestamp of the input location (integers, UNIX-like timestamp).
- `options.radiuses` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Standard deviation of GPS precision used for map matching. If applicable use GPS accuracy. Can be `null` for default value `5` meters or `double >= 0`.
- `options.gaps` **[String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)?** Allows the input track splitting based on huge timestamp gaps between points. Either `split` or `ignore` (optional, default `split`).
- `options.tidy` **[Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean)?** Allows the input track modification to obtain better matching quality for noisy tracks (optional, default `false`).
console.log(response.tracepoints); // array of Waypoint objects
console.log(response.matchings); // array of Route objects
});
```
Returns **[Object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)** containing `tracepoints` and `matchings`.
**`tracepoints`** Array of [`Ẁaypoint`](#waypoint) objects representing all points of the trace in order.
If the trace point was ommited by map matching because it is an outlier, the entry will be null.
Each `Waypoint` object includes two additional properties, 1) `matchings_index`: Index to the
[`Route`](#route) object in matchings the sub-trace was matched to, 2) `waypoint_index`: Index of
the waypoint inside the matched route.
**`matchings`** is an array of [`Route`](#route) objects that assemble the trace. Each `Route` object has an additional `confidence` property,
which is the confidence of the matching. float value between `0` and `1`. `1` is very confident that the matching is correct.
### trip
The trip plugin solves the Traveling Salesman Problem using a greedy heuristic
(farthest-insertion algorithm) for 10 or _ more waypoints and uses brute force for less than 10
waypoints. The returned path does not have to be the shortest path, _ as TSP is NP-hard it is
only an approximation.
Note that all input coordinates have to be connected for the trip service to work.
Currently, not all combinations of `roundtrip`, `source` and `destination` are supported.
Right now, the following combinations are possible:
| roundtrip | source | destination | supported |
| :-------- | :----- | :---------- | :-------- |
| true | first | last | **yes** |
| true | first | any | **yes** |
| true | any | last | **yes** |
| true | any | any | **yes** |
| false | first | last | **yes** |
| false | first | any | no |
| false | any | last | no |
| false | any | any | no |
**Parameters**
- `options` **[Object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object)** Object literal containing parameters for the trip query.
- `options.coordinates` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** The coordinates this request will use, coordinates as `[{lon},{lat}]` values, in decimal degrees.
- `options.bearings` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Limits the search to segments with given bearing in degrees towards true north in clockwise direction.
Can be `null` or an array of `[{value},{range}]` with `integer 0 .. 360,integer 0 .. 180`.
- `options.radiuses` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Limits the coordinate snapping to streets in the given radius in meters. Can be `double >= 0` or `null` (unlimited, default).
- `options.hints` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Hints for the coordinate snapping. Array of base64 encoded strings.
- `options.steps` **[Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean)** Return route steps for each route. (optional, default `false`)
- `options.annotations` **([Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array) \| [Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean))** An array with strings of `duration`, `nodes`, `distance`, `weight`, `datasources`, `speed` or boolean for enabling/disabling all. (optional, default `false`)
- `options.geometries` **[String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)** Returned route geometry format (influences overview and per step). Can also be `geojson`. (optional, default `polyline`)
- `options.roundtrip` **[Boolean](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean)** Return route is a roundtrip. (optional, default `true`)
- `options.source` **[String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)** Return route starts at `any` or `first` coordinate. (optional, default `any`)
- `options.destination` **[String](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String)** Return route ends at `any` or `last` coordinate. (optional, default `any`)
- `options.approaches` **[Array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array)?** Keep waypoints on curb side. Can be `null` (unrestricted, default) or `curb`.
Releasing a new version of `node-osrm` is mostly automated using Travis CI.
The version of `node-osrm` is locked to the same version as `osrm-backend`. Every `node-osrm` should have a `osrm-backend` release of the same version. Of course, only release a `node-osrm` after the release has been tagged in `osrm-backend`.
These steps all happen on `master`. After the release is out, create a branch using the MAJOR.MINOR version of the release to document code changes made for that version.
### Steps to release
1. Update the `osrm_release` field in `package.json` to the corresonding git tag in `osrm-backend.`
Confirm the desired OSRM branch and commit to `master`.
1. Bump node-osrm version
Update the `CHANGELOG.md` and the `package.json` version if needed.
1. Check that Travis CI [builds are passing](https://travis-ci.org/Project-OSRM/node-osrm) for the latest commit on `master`.
1. Publishing binaries
If travis builds are passing then it's time to publish binaries by committing with a message containing `[publish binary]`. Use an empty commit for this.
OSRM supports "profiles". Profiles representing routing behavior for different transport modes like car, bike and foot. You can also create profiles for variations like a fastest/shortest car profile or fastest/safest/greenest bicycles profile.
A profile describes whether or not it's possible to route along a particular type of way, whether we can pass a particular node, and how quickly we'll be traveling when we do. This feeds into the way the routing graph is created and thus influences the output routes.
## Available profiles
Out-of-the-box OSRM comes with profiles for car, bicycle and foot. You can easily modify these or create new ones if you like.
Profiles have a 'lua' extension, and are placed in 'profiles' directory.
When running OSRM preprocessing commands you specify the profile with the --profile (or the shorthand -p) option, for example:
It's important to understand that profiles are used when preprocessing the OSM data, NOT at query time when routes are computed.
This means that after modifying a profile **you will need to extract, contract and reload the data again** and to see changes in the routing results. See [Processing Flow](https://github.com/Project-OSRM/osrm-backend/wiki/Processing-Flow) for more.
## Profiles are written in Lua
Profiles are not just configuration files. They are scripts written in the [Lua scripting language](http://www.lua.org). The reason for this is that OpenStreetMap data is complex, and it's not possible to simply define tag mappings. Lua scripting offers a powerful way to handle all the possible tag combinations found in OpenStreetMap nodes and ways.
## Basic structure of profiles
A profile will process every node and way in the OSM input data to determine what ways are routable in which direction, at what speed, etc.
A profile will typically:
- Define api version (required)
- Require library files (optional)
- Define setup function (required)
- Define process functions (some are required)
- Return functions table (required)
A profile can also define various local functions it needs.
Looking at [car.lua](../profiles/car.lua) as an example, at the top of the file the api version is defined and then required library files are included.
Then follows the `setup` function, which is called once when the profile is loaded. It returns a big hash table of configurations, specifying things like what speed to use for different way types. The configurations are used later in the various processing functions. Many adjustments can be done just by modifying this configuration table.
The setup function is also where you can do other setup, like loading an elevation data source if you want to consider that when processing ways.
Then come the `process_node` and `process_way` functions, which are called for each OSM node and way when extracting OpenStreetMap data with `osrm-extract`.
The `process_turn` function processes every possible turn in the network, and sets a penalty depending on the angle and turn of the movement.
Profiles can also define a `process_segment` function to handle differences in speed along an OSM way, for example to handle elevation. As you can see, this is not currently used in the car profile.
At the end of the file, a table is returned with references to the setup and processing functions the profile has defined.
## Understanding speed, weight and rate
When computing a route from A to B there can be different measures of what is the best route. That's why there's a need for different profiles.
Because speeds vary on different types of roads, the shortest and the fastest route are typically different. But there are many other possible preferences. For example a user might prefer a bicycle route that follow parks or other green areas, even though both duration and distance are a bit longer.
To handle this, OSRM doesn't simply choose the ways with the highest speed. Instead it uses the concepts of `weight` and `rate`. The rate is an abstract measure that you can assign to ways as you like to make some ways preferable to others. Routing will prefer ways with high rate.
The weight of a way is normally computed as length / rate. The weight can be thought of as the resistance or cost when passing the way. Routing will prefer ways with low weight.
You can also set the weight of a way to a fixed value. In this case it's not calculated based on the length or rate, and the rate is ignored.
You should set the speed to your best estimate of the actual speed that will be used on a particular way. This will result in the best estimated travel times.
If you want to prefer certain ways due to other factors than the speed, adjust the rate accordingly. If you adjust the speed, the time estimation will be skewed.
If you set the same rate on all ways, the result will be shortest path routing.
If you set rate = speed on all ways, the result will be fastest path routing.
If you want to prioritize certain streets, increase the rate on these.
## Elements
### api_version
A profile should set `api_version` at the top of your profile. This is done to ensure that older profiles are still supported when the api changes. If `api_version` is not defined, 0 will be assumed. The current api version is 2.
### Library files
The folder [profiles/lib/](../profiles/lib/) contains LUA library files for handling many common processing tasks.
File | Notes
------------------|------------------------------
way_handlers.lua | Functions for processing way tags
tags.lua | Functions for general parsing of OSM tags
set.lua | Defines the Set helper for handling sets of values
sequence.lua | Defines the Sequence helper for handling sequences of values
access.lua | Function for finding relevant access tags
destination.lua | Function for finding relevant destination tags
maxspeed.lua | Function for determining maximum speed
guidance.lua | Function for processing guidance attributes
They all return a table of functions when you use `require` to load them. You can either store this table and reference its functions later, or if you need only a single function you can store that directly.
### setup()
The `setup` function is called once when the profile is loaded and must return a table of configurations. It's also where you can do other global setup, like loading data sources that are used during processing.
Note that processing of data is parallelized and several unconnected LUA interpreters will be running at the same time. The `setup` function will be called once for each. Each LUA iinterpreter will have its own set of globals.
The following global properties can be set under `properties` in the hash you return in the `setup` function:
left_hand_driving | Boolean | Are vehicles assumed to drive on the left? (used in guidance, default `false`)
use_turn_restrictions | Boolean | Are turn instructions followed? (default `false`)
continue_straight_at_waypoint | Boolean | Must the route continue straight on at a via point, or are U-turns allowed? (default `true`)
max_speed_for_map_matching | Float | Maximum vehicle speed to be assumed in matching (in m/s)
max_turn_weight | Float | Maximum turn penalty weight
force_split_edges | Boolean | True value forces a split of forward and backward edges of extracted ways and guarantees that `process_segment` will be called for all segments (default `false`)
The following additional global properties can be set in the hash you return in the `setup` function:
excludable | Sequence of Sets | Determines which class-combinations are supported by the `exclude` option at query time. E.g. `Sequence{Set{"ferry", "motorway"}, Set{"motorway"}}` will allow you to exclude ferries and motorways, or only motorways.
classes | Sequence | Determines the allowed classes that can be referenced using `{forward,backward}_classes` on the way in the `process_way` function.
restrictions | Sequence | Determines which turn restrictions will be used for this profile.
suffix_list | Set | List of name suffixes needed for determining if "Highway 101 NW" the same road as "Highway 101 ES".
relation_types | Sequence | Determines wich relations should be cached for processing in this profile. It contains relations types
traffic_lights | Boolean | Is it a traffic light (incurs delay in `process_turn`)?
### process_way(profile, way, result, relations)
Given an OpenStreetMap way, the `process_way` function will either return nothing (meaning we are not going to route over this way at all), or it will set up a result hash.
profile | The configuration table you returned in `setup`.
node | The input way to process (read-only).
result | The output that you will modify.
relations| Storage of relations to access relations, where `way` is a member.
Importantly it will set `result.forward_mode` and `result.backward_mode` to indicate the travel mode in each direction, as well as set `result.forward_speed` and `result.backward_speed` to integer values representing the speed for traversing the way.
It will also set a number of other attributes on `result`.
Using the power of the scripting language you wouldn't typically see something as simple as a `result.forward_speed = 20` line within the `process_way` function. Instead `process_way` will examine the tag set on the way, process this information in various ways, calling other local functions and referencing the configuration in `profile`, etc., before arriving at the result.
The following attributes can be set on the result in `process_way`:
forward_speed | Float | Speed on this way in km/h. Mandatory.
backward_speed | Float | ""
forward_rate | Float | Routing weight, expressed as meters/*weight* (e.g. for a fastest-route weighting, you would want this to be meters/second, so set it to forward_speed/3.6)
backward_rate | Float | ""
forward_mode | Enum | Mode of travel (e.g. `car`, `ferry`). Mandatory. Defined in `include/extractor/travel_mode.hpp`.
backward_mode | Enum | ""
forward_classes | Table | Mark this way as being of a specific class, e.g. `result.classes["toll"] = true`. This will be exposed in the API as `classes` on each `RouteStep`.
backward_classes | Table | ""
duration | Float | Alternative setter for duration of the whole way in both directions
weight | Float | Alternative setter for weight of the whole way in both directions
turn_lanes_forward | String | Directions for individual lanes (normalized OSM `turn:lanes` value)
turn_lanes_backward | String | ""
forward_restricted | Boolean | Is this a restricted access road? (e.g. private, or deliveries only; used to enable high turn penalty, so that way is only chosen for start/end of route)
backward_restricted | Boolean | ""
is_startpoint | Boolean | Can a journey start on this way? (e.g. ferry; if `false`, prevents snapping the start point to this way)
roundabout | Boolean | Is this part of a roundabout?
circular | Boolean | Is this part of a non-roundabout circular junction?
name | String | Name of the way
ref | String | Road number (equal to set `forward_ref` and `backward_ref` with one value)
forward_ref | String | Road number in forward way direction
backward_ref | String | Road number in backward way direction
destinations | String | The road's destinations
exits | String | The ramp's exit numbers or names
pronunciation | String | Name pronunciation
road_classification.motorway_class | Boolean | Guidance: way is a motorway
road_classification.link_class | Boolean | Guidance: way is a slip/link road
road_classification.road_priority_class | Enum | Guidance: order in priority list. Defined in `include/extractor/guidance/road_classification.hpp`
road_classification.may_be_ignored | Boolean | Guidance: way is non-highway
road_classification.num_lanes | Unsigned | Guidance: total number of lanes in way
### process_segment(profile, segment)
The `process_segment` function is called for every segment of OSM ways. A segment is a straight line between two OSM nodes.
On OpenStreetMap way cannot have different tags on different parts of a way. Instead you would split the way into several smaller ways. However many ways are long. For example, many ways pass hills without any change in tags.
Processing each segment of an OSM way makes it possible to have different speeds on different parts of a way based on external data like data about elevation, pollution, noise or scenic value and adjust weight and duration of the segment accordingly.
In the `process_segment` function you don't have access to OSM tags. Instead you use the geographical location of the start and end point of the way to look up information from another data source, like elevation data. See [rasterbot.lua](../profiles/rasterbot.lua) for an example.
The following attributes can be read and set on the result in `process_segment`:
source.lon | Read | Float | Co-ordinates of segment start
source.lat | Read | Float | ""
target.lon | Read | Float | Co-ordinates of segment end
target.lat | Read | Float | ""
target.distance | Read | Float | Length of segment
weight | Read/write | Float | Routing weight for this segment
duration | Read/write | Float | Duration for this segment
### process_turn(profile, turn)
The `process_turn` function is called for every possible turn in the network. Based on the angle and type of turn you assign the weight and duration of the movement.
The following attributes can be read and set on the result in `process_turn`:
angle | Read | Float | Angle of turn in degrees (`[-179, 180]`: `0`=straight, `180`=u turn, `+x`=x degrees to the right, `-x`= x degrees to the left)
number_of_roads | Read | Integer | Number of ways at the intersection of the turn
is_u_turn | Read | Boolean | Is the turn a u-turn?
has_traffic_light | Read | Boolean | Is a traffic light present at this turn?
is_left_hand_driving | Read | Boolean | Is left-hand traffic?
source_restricted | Read | Boolean | Is it from a restricted access road? (See definition in `process_way`)
source_mode | Read | Enum | Travel mode before the turn. Defined in `include/extractor/travel_mode.hpp`
source_is_motorway | Read | Boolean | Is the source road a motorway?
source_is_link | Read | Boolean | Is the source road a link?
source_number_of_lanes | Read | Integer | How many lanes does the source road have? (default when not tagged: 0)
source_highway_turn_classification | Read | Integer | Classification based on highway tag defined by user during setup. (default when not set: 0, allowed classification values are: 0-15))
source_access_turn_classification | Read | Integer | Classification based on access tag defined by user during setup. (default when not set: 0, allowed classification values are: 0-15))
source_speed | Read | Integer | Speed on this source road in km/h
source_priority_class | Read | Enum | The type of road priority class of the source. Defined in `include/extractor/guidance/road_classification.hpp`
target_restricted | Read | Boolean | Is it from a restricted access road? (See definition in `process_way`)
target_mode | Read | Enum | Travel mode before the turn. Defined in `include/extractor/travel_mode.hpp`
target_is_motorway | Read | Boolean | Is the target road a motorway?
target_is_link | Read | Boolean | Is the target road a link?
target_number_of_lanes | Read | Integer | How many lanes does the target road have? (default when not tagged: 0)
target_highway_turn_classification | Read | Integer | Classification based on highway tag defined by user during setup. (default when not set: 0, allowed classification values are: 0-15))
target_access_turn_classification | Read | Integer | Classification based on access tag defined by user during setup. (default when not set: 0, allowed classification values are: 0-15))
target_speed | Read | Integer | Speed on this target road in km/h
target_priority_class | Read | Enum | The type of road priority class of the target. Defined in `include/extractor/guidance/road_classification.hpp`
roads_on_the_right | Read | Vector<ExtractionTurnLeg> | Vector with information about other roads on the right of the turn that are also connected at the intersection
roads_on_the_left | Read | Vector<ExtractionTurnLeg> | Vector with information about other roads on the left of the turn that are also connected at the intersection. If turn is a u turn, this is empty.
weight | Read/write | Float | Penalty to be applied for this turn (routing weight)
duration | Read/write | Float | Penalty to be applied for this turn (duration in deciseconds)
#### `roads_on_the_right` and `roads_on_the_left`
The information of `roads_on_the_right` and `roads_on_the_left` that can be read are as follows:
is_restricted | Read | Boolean | Is it a restricted access road? (See definition in `process_way`)
mode | Read | Enum | Travel mode before the turn. Defined in `include/extractor/travel_mode.hpp`
is_motorway | Read | Boolean | Is the road a motorway?
is_link | Read | Boolean | Is the road a link?
number_of_lanes | Read | Integer | How many lanes does the road have? (default when not tagged: 0)
highway_turn_classification | Read | Integer | Classification based on highway tag defined by user during setup. (default when not set: 0, allowed classification values are: 0-15)
access_turn_classification | Read | Integer | Classification based on access tag defined by user during setup. (default when not set: 0, allowed classification values are: 0-15)
speed | Read | Integer | Speed on this road in km/h
priority_class | Read | Enum | The type of road priority class of the leg. Defined in `include/extractor/guidance/road_classification.hpp`
is_incoming | Read | Boolean | Is the road an incoming road of the intersection
is_outgoing | Read | Boolean | Is the road an outgoing road of the intersection
The order of the roads in `roads_on_the_right` and `roads_on_the_left` are *counter clockwise*. If the turn is a u turn, all other connected roads will be in `roads_on_the_right`.
**Example**
```
c e
| /
| /
a ---- x ---- b
/|
/ |
f d
```
When turning from `a` to `b` via `x`,
*`roads_on_the_right[1]` is the road `xf`
*`roads_on_the_right[2]` is the road `xd`
*`roads_on_the_left[1]` is the road `xe`
*`roads_on_the_left[2]` is the road `xc`
Note that indices of arrays in lua are 1-based.
#### `highway_turn_classification` and `access_turn_classification`
When setting appropriate turn weights and duration, information about the highway and access tags of roads that are involved in the turn are necessary. The lua turn function `process_turn` does not have access to the original osrm tags anymore. However, `highway_turn_classification` and `access_turn_classification` can be set during setup. The classification set during setup can be later used in `process_turn`.
**Example**
In the following example we use `highway_turn_classification` to set the turn weight to `10` if the turn is on a highway and to `5` if the turn is on a primary.
```
function setup()
return {
highway_turn_classification = {
['motorway'] = 2,
['primary'] = 1
}
}
end
function process_turn(profile, turn) {
if turn.source_highway_turn_classification == 2 and turn.target_highway_turn_classification == 2 then
turn.weight = 10
end
if turn.source_highway_turn_classification == 1 and turn.target_highway_turn_classification == 1 then
turn.weight = 5
end
}
```
## Guidance
The guidance parameters in profiles are currently a work in progress. They can and will change.
Please be aware of this when using guidance configuration possibilities.
Guidance uses road classes to decide on when/if to emit specific instructions and to discover which road is obvious when following a route.
Classification uses three flags and a priority-category.
The flags indicate whether a road is a motorway (required for on/off ramps), a link type (the ramps itself, if also a motorway) and whether a road may be omitted in considerations (is considered purely for connectivity).
The priority-category influences the decision which road is considered the obvious choice and which roads can be seen as fork.
Forks can be emitted between roads of similar priority category only. Obvious choices follow a major priority road, if the priority difference is large.
### Using raster data
OSRM has built-in support for loading an interpolating raster data in ASCII format. This can be used e.g. for factoring in elevation when computing routes.
Use `raster:load()` in your `setup` function to load data and store the source in your configuration hash:
```lua
functionsetup()
return{
raster_source=raster:load(
"rastersource.asc",-- file to load
0,-- longitude min
0.1,-- longitude max
0,-- latitude min
0.1,-- latitude max
5,-- number of rows
4-- number of columns
)
}
end
```
The input data must an ASCII file with rows of integers. e.g.:
```
0 0 0 0
0 0 0 250
0 0 250 500
0 0 0 250
0 0 0 0
```
In your `segment_function` you can then access the raster source and use `raster:query()` to query to find the nearest data point, or `raster:interpolate()` to interpolate a value based on nearby data points.
You must check whether the result is valid before use it.
We are using http://semver.org/ for versioning with major, minor and patch versions.
## Guarantees
We are giving the following guarantees between versions:
### Major version change
- There are no guarantees about compatiblity of APIs or datasets
- Breaking changes will be noted as `BREAKING` in the changelog
### Minor version change
We may introduce forward-compatible changes: query parameters and response properties may be added in responses, but existing properties may not be changed or removed. One exception to this is the addition of new turn types, which we see as forward-compatible changes.
- Forward-compatible HTTP API
- Forward-compatible C++ library API
- Forward-compatible node-osrm API
- No compatiblity between OSRM datasets (needs new processing)
### Patch version change
- No change of query parameters or response formats
- Compatible HTTP API
- Compatible C++ library API
- Compatible node-osrm API
- Compatible OSRM datasets
## Release and branch management
- The `master` branch is for the bleeding edge development
- We create and maintain release branches `x.y` to control the release flow
- We create the release branch once we create release branches once we want to release the first RC
- RCs go in the release branch, commits needs to be cherry-picked from master
- No minor or major version will be released without a code-equal release candidates
- For quality assurance, release candidates need to be staged beforing tagging a final release
- Patch versions may be released without a release candidate
- We may backport fixes to older versions and release them as patch versions
## Releasing a version
1. Check out the appropriate release branch `x.y`
2. Make sure `CHANGELOG.md` is up to date.
3. Make sure the OSRM version in `CMakeLists.txt` is up to date
4. Make sure the `package.json` is up to date.
5. Make sure all tests are passing (e.g. Travis CI gives you a :thumbs_up:)
6. Use an annotated tag to mark the release: `git tag vx.y.z -a` Body of the tag description should be the changelog entries.
7. Use `npm run docs` to generate the API documentation. Copy `build/docs/*` to `https://github.com/Project-OSRM/project-osrm.github.com` in the `docs/vN.N.N/api` directory
8. Push tags and commits: `git push; git push --tags`
9. If not a release-candidate: Write a mailing-list post to osrm-talk@openstreetmap.org to announce the release
10. Wait until the travis build has been completed and check if the node binaries were published by doing:
`rm -rf node_modules && npm install` locally.
11. For final releases run `npm publish` or `npm publish --tag next` for release candidates.
12. Bump version in `package.json` to `{MAJOR}.{MINOR+1}.0-latest.1` on the `master` branch after the release.
OSRM comes with a testsuite containing both unit-tests using the Boost library and cucumber.js for scenario driven testing.
## Unit Tests
For a general introduction on Boost.Test have a look at [its docs](http://www.boost.org/doc/libs/1_60_0/libs/test/doc/html/index.html).
### Separate Test Binaries
Unit tests should be registered according to the sub-project they're in.
If you want to write tests for utility functions, add them to the utility test binary.
See `CMakeLists.txt` in the unit test directory for how to register new unit tests.
### Using Boost.Test Primitives
There is a difference between only reporting a failed condition and aborting the test right at a failed condition.
Have a look at [`BOOST_CHECK` vs `BOOST_REQUIRE`](http://www.boost.org/doc/libs/1_60_0/libs/test/doc/html/boost_test/utf_reference/testing_tool_ref/assertion_boost_level.html).
Instead of manually checking e.g. for equality, less than, if a function throws etc. use their [corresponding Boost.Test primitives](http://www.boost.org/doc/libs/1_60_0/libs/test/doc/html/boost_test/utf_reference/testing_tool_ref.html).
If you use `BOOST_CHECK_EQUAL` you have to implement `operator<<` for your type so that Boost.Test can print mismatches.
If you do not want to do this, define `BOOST_TEST_DONT_PRINT_LOG_VALUE` (and undef it after the check call) or sidestep it with `BOOST_CHECK(fst == snd);`.
### Test Fixture
If you need to test features on a real dataset (think about this twice: prefer cucumber and dataset-independent tests for their reproducibility and minimality), there is a fixed dataset in `test/data`.
This dataset is a small extract and may not even contain all tags or edge cases.
Furthermore this dataset is not in sync with what you see in up-to-date OSM maps or on the demo server.
See the library tests for how to add new dataset dependent tests.
To prepare the test data simply `cd test/data/` and then run `make`.
### Running Tests
To build the unit tests:
```
cd build
cmake ..
make tests
```
You should see the compiled binaries in `build/unit_tests`, you can then run each suite individually:
```
./engine-tests
```
## Cucumber
For a general introduction on cucumber in our testsuite, have a look at [the wiki](https://github.com/Project-OSRM/osrm-backend/wiki/Cucumber-Test-Suite).
This documentation aims to supply a guideline on how to write cucumber tests that test new features introduced into osrm.
### Test the feature
It is often tempting to reduce the test to a path and accompanying instructions. Instructions can and will change over the course of improving guidance.
Instructions should only be used when writing a feature located in `features/guidance`. All other features should avoid using instructions at all.
### Write Tests to Scale
OSRM is a navigation engine. Tests should always consider this background.
An important implication is the grid size. If tests use a very small grid size, you run into the chance of instructions being omitted.
For example:
```
Background:
Given the profile "car"
Given a grid size of 10 meters
Scenario: Testbot - Straight Road
Given the node map
"""
a b c d
"""
And the ways
| nodes | highway |
| ab | primary |
| bc | primary |
| cd | primary |
When I route I should get
| from | to | route |
| a | d | ab,bc,cd,cd |
```
In a navigation engine, the instructions
- depart east on ab
- in 10 meters the road name changes to bc
- in 10 meters the road name changes to cd
- you arrived at cd
would be impossible to announce and not helpful at all.
Since no actual choices exist, the route you get could result in `ab,cd` and simply say `depart` and `arrive`.
To prevent such surprises, always consider the availability of other roads and use grid sizes/road lengths that correspond to actually reasonable scenarios in a road network.
### Use names
If you specify many nodes in close succession to present a specific road geometry, consider using `name` to indicate to OSRM that the segment is a single road.
```
Background:
Given the profile "car"
Given a grid size of 10 meters
Scenario: Testbot - Straight Road
Given the node map
"""
a b c d
"""
And the ways
| nodes | highway | name |
| ab | primary | road |
| bc | primary | road |
| cd | primary | road |
When I route I should get
| from | to | route | turns |
| a | d | road,road | depart,arrive |
```
Guidance guarantees only essential maneuvers. You will always see `depart` and `arrive` as well as all turns that are not obvious.
So the following scenario does not change the instructions
```
Background:
Given the profile "car"
Given a grid size of 10 meters
Scenario: Testbot - Straight Road
Given the node map
"""
a b
d c
"""
And the ways
| nodes | highway | name |
| ab | primary | road |
| bc | primary | road |
| cd | primary | road |
When I route I should get
| from | to | route | turns |
| a | d | road,road | depart,arrive |
```
but if we modify it to
```
Background:
Given the profile "car"
Given a grid size of 10 meters
Scenario: Testbot - Straight Road
Given the node map
"""
a b e
d c
"""
And the ways
| nodes | highway | name |
| ab | primary | road |
| bc | primary | road |
| cd | primary | road |
| be | primary | turn |
When I route I should get
| from | to | route | turns |
| a | d | road,road,road | depart,continue right,arrive |
```
### Test all directions
Modelling a road as roundabout has an implied oneway tag associated with it. In the following case, we can route from `a` to `d` but not from `d` to `a`.
To discover those errors, make sure to check for all allowed directions.
```
Scenario: Enter and Exit mini roundabout with sharp angle # features/guidance/mini-roundabout.feature:37
Given the profile "car" # features/step_definitions/data.js:8
Given a grid size of 10 meters # features/step_definitions/data.js:20
Given the node map # features/step_definitions/data.js:45
"""
a b
c d
"""
And the ways # features/step_definitions/data.js:128
| nodes | highway | name |
| ab | tertiary | MySt |
| bc | roundabout | |
| cd | tertiary | MySt |
When I route I should get # features/step_definitions/routing.js:4
| from | to | route | turns | # |
| a | d | MySt,MySt | depart,arrive | # suppress multiple enter/exit mini roundabouts |
| d | a | MySt,MySt | depart,arrive | # suppress multiple enter/exit mini roundabouts |
Tables were not identical:
| from | to | route | turns | #
| a | d | MySt,MySt | depart,arrive | # suppress multiple enter/exit mini roundabouts |
| (-) d | (-) a | (-) MySt,MySt | (-) depart,arrive | (-) # suppress multiple enter/exit mini roundabouts |
| (+) d | (+) a | (+) | (+) | (+) # suppress multiple enter/exit mini roundabouts |
```
### Prevent Randomness
Some features in OSRM can result in strange experiences during testcases. To prevent some of these issues, follow the guidelines below.
#### Use Waypoints
Using grid nodes as waypoints offers the chance of unwanted side effects.
OSRM converts the grid into a so called edge-based graph.
```
Scenario: Testbot - Intersection
Given the node map
"""
e
b a d
c
"""
And the ways
| nodes | highway | oneway |
| ab | primary | yes |
| ac | primary | yes |
| ad | primary | yes |
| ae | primary | yes |
```
Selecting `a` as a `waypoint` results in four possible starting locations. Which one of the routes `a,b`, `a,c`, `a,d`, or `a,e` is found is pure chance and depends on the order in the static `r-tree`.
To guarantee discovery, use:
```
Scenario: Testbot - Intersection
Given the node map
"""
e
4
b 1 a 3 d
2
c
"""
And the ways
| nodes | highway | oneway |
| ab | primary | yes |
| ac | primary | yes |
| ad | primary | yes |
| ae | primary | yes |
```
And use `1`,`2`,`3`, and `4` as starting waypoints. The routes `1,b`, `2,c`, `3,d`, and `4,e` can all be discovered.
#### Allow For Small Offsets
Whenever you are independent of the start location (see use waypoints), the waypoint chosen as start/end location can still influence distances/durations.
If you are testing for a duration metric, allow for a tiny offset to ensure a passing test in the presence of rounding/snapping issues.
#### Don't Rely on Alternatives
Alternative route discovery is a random feature in itself. The discovery of routes depends on the contraction order of roads and cannot be assumed successful, ever.
### Understanding Turn Restrictions
Adding turn restrictions requires the restriction to follow a very specific format.
We specify them in a table with the header `| type | way:from | way:to | node:via | restriction |`.
It is important that turn restrictions require micro segmentation.
The setting looks perfectly fine at first glance. However, it is not well defined.
The forbidden right turn could be either a superfluous addition, forbidding the turn `cb` to `be`, or actually refer to the turn `ab` to `bd` to say that a turn is forbidden here.
To model turn-restrictions correctly and unique, we need to split segments that contribute to the restriction into the smallest possible parts.
E.g. the above scenario could correctly be expressed as:
Unless this format is used, OSRM will omit the (then ambiguous) turn restrictions and ignore them.
## My Guidance Tests are Failing - Understanding what you can change
If you change some stuff in guidance, you will easily see tests change their result. E.g. if you change the angles for which we report `right`, then obviously some tests might not report a `direction modifier` named `right` anymore.
This small section will try to guide you in making the correct decisions for changing the behaviour of tests.
The difficulty in guidance tests is that not all items can be translated 1:1 from the ascii art into turn-angles.
The turn-angle calculation tries to find turn angles that would represent perceived turn angles, not the exact angle at the connection.
This is necessary, since connections in OSM are always bound by the paradigm that the way is supposed to be in the middle of the actual road.
For broad streets, you will see stronger angles than the actual turns.
### Don't change the test, change the expected behaviour
And the test reports `turn right` for the route `a->e`, where before it said `slight right`.
If you changed the turn angles, obviously you can expect changes in the distinction between `slight right` and `right`.
In such a case it is, of course, reasonable to change the expected route to report `right` instead of `slight right`. You should consider inspecting the actual turn angles at `b` to see if you feel that change is justified.
However, you should never adjust the test itself.
If you look at a failure, the other way around
```
Given a grid size of 5 m
Given the node map
"""
a - b - - - - - - c
\
d - - - - - e
"""
When I route I should get
| waypoints | route | turns |
| a,e | abc,bde,bde | depart,turn right,arrive|
```
where we see a `slight right`, over the expected `right`.
We could be tempted to adjust the grid size (e.g. from `10 m` to `20` meters).
Such a change would fundamentally alter the tests, though.
Since the part `b-d` is a short offset, when we are looking at a grid of size `5 m`, the angle calculation will try and compensate for this offset.
In this case we would see a very slight turn angle. If your change now reports different turn angles, you can of course change the expected result. But you should not adjust the grid size. The test would be testing turn angles of `180` and `100` degrees, instead of `180` and `160`.
### Consider Post-Processing Impacts
Some changes you might see could look completely unrelated. To understand the impact of your changes, you can make use of the debugging utilities you can finde in `util/debug.hpp` (and potentially other related headers).
If your test is inspecting a series of turns (remember, a turn not necessarily equals an instruction), you could see interaction with post-processing.
To see the unprocessed turns, you should print the steps at the end of step assembly (`assembleSteps` in `engine/guidance/assemble_steps.hpp`).
If you see unexpected changes, you can consider adding the `locations` field to your test to study what location a turn is reported at.
To study a test without post-processing impacts, you can create a copy of the case on a very large grid (like 2000 meters). In such a grid, `turn collapsing` would be essentially disable.
Sadly, there is no general guideline.
### Use Caution
If in doubt, ask another person. Inspect as much of the data as possible (e.g. print un-collapsed steps, turn angles and so on) and use your best judgement, if the new result seems justified.
message(STATUS"[Warning] FindTBB.cmake: The use of TBB_ARCHITECTURE and TBB_COMPILER is deprecated and may not be supported in future versions. Please set \$ENV{TBB_ARCH_PLATFORM} (using tbbvars.[bat|csh|sh]).")
# Jiri: It doesn't hurt to look in more places, so I store the hints from
# ENV{TBB_ARCH_PLATFORM} and the TBB_ARCHITECTURE and TBB_COMPILER
message(STATUS"[Warning] FindTBB.cmake: The use of TBB_ARCHITECTURE and TBB_COMPILER is deprecated and may not be supported in future versions. Please set \$ENV{TBB_ARCH_PLATFORM} (using tbbvars.[bat|csh|sh]).")
# Jiri: It doesn't hurt to look in more places, so I store the hints from
# ENV{TBB_ARCH_PLATFORM} and the TBB_ARCHITECTURE and TBB_COMPILER
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Michael Krasnyk
Patrick Niklaus
Daniel Patterson
karenzshea
Karen Shea
Huyen Chau Nguyen
Kushan Joshi
Kajari Ghosh
Mateusz Loskot
Alain ANDRE
Raphael Dumas
Marcel Radischat
Daniel J. Hofmann
Darafei Praliaskouski
Frédéric Rodrigo
Denis Koronchik
Minh Nguyễn
brian lewis
vng
Moritz Kobitzsch
Daniel J. H
David Audrain
Emil Tin
Jack Danger
Lev Dragunov
Patrick Niklaus
FILLAU Jean-Maxime
Pepijn Schoen
Harry Wood
Stepan Kuzmin
Johan Uhle
Frederik Ramm
Freenerd
MichalPP
Richard Fairhurst
Bhargav Chippada
wieringen
Emil Tin
yuryleb
Quinn Chrzan
Jonathon Rossi
Moritz Seemann
Mathias Gug
Jihyun Yu
Kajari
Dane Springmeyer
Alex Barth
Kerrick Staley
Dane Springmeyer
jakepruitt
jakepruitt
Lauren Budorick
Ansis Brammanis
Sandra Thieme
Gavin Sherry
Konstantin Shalnev
Konstantin Käfer
Surya Suluh
Aleksei Potov
Vladimir Kurchatkin
jperaltamalvar
bergwerkgis
Jeff Miccolis
Wilhelm Berg
