eqasim-org / eqasim-java

The eqasim framework features an integrated transport simulation environment. It is based on the agent-based transport simulation framework MATSim with added components for simulation of discrete choice models.

eqasim-java

The eqasim package is a collection of ready-to-run high-quality scenarios for the agent- and activity-based transport simulation framework MATSim. This repository contains the Java parts of the project which extend MATSim and provide functionality to generate the simulation data.

Therefore, this repository has two functions: First, to provide the code to run eqasim simulations (and extend them), second, to act as a dependency for the various pipelines that generate runnable MATSim scenarios from raw data sets, such as for:

• Île-de-France and Paris
• California
• Sao Paulo

To understand how to set up a simulation and run it, please refer to the respective repositories.

Additional topics:

• How to cut out smaller parts of existing simulations.
• How to run a simulation with on-demand mobility services (as a main mode and as a transit feeder).
• How to run the discrete mode choice model as a standalone

Main reference

The main research reference for the eqasim-java framework:

Hörl, S. and M. Balac (2021) Introducing the eqasim pipeline: From raw data to agent-based transport simulation, Procedia Computer Science, 184, 712-719.

Versioning and Packging

The current version of eqasim is 1.5.0 and is based on MATSim 15.0. You can access it through the v1.5.0 tag. The develop branch is kept at version 1.5.0 until the next release is prepared, but may include additional developments since the last release.

The code is available as a Maven package. To use it, add the following repository to your pom.xml:

<repository>
    <id>eqasim</id>
    <url>https://packagecloud.io/eth-ivt/eqasim/maven2</url>
</repository>

Afterwards, you can add various sub-packages to your project:

<dependency>
    <groupId>org.eqasim</groupId>
    <artifactId>core</artifactId>
    <version>1.5.0</version>
</dependency>

Besides the latest release based on MATSim 15.0, legacy versions 1.3.1, 1.2.1, 1.2.0, 1.0.6, and 1.0.5 are also available through packagecloud.

Upstream branch

To keep scenario-based repositories up-to-date (for instance, ile-de-france), we provide the upstream branch, which contains a well-defined develop version of eqasim-java and is used in the develop version of the dependent repository. While this is useful for development purposes, their versioned releases will always depend on versioned releases of eqasim-java.

eqasim-java's Issues

Issue with output CSV in cross validation with input data

Dear @sebhoerl @balacmi I am trying to run the Quebec scenario using version 1.3.1 eqasim , with my computed DCM parameter in biogeme , but with this version when I compare the matsim results output CSV with my OD survey the results are way off . And also the mode share shoes in the analysis notebook is not aligned with mode share with mode stat PNG , could it be some issue with covering matsim results in the output CSV?

config = https://drive.google.com/file/d/1yYgSX43vn5S-5rN-L1z7gRRnjX-KiByX/view?usp=sharing

activity chain analysis notebook = https://drive.google.com/file/d/1lD1x8JXa2JpiU0-_GuwB06s0B6e5zm7u/view?usp=sharing
I attached the config that I am using as well as results ,
Cheers ,
Sara

