osrm-backend/include/engine/guidance/post_processing.hpp

67 lines
3.1 KiB
C++
Raw Normal View History

2016-02-24 04:29:23 -05:00
#ifndef ENGINE_GUIDANCE_POST_PROCESSING_HPP
#define ENGINE_GUIDANCE_POST_PROCESSING_HPP
#include "engine/guidance/leg_geometry.hpp"
2016-05-27 15:05:04 -04:00
#include "engine/guidance/route_step.hpp"
#include "engine/phantom_node.hpp"
2016-02-24 04:29:23 -05:00
#include <vector>
namespace osrm
{
namespace engine
{
namespace guidance
{
// passed as none-reference to modify in-place and move out again
std::vector<RouteStep> postProcess(std::vector<RouteStep> steps);
2016-02-24 04:29:23 -05:00
// Multiple possible reasons can result in unnecessary/confusing instructions
// A prime example would be a segregated intersection. Turning around at this
// intersection would result in two instructions to turn left.
// Collapsing such turns into a single turn instruction, we give a clearer
// set of instructionst that is not cluttered by unnecessary turns/name changes.
std::vector<RouteStep> collapseTurns(std::vector<RouteStep> steps);
2016-03-29 07:45:48 -04:00
// trim initial/final segment of very short length.
// This function uses in/out parameter passing to modify both steps and geometry in place.
// We use this method since both steps and geometry are closely coupled logically but
// are not coupled in the same way in the background. To avoid the additional overhead
// of introducing intermediate structions, we resolve to the in/out scheme at this point.
void trimShortSegments(std::vector<RouteStep> &steps, LegGeometry &geometry);
// assign relative locations to depart/arrive instructions
std::vector<RouteStep> assignRelativeLocations(std::vector<RouteStep> steps,
const LegGeometry &geometry,
const PhantomNode &source_node,
const PhantomNode &target_node);
2016-05-30 11:42:28 -04:00
// collapse suppressed instructions remaining into intersections array
std::vector<RouteStep> buildIntersections(std::vector<RouteStep> steps);
2016-05-27 15:05:04 -04:00
// remove steps invalidated by post-processing
std::vector<RouteStep> removeNoTurnInstructions(std::vector<RouteStep> steps);
// remove use lane information that is not actually a turn. For post-processing, we need to
// associate lanes with every turn. Some of these use-lane instructions are not required after lane
// anticipation anymore. This function removes all use lane instructions that are not actually used
// anymore since all lanes going straight are used anyhow.
// FIXME this is currently only a heuristic. We need knowledge on which lanes actually might become
// turn lanes. If a straight lane becomes a turn lane, this might be something to consider. Right
// now we bet on lane-anticipation to catch this.
std::vector<RouteStep> collapseUseLane(std::vector<RouteStep> steps);
// postProcess will break the connection between the leg geometry
// for which a segment is supposed to represent exactly the coordinates
// between routing maneuvers and the route steps itself.
// If required, we can get both in sync again using this function.
// Move in LegGeometry for modification in place.
LegGeometry resyncGeometry(LegGeometry leg_geometry, const std::vector<RouteStep> &steps);
2016-02-24 04:29:23 -05:00
} // namespace guidance
} // namespace engine
} // namespace osrm
#endif // ENGINE_GUIDANCE_POST_PROCESSING_HPP