-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Split EBG and guidance pipelines in EBGF #4674
Conversation
d72c8e1
to
e28c37e
Compare
40344a0
to
e874f65
Compare
@ghoshkaj pushed the current branch state that is working, but almost stuck with the third point
will prevent running this line of code
and EBG will miss a U-turn edge. Ideally intersections shape and connectivity must be analyzed before edges and turns generation, but atm intersection views can be mutated by the turn and lanes handlers during the generation phase. This makes the splitting of code extremely fragile with respect to indexing turns and consequences of the incorrect indexing can be visible only in post-processing. The drawback of this PR without intersection connectivity pre-analysis is in increasing EBGF processing time without any facilitation in solving current open issues, like multiple via-way restrictions or U-turns penalization in segregated intersections. |
a2872db
to
b5390a4
Compare
a83bfa3
to
16dde94
Compare
16dde94
to
853d4b3
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.
Looks good to me, I just have some minor comments and nitpicks. 👍
@@ -70,7 +70,7 @@ inline LegGeometry assembleGeometry(const datafacade::BaseDataFacade &facade, | |||
cumulative_distance += current_distance; | |||
|
|||
// all changes to this check have to be matched with assemble_steps | |||
if (path_point.turn_instruction.type != extractor::guidance::TurnType::NoTurn) | |||
if (path_point.turn_instruction.type != osrm::guidance::TurnType::NoTurn) |
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.
Hrm this should not need a global namespace prefix.
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.
using guidance::TurnType
leads to an error "engine::guidance::TurnType
is undefined type". To avoid ambiguity osrm::guidance::TurnType
must be used here.
m_node_based_graph.GetOutDegree(intersection_node), | ||
turn.instruction.IsUTurn(), | ||
guidance::getTurnDirection(turn_angle) == guidance::DirectionModifier::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.
Does this also match sharp turns or really just the 180 deg turns?
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 0 (360) degrees turns.
buffer->nodes_processed = | ||
intersection_node_range.end() - intersection_node_range.begin(); | ||
|
||
// If we get fed a 0-length range for some reason, we can just return right away |
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.
Why could this be removed? Was it superfluous?
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, intersection_node_range
size will also be checked in the for loop pre-condition below
|
||
// Copy data from local buffers into global EBG data | ||
std::for_each( | ||
buffer->continuous_data.begin(), buffer->continuous_data.end(), transfer_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.
Is there a reason why the transfer_data
lambda is not inlined here?
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.
transfer_data
is used in two places to copy buffer->continuous_data
and delayed_data
const std::vector<TurnRestriction> &turn_restrictions, | ||
const std::vector<ConditionalTurnRestriction> &conditional_turn_restrictions, | ||
const util::NameTable &name_table, | ||
LaneDescriptionMap lane_description_map, |
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 passed on purpose by value?
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, lane_description_map
is modified by the turn lane handler. Before lane_description_map
was a non-const reference, now it is moved into the function scope, modified and serialized in ProcessGuidanceTurns
@@ -112,9 +114,6 @@ void checkWeightsConsistency( | |||
extractor::EdgeBasedNodeDataContainer node_data; | |||
extractor::files::readNodeData(config.GetPath(".osrm.ebg_nodes"), node_data); | |||
|
|||
extractor::TurnDataContainer turn_data; | |||
extractor::files::readTurnData(config.GetPath(".osrm.edges"), turn_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.
Oh nice where is this simplification coming from?
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 a left over from some other refactoring step. turn_data
is loaded, but not used
src/guidance/guidance_processing.cpp
Outdated
namespace guidance | ||
{ | ||
|
||
void processGuidanceTurns(const util::NodeBasedDynamicGraph &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.
Nitpick on naming here: What we are doing is annotation the turn with guidance information, so for example something like guidance::annotateTurns
might be sufficient as a name.
Vector<guidance::TurnInstruction> turn_instructions; | ||
Vector<LaneDataID> lane_data_ids; | ||
Vector<EntryClassID> entry_class_ids; | ||
Vector<util::guidance::TurnBearing> pre_turn_bearings; |
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 nitpick: We should probably move TurnBearing
to the guidance
module/namespace.
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.
moved to include/guidance/turn_bearing.hpp
fe0215e
to
f5fa343
Compare
6c6323f
to
1cbfb43
Compare
3d9d1aa
to
68a500f
Compare
68a500f
to
9bf892f
Compare
Intersection analysis occupy in osrm::extractor::intersection namespace and guidance code osrm::guidance
9bf892f
to
2dc70a3
Compare
Issue
The PR is the implementation of #4664.
Tasklist
processor_stage
generate_edge
generate_edge
Requirements / Relations
Link any requirements here. Other pull requests this PR is based on?