![modestats](

https://user-images.githubusercontent.com/61546453/195116682-70ccc784-8349-46ae-aeb3-202c60b81923.png)

as I checked my synthesis population with od_survey they are look ok before by simulation but why after simulation the distance-activities distribution are changed ...

syspop_analysis code = https://drive.google.com/file/d/1JVaqwsqjqPNGNniT_3V5SQ91O_NNQ85G/view?usp=sharing

adding spatial attributes to activity in the population file ,

Dear All,
I am trying to add my estimated spatial variable for each origin and destination coordinates of activity , I tried to customize matsim.writer and matsim population to add this urban variable ,

here is the final structure ,

I also attached the writer and population codes ,
but while I run simulation in eqasim I got this error

org.xml.sax.SAXParseException; lineNumber: 66; columnNumber: 12; The content of element type "plan" must match "(attributes?,(activity|leg)*)".

could you guide me with this issue
population.zip

Matching of activity links

Currently, we simply match activities with the road network. However, we can quite easily perform a better assignment by removing highways and other restricted access ways using OSM attributes.

Problem using RunScenarioCutter to cut the scenario

Hello, I successfully used the ile_de_france jar file from the eqasim repo to cut a MATSim scenario, following the documentation.

Now, I'm considering if it's feasible to use this tool for scenarios outside of switzerland or ile_de_france, which could significantly enhance the efficiency of our simulations.

I intend to test the scenario cutter using a small, open-source simulation project named Londinium on GitHub. Here are the MATSim config and population files I used for testing.

I'm curious whether the cutter requires specific MATSim configuration settings and plan inputs to be compatible. An error I encountered while cutting the test scenario suggested that each activity in the plans.xml might need an associated facility:

2023-10-31T15:34:33,149 ERROR ScenarioValidator:66 Person agent_99 has park activity without facility
2023-10-31T15:34:33,149 ERROR ScenarioValidator:66 Person agent_99 has shop activity without facility
2023-10-31T15:34:33,150 ERROR ScenarioValidator:66 Person agent_99 has home activity without facility
Exception in thread "main" java.lang.IllegalStateException: Found errors while checking population
        at org.eqasim.core.scenario.validation.ScenarioValidator.checkScenario(ScenarioValidator.java:196)
        at org.eqasim.core.scenario.cutter.RunScenarioCutter.main(RunScenarioCutter.java:84)

Here's an example activity from the test plan.xml:

    </attributes>
    <plan selected="yes">
      <activity type="home" x="528634.2579046559" y="176896.66392752415" end_time="07:58:00"/>
      <leg mode="car" trav_time="00:25:00"/>

Does it require the addition of a facility to the activity plan, like so?

      <activity type="home" facility="home_hh_0" x="528634.2579046559" y="176896.66392752415" end_time="07:58:00"/>

---

I also wonder if specific MATSim configuration settings, such as the qsim mobility module, are necessary for compatibility with the cutter.

When I tried to comment out the validating statement in the core/src/main/java/org/eqasim/core/scenario/validation/ScenarioValidator.java, I met another error:

2024-02-01T17:48:34,359  INFO Injector:94   ==full==> ConstructorBinding{key=Key[type=org.matsim.core.trafficmonitoring.TravelTimeCalculator, annotation=[none]], source=org.matsim.core.trafficmonitoring.TravelTimeCalculatorModule.install(TravelTimeCalculatorModule.java:87), scope=Scopes.SINGLETON}
2024-02-01T17:48:34,359  INFO Injector:96 
2024-02-01T17:48:34,359  INFO Injector:99 === printInjector end ===
2024-02-01T17:48:34,368  INFO ParallelProgress:26 Cutting population ... 0/100 (0.00%)
com.google.inject.ProvisionException: Unable to provision, see the following errors:

1) [Guice/ErrorInCustomProvider]: IllegalStateException: Cutter does not support teleportedModeFreespeedFactor yet!
  at PopulationCutterModule.provideModeAwareTripProcessor(PopulationCutterModule.java:120)
      \_ installed by: Modules$CombinedModule -> Modules$CombinedModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> AbstractModule$4 -> Modules$OverrideModule -> PopulationCutterModule
  while locating ModeAwareTripProcessor
  at PlanCutter.<init>(PlanCutter.java:25)
      \_ for 1st parameter
  while locating PlanCutter

Learn more:
  https://github.com/google/guice/wiki/ERROR_IN_CUSTOM_PROVIDER

1 error

It seems like it doesn't like some matsim config setting.

Could you please advise on any required modifications to the MATSim configuration and plans for successful testing scenario cutting?

Many thanks for your help in advance.

Clean up of packages

• The examples package is not needed anymore. All unit tests that historically were in this package have been moved elsewhere, except for vdf, which we can simply do now.
• Remove the gis package, it only contains files that nobody uses I think

Bug: Wrong ordering of events in EqasimTransitEngine

In rare circumstances it can happen that two PublicTransitEvent are sent in the same time step, but their actual double time of the previous one is later than the second one. This happens, because the events that we sent with processEvent to the event manager are based on the exactly calculated arrival time of the agent (which does not need to be in full seconds). Hence, we should send events in doSimStep which are actually using the variable time instead of the precomputed arrival time.

Comparing trips from plans and events

Something that came up while looking at #82: In the simulation (and the events) activities take place at links. However, the plan-based analysis currently calculates Euclidean distances of the trips not based on the links, but on the coordinates written in the facilities / in the plans. We should switch to link information to make this more consistent.

Improve analysis

• Make more modular (to add additional modes etc)
• Make more fine-grained (inlcuding legs for access/egress if we look at first/last mile)

Consolidate scenarios / minimize code duplication for choice models

A lot of the choice model code is duplicated across the scenarios. There are some options to go forward:

• Remove different city projects altogether and have one general eqasim RunSimulation that works on all scenarios (with custom parameters, settings, etc.)
• Keep the city projects but maybe move the general "does it all" choice model into a separate project

The reason is that I would, for instance, now like to use the ASTRA Zurich choice model for Paris, but it is not so easy, because there is a lot of implementational overhead. Whether to remove the city projects depends a bit pn how individual all the code around the choice model is (but I think there are not many individual components).

Use events for network cutting

Currently, the cutting times (along a network route) are determined by free-flow speeds. We take the departure time of the trip and then traverse the links to find the time at which the link going in or out of the cutting area is traversed. Clearly, this can skew the cutting point, especially for long trajectories.

It would be good to have a three options, from less to most detailed:

• Cut according to free speeds (status quo)
• Cut according to recorded travel times (better, but bound to time bins)
• Cut according to the actual EnterLinkEvent time

The recorded case can be built easily, all the classes are available (RecordedTravelTime). The event-based case needs some implementation (basically tracking all the relevant events and then using them in the cutter).

Switch to car access egress

Since MATSim 12 it is possible (and now default) to have walk access and egress for car trips, we should switch to that behavior now (requires adjusting the utility estimators).

Adding motorcycles

Hello !
I am trying to add motorcycles to Eqasim..

I'm almost there :

I generate the vehicle fleet in the pipeline
I get a "motocycleAvailability" in the population
I added Motorcyles classes (Estimator, CostModel, Variable, Predictor, etc.)
I added "motorcyle" in the right places in the config file.
the last thing I'm struggling with is making the motorcycle legs appear in the events file. The motorcycle trips are evaluated in the the DMC replanning part and the routes are in the population file but it looks like the trips don't enter the actual QSim part ... And the issue is that they don't have any "vehicles" attached to it.

at some point I add these line to provide a TripRouter for Motorcycle :

controller.addOverridingModule(new AbstractModule() {
	@Override
	public void install() {
		addRoutingModuleBinding("motorcycle").toProvider(new NetworkRoutingProvider("motorcycle"));
	}
});

But I have the feeling it is not enough for the QSim part to kick in...

Do you have any clues ?

Clean up routing tools

With #217 we will have a very convenient and clean way of routing things. This means we can remove the command line tools in core now. Before, we should have some proper instructions on how to use the routing server. And it probably makes sense to still have a standalone command line script in the server package if needed (which then digests requests in JSON format as they would be sent to the server).

Code adjustments from recent projects

• Pull in code changes from the project/astra16 branch
• Pull in code changes fro mthe projects/paris-trb branch

Increase extensibility of parameters

Previously at eqasim-org/ile-de-france#77, but in the wrong repository. Working on it.

Currently, we have

IDFModeParameters parameters = IDFModeParameters.buildDefault();

However, to make it easier to extend this and reuse standard parameters, we should have something like

IDFWithDrtModeParameters parameters = new IDFWithDrtModeParameters();
IDFModeParameters.applyDefault(parameters);
IDFWithDrtModeParameters.applyDefault(parmeters);

i.e., instead of creating a new option, just apply the parameter values to the object.

Replace custom PT simulation by SBB simulation

• Wait until we did update to MATSim 12
• Remove our custom transit engine
• Use now-default MATSim engine
• Compare results and runtime

Add maven repository

Create a Maven repository so that eqasim can be used as a library elsewhere.

Enable DRT analysis for prebooking

After #185 we have a nice set of DRT analysis classes in core.
After #178 they will need to be updated to be compatible with the new prebooking-enabled event sequence (PassengerWaitingEvent)

Towards MATSim 12

Prepare repository

• Create branch with MATSim 12 (weekly snapshot)
• Fix resulting code problems (OptionalTime, etc.)

Compare results

• Run old version of ASTRA Zurich
• Run new version of ASTRA Zurich (with MATSim 12)
• Compare results
• Fix, if there are any deviations

Public transport simulation

• Run ASTRA Zurich as usual
• Run ASTRA Zurich without our PT simulator, but with SwissRail simulator
• Compare results
• Fix problems and remove our simulator if it makes sense

Cleanup

• Remove location assignment
• Check what UniversalTourFinder does differently than the standard DMC one
• ModularUtilityEstimator -> ModalUtilityEstimator

Remove Location Assignment

Location assignment is now a part of the pipeline (Python) code. Eventually, we should remove this component from here as the implementation there is more stable and easier to maintain.

Improve and disentangle caching

With Tarek we found a couple of issues with caching of trips in eqasim. The problem starts with the fact that we have three caches that can be simplified:

• There is the AbstractTripRouterEstimator, which has the notion of "prerouted" modes. Whenever a trip is estimated that has already been routed with the same departure time, it is not routed again. This is nice, but not used. The list of preroutedModes is empty by default and hardcoded. This one should be activated and currently I'm working on integrating the following paper at that point in code:

Tchervenkov, C., Hörl, S., Balac, M., Dubernet, T., Axhausen, K.W., 2020. An improved replanning strategy for congested traffic conditions in MATSim. Procedia Computer Science, The 11th International Conference on Ambient Systems, Networks and Technologies (ANT) / The 3rd International Conference on Emerging Data and Industry 4.0 (EDI40) / Affiliated Workshops 170, 779–784. https://doi.org/10.1016/j.procs.2020.03.156

• There is the CachedTripEstimator, which follows almost the same pattern but is caching more things because it does not take into account the departure time of a trip along a chain. The current behaviour is hence to ignore varying departure times of the same trip (trip index + mode) and return the same travel time for every occurence of that trip in a chain. This may lead to inconsistencies, especially in public transport, where people may get stuck because the wrong connection was chosen for the end of the day. Tarek is currently adding the time constraint to this cache, we need to see how this affects simulation performance. In a second step, we could think of having a more intelligent caching approach (for instance, for public transport, always reroute if the new trip departs after the planned enter time of the agent in the currently cached route, and otherwise only if a certain threshold of difference in departure time is reached).

• There is the CachedVariablePredictor which is simply weird, not sure what was the idea behind it. Basically, is only reacts if the same trip is requested twice one after another. I believe the idea behind was that if we call two times predict on a car predictor, i.e. from the car utility predictor and the included cost model, the calculation should not be done twice. But it probably makes sense to solve this in the upstream code design (in the utility estimator, ...) and it probably does not any noticeable overhead! This one can be removed.

Make trip analysis configurable to be called every Nth iteration

Default trip duration handling

We have special cases in the mode choice where a trip may be so much delayed that it ends after the end time of the following activity. In such cases, our default configuration now sets back the departure time of the following trip to the end time of the activity, while the end time of the preceding trip should be used. This can be easily fixed by changing the trip duration interpretation in the default configuration from ignoreDelays to shiftActivityEnd.

Probably need to adjust the unit tests to respond to the new default behavior.

Travel time validation

For the last TRB paper on discrete mode choice, we were verifying that the predicted travel times in the choice model are in line with the ones actually observed in the simulation after several iterations. We should add this validation as a default output.

Plus, this will go well with the investigations by Milos and Aurore on settings network capacities properly, and it will be interesting to test the standard travel time estimation procedure that takes into account travel times of the last iteration vs. smoothing travel times over several iterations.

Swiss config does not include separate replanning strategies for freight agents

The scenario for Switzerland contains a separate freight population, which should have a different replanning strategy from the normal population. However, this subpopulation-specific replanning strategy is not defined in the base config, and not adapted in the Swiss ConfigAdapter, causing the RunSimulation class to fail if the config file is not manually edited.

As a first simple fix, the ConfigAdapter should be extended to add the necessary changes.

Problem in generate trips.csv of output plan

Hi @sebhoerl and @balacmi
I found an issue in eqasim output CSV , as you see below the input_plan.xml and output_plan.xml for certain number of agents (5000 out of 7600) in the origin and destination coordinates did not change and it always returns zero euclidean distance. I assume the code that parse output plans and change it to trips.csv format has a problem .

it would be nice if you can fix it.

Special case in cutting

There are special cases in the population that are not cut properly. In fact, routes by car which are outside of the study area are kept in very rare cases. This happens if we have:

• The origin activity is outside of the area
• The destination activity is inside of the area
• The last link of the car route that the destination facility is attached to is outside, while the facility (and the activity) themselves are inside

The same is true for the other way round for outgoing trips. The underlying problem is that the algorithm doesn't find any cutting point when the route is traversed. This is a special case that is not covered and hence some undefined behaviour is executed.

Utilities for DRT

Following our recent discussion, it would be interesting to improve the out-of-the-box functionality for DRT. We already have started this with the Corsica DRT example. First, this example should be extended and standardized, then the relevant components might move to a more high-level package inside this repository.

What is there:

• Analysis tools copied from AMoDeus, which give three relevant files: List of all DRT trips with origin, destination and timing from the customer perspective; list of movements with origin, destination, timing, occupancy from the operator perspective; list of activities (idle, pickup, dropoff) from the operator perspective.
• Simple rejection handling using a constraint: The rejection rate R is measured globally, and then a constraint is defined that forbids the use of DRT in R% of cases.

What we should add:

• Current rejection constraint should be revised: Following the structure of the epsilon package, we may want this to be deterministic in the sense that if in one iteration the DRT alternative is available, and nothing else changes about the trip chain of the agent, this alternative should also be available in the next iteration, and vice versa. Currently, it seems that we go in that direction by having a person-specific random number generated, but when looking through the code we had doubts that this is really deterministic (as the constraint factory may be recreated in every iteration; and if not, there may be multiple factories in parallel accessing the same Random instance). The best would probably be to generate a random number [0,1] deterministically at MATSim start-up, save it as an agent attribute, and then make use of it for this constraint.
• Alternative handling of rejections by adding a new component to the utility function that is based on the rejection rate.
• Infrastructure for estimating the relevant metrics: Make it easy to estimate waiting times, detour factors, and rejection rates by time bin and by spatial bin. Spatial geometry should be defined by a shape file, time bins by [start, end, interval]. This is useful for estimating these attributes and feeding them back to the utility estimator, but also simply for post-simulation analysis.
• Comparison infrastructure: Once we measure the metrics, we need to compare if the measured values represent more or less what we have seen later in the actual simulation. It would be good to have this functionality out of the box to directly identify (visually) after a run whether the estimation error is normally distributed or heavily biased. This goes for waiting time, detour factors, and rejection rates.
• Options for proposing values in the utility function: So far, we have mainly used the defined maximum values for the waiting times as choice dimensions that enter the utility function. It would be good to have separation of estimation and proposition as the operator may, based on its estimates, make a proposition that is either more optimistic or pessimistic than the estimated value. We expect that an interesting trade-off can be observed here: If the operator is very "optimistic", rejection rates may go up and customers will be unsatisfied. If the operator very "pessimistic", the base number of trips will go down, because customers are not interested. So there is a sweat spot in terms of proposing a connection from the operator side.

@kaghog @tkchouaki @balacmi

Consider crossing penalty in TravelTime

The standard car TravelTime currently does not consider the crossing penalty that we use in the QSim. While fixing this, we can also include the fix that solves the difference between QSim travel times (rounded up to the full second) vs. free-speed travel time from the network data (just the way we used it in our congestion analysis).

Improve analysis output

• Add legs output (just like trips.csv) indicating which legs belong to which trips, origin, destination, times, etc. (general information)
• Generalize public transport leg writer from ile-de-france as a standard analysis output (to give more information on access/egress stop, etc.)
• Optionally, provide output as parquet for fast reading / writing with pandas or other tools

RunExportEmissionsNetwork.java

Hello @sebhoerl,
After updating the RunExportEmissionsNetwork.java, when I run that in command line:

java -cp ile_de_france-1.0.6.jar org.eqasim.ile_de_france.emissions.RunExportEmissionsNetwork --config-path config.xml --time-bin-size 3600

in output I have the shp file but the updated pollutants are not in this shape file. Could you please let me know what else i should do?

Problem executing sao_paulo pipeline after commit c529f21

Hi. I tried using the sao_paulo pipeline a few months ago to generate files and simulation and it worked fine. Last week I tried to run the pipeline again and an exception popped up when executing matsim.simulation.prepare:

java.lang.RuntimeException: Could not retrieve vehicle id from person: 100266. If you are not using config.qsim().getVehicleSource() with 'defaultVehicle' or 'modeVehicleTypesFromVehiclesData' you have to provide a vehicle for each mode for each person. Attach a PersonVehicles instance (containing a map of mode:String -> id:Id<Vehicle>) with key 'vehicles' as person attribute to each person. VehicleUtils.insertVehicleIdIntoAttributes does this for you.

