Encapsulate modifiying plans in router

[paulheinr]

For now, there are things done in the simulation, that are only relevant in case of routing.

E.g.:

• Extending Plan::get_full_plan_for_routing should be part of the router. src/simulation/messaging/messages.rs:430
• Updating Walking legs src/simulation/simulation.rs:119

Both should be part of the router module. Especially extending/modifiying the plan should be done on the fly during the simulation.

Also, interaction activities should get correct coordinates.

[Janekdererste]

In the end this should include the following:

• Plans are read in as is
• If ad-hoc routing is enabled the router-module is queried after each wakeup from activity_q
• The router should look a the activity which just finished
  • In case of a main activity: Remove the entire trip (simple leg, or leg/interaction activity chain) and plan a new route
  • In case of an interaction activity don't do anything (This enables the option of having more ad-routing while the agent is on route already later. For now, following through with the plan which was created once is fine)
• The router module should have all information it needs for routing encapsulated. This includes a suitable representation of the network. Since we have a network representation which can be passed into the KIT-Router anyway I would rather have this one with more features instead of storing stuff in the simulation network. This is important because if the Router-Module is self sufficient we will be more flexible in case we want to re-design things.

[Janekdererste]

I will start on this, because it feels like there is too much clutter in the simulation to proceed.

[Janekdererste]

@paulheinr could you please tell me why you decided to pass a Router trait to the simulation instead of the plain object? At the moment it looks like we only have a single type of Router. This feels like a premature abstraction.

[paulheinr]

I will start on this, because it feels like there is too much clutter in the simulation to proceed.

Yeah, I'm afraid you're right. I'm sorry that I haven't thought about encapsulating that before...

@paulheinr could you please tell me why you decided to pass a Router trait to the simulation instead of the plain object? At the moment it looks like we only have a single type of Router. This feels like a premature abstraction.

I think it makes sense to apply IOC to every component, that is plugged into the simulation. Even if this kind of abstraction is premature, in the long term we need a trait either way, don't we? As a near outlook after finishing my thesis, I thought about using another routing algorithm of KIT's rust road router. Therefore, a trait would be beneficial.

[Janekdererste]

As a near outlook after finishing my thesis, I thought about using another routing algorithm of KIT's rust road router. Therefore, a trait would be beneficial.

Thanks that makes sense. We'll keep the interface then.

[paulheinr]

Already done by implementing Replanner trait