matsim-eth / discrete-mode-choice Goto Github PK

If the transit route is anything else (i.e. generic route) in the simulation, the default estimator will fail.

Hi soel,

I download the package and follow the instruction in the gettingstarted.md but when i add the DiscreteModeChoiceModule inside the config_default.xml and run it then it report this error.
No implementation for org.matsim.core.replanning.PlanStrategy annotated with @com.google.inject.name.Named(value=DiscreteModeChoice) was bound.
at org.matsim.core.replanning.StrategyManagerModule.install(StrategyManagerModule.java:87) (via modules: com.google.inject.util.Modules$CombinedModule

I try both way
1st: add it through controler.addOveridingModule then using a helper from modechoie
2nd: add it through config by using DiscreteModeChoiceConfigGroup

THey both have the same error.

Include household constraints / hierarchichal choice process

The transit routing is sorting the departures right now. However, only the "closest" one to a certain is needed, hence not the whole array needs to be sorted ...

... in DscireteModeChoiceAlgorithm, list should be one element larger.

However, sometimes this is true or false. Especially look at PlanBuilder from the test package where it is expected in the true/false form. We should find some consistency here.

The thread-safe Dijkstra is closeable now. Probably this should be used in a ShutdownListener or something like that!

Currently, we have a problem when the trips are constructed from a list of elements and one of the activities only has a maximum duration. If the leg has NaN travel time, the departure time of the trip will become NaN as well, causing problems with routing.

To test:

• Set up a test case with a maximum duration activity
• Assert that the departure time of the resulting trips is not NaN

While I agree that other strategies do not make much sense, I would argue that ReRoute should still be allowed in combination with DCM.

• Make HomeFinder configurable
• Add a NullHomeFinder

Include the code from raphaeha for intermodal trips

We need a versatile infrastructure for tracking predictions of certain choice dimensions and the actual observed values in the simulation. For TRB 2018, we did something like that to compare the car travel times that go into the choice model for each trip vs. the car travel times that were observed in the simulation for the trips where the car mode had been chosen.

We need:

• Something like a PredictionRecorder that is flexible enough to record multiple choice dimensions (for a first version, only double would probably be fine). It should provide methods to obtain a value by getValue(Id<Person> personId, int tripIndex).
• Something like a ObservationRecorder, which, in essence, is just a MATSim EventListener. However, it must provide something like Optional<Double> getValue(Id<Person> personId, int tripIndex); to determine if a value is even present (maybe the mode has not been chosen) and, if so, provide the observation.
• Some code that runs of the end of the iteration to stitch together both parts and create, for instance, a CSV file with person_id trip_id estimation observation. Later on, we can push this even further to automatically create a plot that quantifies the offset or something similar.

@ctchervenkov already has come code for that and maybe could take over the issue? :)

Currently, FilterModule is not added to Guice in ModelModule.

Further decouple the code from MATSim and provide a solely text-based or database-based interface

Remove all the old stuff and take v2 as the default version

Add functionality for frozen randomness

Currently, we have two ModeAvailability implementations: DefaultModeAvailability and CarModeAvailability. I would propose that this is unified into DefaultModeAvailability, which gets two additional flags through the config file:

• considerLicense
• considerCarAvailability

Maybe then we could add a more flexible ModeAvailability where the use of modes can be controlled by config groups (and maybe person attributes).

I think the acitivty-based tour finder leads to problems later in the constraints (Subtour especially) if there are open acitvity chains (i.e. no starting/ending at the same spot). Check that.

in names.size() == 0

In MATSim 12, MainModeIdentifier is only used for reading plans. There is now a TripStructureUtils.getRoutingMode, which retrieves the "routing mode" from any leg in a plan. This routing mode references the originating RoutingModule of the TripRouter. Whenever MainModeIdentifier is used in the MATSim 12 version of DMC, we should now use this routing mode instead of relying on the MainModeIdentifier.

Add documentation (base it on the TRB Paper)