The complete log of the java command that is failing can be viewed here.

I did some tests and found out that the exception starts after commit “feat: car access/egress (#183) [c529f21]”, before this commit the pipeline completes all steps successfully.

I am new to Java, Matsim, and Eqasim and could not find how to avoid this exception. Do you have any ideas about what needs to be changed or what is missing?

IDFPtCostModel

I would like to propose some updates to the IDFPtCostModel class. Currently, if the agent doesn't have a Navigo pass, and if his trip is not within Paris or he doesn't use the metro or the bus, the price is calculated as follows:

Price = 0.25× (distance_origin_center_km+distance_destination_center_km)

However, this model is straightforward and assumes that all trips using the train, for example, and whose origin or destination are outside Paris, must necessarily pass by Paris, which is not always the case, especially when one is far from Paris and only takes the train to one or two stations, so the origin-destination distance should also be taken into account in order not to penalize train trips over short distances outside Paris.
A further remark is that, in general, people who do not have a Navigo pass are likely to use point-to-point tickets if they go to/come from outside Paris.
So, I would like to propose this simple model:
Price = max(5.5×σ(a×distance_origin_destination +b×distance_origin_center +c×distance_destination_center+d), 1.9 )
Where σ is the sigmoid function
The data I used to fit the model and estimate the coefficients is presented in the following table (collected from RATP and TRANSILIEN ):

the fitted coefficients are:

a = 0.098  
b = 0.006 
c = 0.006 
d =-0.77 

And here is a figure that illustrates the difference between the current model and the model I present:

Unit Tests

We need unit tests for:

• Basic run examples (running each scenario, with some toy data)
• Include cutter
• Analysis tools

And:

• CI (Travis) needs to be activated

Zero utility of waiting time

Currently, in the standard configuration of all scenarios, we have a zero utility of waiting time. This can have an effect on public transport routing. First test case will be Paris, where we can set it to a finite value (-1 to consider total travel time) and check if results are considerable different.

Improve public transport cutting

Currently, it seems that public transport cutting does not work as expected. In fact, cutting should happen from the agent perspective at the first stop that is inside of the area for incoming trips and the last stop that is inside of the area for outgoing trips. This may still be the case. However, when looking at the cut scenario in VIA, one can see that some stops close to the study area are kept.

Hence, we need to figure out if the problem already occurs in population cutting or only afterwards when the lines and routes are cut (and basically the stops are kept although nothing is happening there right now).

Allow for departure-time based caching

Currently, the mode choice components have either normal or cached estimators (configurable via config per mode). If cached, a trip is not rerouted when examining all the possible trip chains for a tour of an agent. This means if the same combination of (person index, trip index, mode) is encountered, an already computed route is used to perform the estimation of travel time and others.

Usually, this makes sense, because the departure time of a trip is mainly defined by the preceding activity end time. However, we can have edge cases when, for instance, a preceding trip takes so long that the following activity end time is exceeded.

Therefore, it might be useful to optionally also perform the caching by departure time, i.e. only if the new departure time of a trip is within a certain range from the cached departure time, the cached item will be used. This functionality needs to be implemented in CachedTripEstimator, but requires some additional refactorings, because currently each DiscreteModeChoiceTrip is an individual object for which the departure times are set on the fly during the trip chain exploration using the setDepartureTime method. This information would need to be passed to the estimator.

Simulate public transport vehicles

We need to check whether we can run eqasim with simulated public transport (from standard MATSim or SwissRailRaptor). A couple of points to check:

• Check whether eqasim scenarios run with standard PT / SwissRail PT
• Problems are expected for the utility estimators, as we usually do not know waiting time. Two options: for another project we have implemented tools to recover planned waiting times (and the code is included in the current develop branch of DMC); or we can switch to a newer weekly SNAPSHOT of MATSim, as I have implemented into the new standard routes of MATSim there.
• Check that cutting works (hint: it doesn't, because there are problems with "Umlauf")
• Compare our simulation-free PT approach with the simulation-fee approach of SwissRail. In case runtimes (and results) are similar, we can drop the specific implementation here!

Switch to AMoDeus / DRT for simulation of automated vehicles

Since the av package does not exist anymore, we should move to AMoDeus (which has all the av functionality now) or to DRT, which is increasingly becoming more compatible.

TransitEngine cannot be removed as it is not registered

In order to remove transit vehicles from mobsim, one now can set usingTransitInMobsim to false in transit module in the config. However, the following will not work anymore:

eqasim-java/core/src/main/java/org/eqasim/core/components/transit/EqasimTransitQSimModule.java

Line 35 in 8c4481f

components.removeNamedComponent(TransitEngineModule.TRANSIT_ENGINE_NAME);

This needs to be updated to reflect MATSim v12.0 workings.

Only-walk transit trips in initial routing

In the DMC we have a TransitWalkConstraint which means that walk-only public transport trips are never allowed as a choice alternative. However, in the initial routing (in the pipeline) we simply take the modes from the HTS and then route the trip. This means that in the initial population, we can very well have only-walk public transport trips.

So, we should update the population routing module to avoid only-walk public transport trips. I guess the straightforward strategy is to replace those trips with walk.

matsim.runtime.eqasim - Unable to delete output file

1st, thanks for your awesome repositories. I am not sure if you have any specific place to post questions. I am trying to run your California pipeline with my own data. However, when running 'matsim.simulation.prepare' it downloads eqasim-java correctly but fails while running test. I guess may be it is trying to delete the output png file before it was closed during test run. Can you please help me?

Error injecting constructor, org.matsim.core.utils.io.UncheckedIOException: java.nio.file.FileSystemException: simulation_output\ITERS\it.2\2.drt_detours_drt_rideTimePlot.png: The process cannot access the file because it is being used by another process

Thanks

Mode choice for zero-distance trips

Sometimes, we can have zero-distance trips in the population. This happens especially because of the way work and education locations are treated right now in the pipeline (always at the same spot for one particular agent). It would be good to make sure that those trips are always "walk", to avoid confusion (and not skew results, for instance on the mode shares), or filter them out in the analysis. A first step would be to check if we can enforce zero-distance trips to be "walk". Does this break the vehicle-based constraint logic? It should not, because if a vehicle is brought to the first activity, it is still at the same location when departing from the second activity at the same spot. Basically, this is a walking subtour, but should be checked!

• Enforce walk for zero-distance trips (or maybe even introduce a mode called none ?)
• Check that this has no impact on the vehicle tour constraints (breaking mass conservation)

Utility based on facilities location.

Hi, I'm new to MATSim, and I'm trying to develop a simulation of a bike sharing service. For this, I created a bunch of facilities with an attribute "type" with the value "pickup-point". I'm trying to lower the utility of bicycles depending on the distance between the start of a trip and the nearest facility of type "pickup-point" - the further way the worse.
In every example I've seen, this utility relies solely on trip data such as the distance or the leg mode but never the position of certain facilities.
Is it possible to have access to the position of facilities inside a utility estimator? How could I approach this issue?

Thanks in advance!

Better handling of mode analysis

NetworkModes is not ideal to feed the analysis listener. We need to define which modes should be tracked on the network more carefully (e.g. AV should be, but car_passenger not).

Inconsistent leg routingModes in some plans of the Corsica test scenario

I'm in the process of replacing the EqasimMainModeIdentifier with the RoutingModeMainModeIdentifier and I noticed it breaks the test in the ile de france package, the leg counts of the outputs of the cut-out of the corsica simulation changed.

After investigating it turns out that there are a few agents in the original corsica population with inconsistent routingMode such as person with id 194390 with a plan that looks like

<activity type="home" link="11711" facility="home_85954" x="1229261.93" y="6126404.59" end_time="06:56:14" >
</activity>
<leg mode="walk" dep_time="06:56:14" trav_time="20:00:48">
    <attributes>
        <attribute name="routingMode" class="java.lang.String">pt</attribute>
    </attributes>
    <route type="generic" start_link="11711" end_link="26202" trav_time="20:00:48" distance="86457.72488805738"></route>
</leg>
<activity type="work" link="26202" facility="work_2699" x="1219523.487796" y="6192193.670357" start_time="07:51:14" end_time="15:06:14" >
</activity>

This caused the EqasimMainModeIdentifier to interpret it as a walk trip when called from the ModeAwareTripProcessor. The trip is then then re-routed as walk in the cutting process.
With the RoutingModeMainModeIdentifier however, it is recognized as a pt trip and re-routed with swissrail raptor. Causing the plan elements to change.
Perhaps the corsica scenario was generated without using the TransitWalkConstraint.

We can quickly fix it by performing a re-routing of the population and replacing reference counts in the test. But we can also remove the corsica scenario and use, in the ile-de-france module, the melun scenario present in the core module. This issue is so that we don't forget about this topic. for now i'll just replace the reference counts in the test to make it work.

Remove EqasimMainModeIdentifier

... in favor of using the routingMode attributes that are provided since MATSim 13.

TimeInterpretationModule required for RunPopulationRouting in MATSim-14

I ran in an issue when trying to perform the RunPopulationRouting process with the state of the matsim-14 branch.
The TimeInterpretationModule is missing.

I think it will be required in other processes such as the RunPopulationCutter. In which case it would make sense to add it in the InjectionBuilderClass.

eqasim-java/core/src/main/java/org/eqasim/core/misc/InjectorBuilder.java

Line 40 in d947638

public void install() {

Generic intermodal routing / mode choice infrastructure

Currently, we have multiple implementations of intermodal trip alternatives. The basic idea is always to perform a routing of [acces mode] + [public transport] + [egress mode] by composing a new RoutingModule that combines existing modules for the individual parts. A varying components of this setup are the interaction points + depending on what intermodal chain is modeled:

• @diallitoz @lvmt-matsim @TSeregina use this for park & ride scenarios where the + above are rail stations with sufficient parking. (car + pt)
• @tkchouaki uses this for shuttle-based first/last mile services (drt + pt), the interaction points are a selection of rail stations
• @diallitoz wants to use it with shared services (sharing contrib + pt), the interaction points are stations with shared vehicle stations
• @balacmi @kaghog are not using this approach, but have a similar setup using SwissRailRaptor

The main components are basically the same in those implementations:

• Routing: Define a composition of existing routing modules for the underlying modes. The composite routing module chooses the potential interaction points. Choosing those interaction points can be hidden behind an interface such that all the use cases above are covered. All other considerations (making the choice deterministic, randomizing the choice, increasing / decreasing the search radius, ...) will be hidden in the implementation of this interface. The composite routing module should hence be defined by. Note that at a later step this could even be completely configuration-based:
  • In the configuration, define a new "intermodal mode" by defining the access/egress mode that will be connected with public transport.
  • In the configuration, define an attribute name that refers to an attribute that is given to all public transport stops that can act as a access/egress point using this new intermodal mode. Such a set-up would cover all the points mentioned above.
• Mode choice: Define a utility estimator, so it can be added to the discrete mode choice. Here, we can also create a composite estimator that sums up the utilities of the individual segments (access, transit, egress). One thing we want to avoid is adding up to many ASCs, so the existing utility estimators may need to get a method getConstant to make sure that we (1) can subtract the constants from the calculated individual utilities, and (2) add a new constant for the intermodal mode to the new alternative. Even this could be configuration-based by simply defining a new intermodal utility estimator and defining which are the base estimators, and by defining the alternative specific constant.
• Constraints: In the case where a chain-based mode is used for access/egress (see P&R above), we also need constraints that make sure that the vehicle is picked up again later during the day. This can be done by extending the existing VehicleConstraints (see thesis of @diallitoz) and this can also be made generic. One issue is to make sure that not only the chain of modes is consistent, but also that the access/egress points are consistent. However, this is something that should be handled on the level of the access/egress point interface. Basically, the condition is that if a trip A to B with a chain-based mode returns (X,*) as access/egress points, then the inverse trip B to A should return (*,X) as access/egress points.

Steps for implementation are:

• Take code from @diallitoz thesis and replace the hard-coded car parts with a generic mode
• Technically, the distinction between car_pt and pt_car is not necessary, we can just have a generic pr mode and the handling fo the correct "direction" of the trip can be handled inside the access/egress interface.
• After, it would be nice to have easy tools in the code to define these modes with all three components (routing, mode choice, constraints)
• And then even later (once this is a bit tested) it would be interesting to be able to do this in configuration

Update JDK

We should update the JDK version, otherwise we'll have problems with newer releases:
eqasim-org/ile-de-france#157

I guess we have to do this anyways when we want to upgrade to a newer MATSim (#155)