Skip to content
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

Merged
merged 9 commits into from
Feb 2, 2018
Merged

Conversation

oxidase
Copy link
Contributor

@oxidase oxidase commented Nov 9, 2017

Issue

The PR is the implementation of #4664.

Tasklist

  • Split intersection shape generation stage from processor_stage
  • Duplicate EBG and guidance stage in one pipeline
  • Cleanup the EBG stage of guidance code, use only EBG-related processing of generate_edge
  • Cleanup the guidance stage of EBG code, use only guidance-related processing of generate_edge
  • Split EBG and guidance into two pipelines with duplicated intersection shape generation Check if needed in this PR
  • check regression / cucumber cases (see docs/testing.md)
  • review
  • adjust for comments

Requirements / Relations

Link any requirements here. Other pull requests this PR is based on?

@oxidase oxidase changed the title Refactor/ebgf guidance Split EDG and guidance pipelines in EBGF Nov 9, 2017
@ghoshkaj ghoshkaj self-assigned this Nov 9, 2017
@ghoshkaj ghoshkaj changed the title Split EDG and guidance pipelines in EBGF Split EBG and guidance pipelines in EBGF Nov 10, 2017
@ghoshkaj ghoshkaj force-pushed the refactor/ebgf-guidance branch 3 times, most recently from d72c8e1 to e28c37e Compare November 10, 2017 19:55
@oxidase oxidase force-pushed the refactor/ebgf-guidance branch 3 times, most recently from 40344a0 to e874f65 Compare November 16, 2017 15:32
@oxidase
Copy link
Contributor Author

oxidase commented Nov 16, 2017

@ghoshkaj pushed the current branch state that is working, but almost stuck with the third point Cleanup the EBG stage of guidance code, use only EBG-related processing of generate_edge because it is nearly impossible in the current implementation. The problem is that turn and lane analysis code influences intersection connectivity, eg, removing

turn_lane_handler.assignTurnLanes(incoming_edge, std::move(intersection));

will prevent running this line of code
intersection[u_turn].entry_allowed = true;

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.

@oxidase oxidase force-pushed the refactor/ebgf-guidance branch 5 times, most recently from a2872db to b5390a4 Compare December 7, 2017 15:25
@oxidase oxidase force-pushed the refactor/ebgf-guidance branch 5 times, most recently from a83bfa3 to 16dde94 Compare January 10, 2018 21:30
Copy link
Member

@TheMarex TheMarex left a 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)
Copy link
Member

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.

Copy link
Contributor Author

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,
Copy link
Member

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?

Copy link
Contributor Author

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
Copy link
Member

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?

Copy link
Contributor Author

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);
Copy link
Member

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?

Copy link
Contributor Author

@oxidase oxidase Jan 16, 2018

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,
Copy link
Member

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?

Copy link
Contributor Author

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);
Copy link
Member

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?

Copy link
Contributor Author

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

namespace guidance
{

void processGuidanceTurns(const util::NodeBasedDynamicGraph &node_based_graph,
Copy link
Member

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;
Copy link
Member

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.

Copy link
Contributor Author

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

@oxidase oxidase merged commit 9e93f19 into master Feb 2, 2018
@chaupow chaupow added this to the 5.16.0 milestone Feb 5, 2018
@DennisOSRM DennisOSRM deleted the refactor/ebgf-guidance branch November 6, 2022 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants