-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed order of generated edges and guidance turns #4706
Conversation
3f65550
to
e7efb5b
Compare
For Berlin extract instructions changed at locations (
Still has to check missing |
3c51d08
to
e509a7c
Compare
e509a7c
to
a9f2011
Compare
} | ||
|
||
return intersection; | ||
} | ||
|
||
private: | ||
mutable std::mutex lock; | ||
mutable std::unordered_map<TurnType::Enum, std::uint64_t> type_hist; | ||
mutable std::unordered_map<DirectionModifier::Enum, std::uint64_t> modifier_hist; | ||
mutable std::map<TurnType::Enum, std::uint64_t> type_hist; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a particular reason we need to preserve the insertion order here? Just curious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, map
preserves order, so it is easier to do line-by-line comparison with diff
} | ||
|
||
// Enforce ordering of outgoing edges | ||
std::sort(result.begin(), result.end()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sequence should be sorted by construction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it depends on GetAdjacentEdgeRange
implementation, but can add std::is_sorted
assertion in both places
2f00908
to
18b058d
Compare
@oxidase minor - can you add a CHANGELOG entry for this? It'll help when reviewing changes for the next release. |
b3c8a5d
to
2f47634
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few smaller clarifications needed, otherwise looks good. Thanks for this refactor! 👍
|
||
type_hist[type] += 1; | ||
modifier_hist[modifier] += 1; | ||
if (road.entry_allowed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
@@ -111,8 +113,7 @@ transformTurnLaneMapIntoArrays(const LaneDescriptionMap &turn_lane_map) | |||
// | |||
// turn lane offsets points into the locations of the turn_lane_masks array. We use a standard | |||
// adjacency array like structure to store the turn lane masks. | |||
std::vector<std::uint32_t> turn_lane_offsets(turn_lane_map.data.size() + | |||
2); // empty ID + sentinel | |||
std::vector<std::uint32_t> turn_lane_offsets(turn_lane_map.data.size() + 1); // + sentinel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know why it was + 2
before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably it is for empty ID
but an empty entry is already included into turn_lane_map.data
@@ -419,22 +421,43 @@ void EdgeBasedGraphFactory::GenerateEdgeExpandedEdges( | |||
|
|||
TurnDataExternalContainer turn_data_container; | |||
|
|||
// TODO: add a MergableRoadDetector instance, to be deleted later |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't fully understand this TODO
, there is an instance of this class a few lines below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is better to keep MergableRoadDetector
for now, but it also influences intersections connectivity via edges merging and creating U-turns
const auto &incoming_edges = intersection::getIncomingEdges( | ||
m_node_based_graph, node_at_center_of_intersection); | ||
const auto &outgoing_edges = intersection::getOutgoingEdges( | ||
m_node_based_graph, node_at_center_of_intersection); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
node_at_center_of_intersection
maybe we can use intersection_node
or something less verbose?
const auto &outgoing_edges = intersection::getOutgoingEdges( | ||
m_node_based_graph, node_at_center_of_intersection); | ||
const auto &edge_geometries_and_merged_edges = | ||
intersection::getIntersectionGeometries(m_node_based_graph, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this would be more concise using std::tie()
?
@@ -165,8 +170,9 @@ bool MergableRoadDetector::EdgeDataSupportsMerge( | |||
bool MergableRoadDetector::IsTrafficLoop(const NodeID intersection_node, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still needed? I thought we compress traffic lights now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it is needed to prevent merges of loops like https://www.openstreetmap.org/?mlat=43.6174&mlon=7.05839#map=19/43.61695/7.05820
|
||
for (const auto outgoing_edge : graph.GetAdjacentEdgeRange(intersection_node)) | ||
{ | ||
// TODO: to use TurnAnalysis all outgoing edges are required, to be uncommented later |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite understand yet how we could skip reversed
edges in the future. How will this be possible?
return true; | ||
|
||
// Allow U-turn if the incoming edge has a U-turn lane | ||
const auto &incoming_edge_annotation_id = graph.GetEdgeData(from.edge).annotation_data; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably discuss if using the presence of a uturn
lane is a good idea here, or if we should base this on country specific settings. Making the accessibility depend on turn lanes is just quite ugly.
In general, we should investigate how often this code path is even triggered - I have a feeling that most streets with a u-turn lane also have segregated ways for both directions (so it is not a "simple" uturn).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added a TODO line here, but i would keep it as it is now
using InputEdge = util::NodeBasedDynamicGraph::InputEdge; | ||
using Graph = util::NodeBasedDynamicGraph; | ||
|
||
BOOST_AUTO_TEST_CASE(simple_intersection_connectivity) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Good to see some unit tests for this code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙌
const guidance::TurnLanesIndexedArray &turn_lanes_data, | ||
const IntersectionEdge &incoming_edge); | ||
|
||
IntersectionEdge skipDegreeTwoNodes(const util::NodeBasedDynamicGraph &graph, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we keep the explanatory comments from
osrm-backend/include/extractor/guidance/intersection_generator.hpp
Lines 67 to 75 in 353829a
// Graph Compression cannot compress every setting. For example any barrier/traffic light cannot | |
// be compressed. As a result, a simple road of the form `a ----- b` might end up as having an | |
// intermediate intersection, if there is a traffic light in between. If we want to look farther | |
// down a road, finding the next actual decision requires the look at multiple intersections. | |
// Here we follow the road until we either reach a dead end or find the next intersection with | |
// more than a single next road. This function skips over degree two nodes to find coorect input | |
// for GetConnectedRoads. | |
OSRM_ATTR_WARN_UNUSED | |
IntersectionGenerationParameters SkipDegreeTwoNodes(const NodeID starting_node, |
road.edge = graph.GetTarget(next_edge) == road.node ? next_edge + 1 : next_edge; | ||
road.node = next_node; | ||
next_node = graph.GetTarget(road.edge); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we lost a CanBeCompressed()
check from
if (!CanBeCompressed(node_based_graph.GetEdgeData(query_edge), |
Do we not need this check anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check always returns true because of an assignment query_edge = next_edge;
one line above and it was a comparison of two identical data structures.
80ae5c5
to
09585e0
Compare
Checked modified instruction in SF https://gist.github.com/oxidase/f0492bd6ffff80a7f24a91a2f07a4602 Also ce17c78 changes |
09585e0
to
9d2e57a
Compare
@oxidase heads up I rebased this on master for a pre-release. |
52c0293
to
97f29d7
Compare
@TheMarex @daniel-j-h 5.14.3 release fixes assertions |
For intersection at https://www.openstreetmap.org/node/65299217 `are_parallel` in MergableRoadDetector::HaveSameDirection is false for South Van Ness Avenue with 150 meters
a2140c2
to
154ceb1
Compare
The commit 154ceb1 changes turn instructions at places on the diff map http://geojson.io/#id=gist:oxidase/221b0b27779fbb5ca662a35d699708bc&map=12/37.8198/-122.3956 |
154ceb1
to
d8185eb
Compare
Issue
This step is required before implementation of #4674
The order of edges is fixed by the order of node-based graph nodes and adjacent intersection edges
incoming_edges
andoutgoing_edges
and the implicit intersection connectivity matrix that is specified by a free functionisTurnAllowed
.Tasklist
Requirements / Relations
Blocks #4674