MatrixBasedPtrouter differentiated by submode (bus/train,tram)?

[MarkRaadsen]

Hi,

We're working on a cloud based platform for the Australian Research Data Commons (ADRC) with one of the services offered being a containerised MATSim (see https://aurin.org.au/about-aurin/network/atrc/). As a basic starting point we want to offer a simple multi-modal "template" that adopts the MatrixBasedPtrouter just to let users get a feel for MATSim without the need for full schedules etc.

The question however is that it appears that the MatrixBasedPtrouter puts all pt modes in the same "bin", resulting in tram stops being accessible to bus-stops etc. Is there a way (without constructing the stop-stop matrix by hand or programmatically ourselves) to configure the router such that it recognises multiple pt (sub)modes and generates entries between pt submodes, e.g. define bus<->bus, tram<->tram, train<-train> etc. This would be both save a lot of computation time as well as being acceptable for our purpose (whereas now I'm afraid it is too crude even for this purpose). I could not find anything in the documentation nor in the repo itself that points to this, but I might have overlooked somehting. If this is indeed not possible, what would you recommend as an alternative to roughly achieve the same base" intermodal setup without resorting to full-fledged schedules?

Thoughts would be very much appreciated!

[vsp-gleich]

Hi, MatrixBasedPtrouter is a pretty old piece of code which has seen only maintenance work in the last years. I see no functionality for pt submodes in it. In order to help you, let me try to understand better your use case.

In principle, in matsim you can think of the following ways to model public transit:

1. Add it as a teleported mode with a fixed teleportation speed like walk or bike. This can either be entirely based on beelines or routed with a certain fixed speed along the network.
2. Route a teleportation leg using a travel time matrix with MatrixBasedPtrouter.
3. Add a proper TransitSchedule and route according to schedule.

In general we use option 3 because this is the most precise option. Option 3 needs some schedule data as input, usually gtfs data. Option 3 needs the most computation time because it has to actually route agents along the schedule.

I am not sure whether your motivation not to choose option 3 is the computation time or the lack of input data for the TransitSchedule. We take many matsim models from a company which runs a 25% sample of Germany, i.e. ca. 20 million agents with a Germany wide schedule. Somehow they manage to calibrate that scenario and route all public transit trips according to schedule on some larger computer, but definitely not a supercomputer. Later on they cut out the agents and the transit schedule for the study area we are interested in and that works for e.g. a 25% sample of the Rhine-Ruhr area with 2 million agents in the model. We are able to run that scenario in ca. 7 days on a larger computer (12 cores, ca. 250GB RAM). Replanning takes less than 25% of the total computation. So public transit routing does not seem the bottleneck in computation time (rather qsim is the bottleneck) so I wonder whether it would be really an issue for you.

A lack of data is a different issue. It would exclude option 3. However, it puts some doubts on what data you could use to fill travel time matrices for option 2. Maybe then option 1 is sufficient? If a constant teleportation speed is not what you want you could either try to write your own teleportation module calculating a more intelligent travel time estimation (maybe the more distance the faster assuming faster rail services are available) or you could try to fill matrixbasedptrouter with whatever estimates you deem adequate. You could add only a selection of real transit stops to reduce the size of the matrix if you are concerned by that.

The way matrixbasedptrouter is built is a simple look-up in a table with travel times from all stops to all stops. It cannot differentiate between pt sub modes and it is not clear how such an differentiation would look like. Do you want to route from origin to destination with either only buses or only trains? Most pt networks rather use train lines as a backbone and buses for access and egress to trains, so this does not sound convincing to me, there might be no continuous bus route. Do you want a multi level router which uses buses for access/egress to schedule based train lines? That is doable by using the normal intermodal transit router and adding "bus" as a teleported mode for access and egress.

[MarkRaadsen]

Thank you for the elaborate response, much appreciated.

The reason not to do 3. is because we will also want to add 3. at a later stage as an alternative "template" let's say. Yet, we want to provide novice users with an "easy template" to do a multi-modal simulation without having to deal with schedules. Especially for first-time users of the system we want to have a number of easy entry points with varying levels of detail. In this project we do not do the application, we just provide the infrastructure for others to run MATSim simulations and part of that is to provide some ready-to-go templates.

My hope was that there would exist something (without the need for any schedules) like the following: A matrix based router as you have but one that could generate travel times only between stops with the same pt mode (bus-bus, train-train, etc.), and a similar matrix that would be inter-pt-mode (bus stop - train stop) where the latter would be based on walking speeds for example and the former on a slightly higher mode specific speed. Then a combination of stops (intra and inter mode lookups) could be used to generate the shortest teleported pt path. This would yield require more but much smaller matrices and a very simple shortest path algorithm to connect them.

This not being present is not a problem. It is already good to know it does not exist and there is no easy way to create this without diving into the code base. We will just keep the basic pt-umbrella router as our "simple" template and start work on supporting option 3 as the "advanced template" which will require schedule information and forego an intermediate approach.

Thank you for your time and clear explanation though!