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.
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
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
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
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
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 |
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.
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 '.'
