Refactoring of GoalDefinition and DrivingCorridorGeneration

[juloberno]

Problem: Driving corridor generation depends on goal definition which is problematic if goal is on other lane, for instance desired in merging scenario

-> better concept needed based on which information local map is generated

TODO: seperate routing and real evaluator goal definition

[klemense1]

Current Implement of Driving Corridor: Driving Corridor is checked to be updated at every world step, if the vehicle changes the lane. A driving corridor is then calculated, which may end in the lane parallel to the goal polygon.

[klemense1]

linked to #167

[patrickhart]

Might be inefficient to compute the driving corridor in every step?

[klemense1]

My proposal:

• New Lane Class (seperate to XODR Definition)
  • polygon get's precomputed
  • center line
  • right line, left line AND its flipped versions if we drive on the lane in the reverse order
• New Road Class (seperate to XODR Definition)
  • Routing is done on road-basis
  • contains lanes
  • I would keep the lane routing so planner's can use it

I think the notion of a driving corridor still makes sense (for example in the context of map-based prediction). however, we should not always (in every world step) compute it, especially not the horizon-dc, which we mostly use for visualization (and could throw away).

[patrickhart]

223