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
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
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.
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
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
* 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.
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.".
This increses query performance dramatically for queries with a lot of
coordinates. However it increases the internal memory usage of the
StaticRTree also 4x.
StaticRTree now uses projected coordinates internally. That means we can
use a euclidean distance measure (squared distance) for sorting the
query queue.
Small fixes I didn't want to include in unrelated PRs.
There are a few left in `storage.cpp` but since it's a single function
in 600 lines of code, I didn't want to touch the mess. The others are
safe to remove, cucumber and test run on Finland gives 👍.
rather than being cached in the StaticRTree. This means we
can freely apply traffic data and not have stale values lying
around. It reduces the size of the RTree on disk, at the expense
of some additional data in RAM.
Phew, a lot of classes were affected by this. The rationale for the
changes are as follows:
- When a type X declares any constructor, the default constructor is
not declared, so there is no need for X() = delete there. In fact,
there is brutal difference between those two: deleted members
participate in overload resolution, but not-declared members do not!
- When a type X wants to be non-copyable (e.g. to be only movable, like
threads, unique_ptrs, and so on), you can either do it by inheriting
from boost::noncopyable (the old way), or better declare both (!) the
copy constructor _and_ the copy assignment operator as deleted:
X(X const&) = delete;
X& operator=(X const&) = delete;
We had tons of types with deleted copy constructors that were lacking
a corresponding deleted copy assignment operator, making them still
copyable and you wouldn't even notice (read: scary)!
References:
- http://accu.org/content/conf2014/Howard_Hinnant_Accu_2014.pdf
- http://www.boost.org/doc/libs/master/libs/core/doc/html/core/noncopyable.html
Note: I know, I'm quoting Hinnant's extraordinary slides a lot, but
getting the sematic right here is so incredibly important.
`pow(2, 16)` is not `2 << 16` but rather `1 << 16`.
With this change we cut memory usage in half for the XORFastHash's two
tables. Adapts XORFastHashStorage, memory usage reduction by factor two.
- Throwing an assertion exception for proper stack unwinding, making
sure destructors are called
- On in Debug mode, in Release, enable via:
cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_ASSERTIONS=ON
Current problem that I'm seeing is that some code is not catching
exceptions or worse silently swallowing them. Would like to check the
whole pipeline before merging this in.
Fixes issue #1864. Given the simple set-up:
a --> b --> c
^-----------|
This would translate into an edge based graph (ab) -> (bc),
(bc) -> (ca), (ca) -> (ab).
Starting at the end of the one-way street (ab) and going to
the beginning, the query has to find a self-loop within the
graph (ab) -> (bc) -> (ca) -> (ab), as both nodes map to the
same segment (ab).
Found with
```
daniel@x1c /t/o/i/util> for header in *.hpp
echo -n $header:
ag -iQ $header ../../ --noheading | wc -l
end
...
fixed_point_number.hpp:0
range_algorithms.hpp:0
...
```
Only two. Surprises me to be honest.
But we're cleaning up for quite a bit now.
When you mark free standing functions as `static inline` instead
of just `inline` they can not get merged across TUs and therefore
produce code bloat which is bad for the binaries size, the CPUs
instruction cache, and so on.
Please also see the discussion at:
- https://groups.google.com/forum/#!topic/mozilla.dev.platform/Ulw9HoZbSyQ
- http://stackoverflow.com/a/12836392
Note that non-fully specialized templates (i.e. with a kind of at
least `Template :: * -> *`) are `inline` by default.
