competing modes for intermodalAccessEgress

[fredshone]

This is to check my understanding and perhaps provide useful record for others.

I am using intermodal access and egress, eg:

    <module name="swissRailRaptor">
        <param name="useIntermodalAccessEgress" value="true" />
                <param name="intermodalAccessEgressModeSelection" value="CalcLeastCostModePerStop" />
        <parameterset type="intermodalAccessEgress">
          <param name="mode" value="walk" />
          <param name="initialSearchRadius" value="1000" />
          <param name="maxRadius" value="1000" />
        </parameterset>
        <parameterset type="intermodalAccessEgress">
          <param name="mode" value="bike" />
          <param name="initialSearchRadius" value="1000" />
          <param name="maxRadius" value="5000" />
        </parameterset>
    </module>

In the cases where there are two viable access or egress modes (in this case walk and bike) I am currently assuming that the router will prefer the cheapest mode.

Based on this code I think that cheapest will be based on marginalUtilityOfTravelTime_utl_s, ie neglecting a constant or any other costs for that mode?

Is this intended? We ussually calibrate the constant cost for modes to prevent unrealistic short trips, for example by car, where walk would be more sensible, and similarly for bike.

As we currently calibrate we therefore always get car as an access mode, even for extremely short trips.

Partial solution seems to be to use:

<param name="intermodalAccessEgressModeSelection" value="RandomSelectOneModePerRoutingRequestAndDirection" />

Which i judge is more in keeping with the overall MATSim approach to util maximisation. But looking for some assurance. :)

[synas34]

Hi there,

I am working on a simulation of Tokyo and have this same issue, where allowing bike or taxi as a accessegress mode leads to complete shift to this faster mode.

I have added a negative constant or a multiplier in the intermodalAcccessEgress class if bike or other mode is selected, however the constant added to reduce bike-to-rail trips to 10% (observed) decreases pt mode drastically(from >40% to <15%)

I am unable to calibrate both the main modes as well as the access/egress modes.

What work arounds are suggested? Where can I insert a constant to calibrate these access/egress trips without affecting the overall main mode?

[fredshone]

I think we used <param name="intermodalAccessEgressModeSelection" value="RandomSelectOneModePerRoutingRequestAndDirection" /> then tuned pt costs to get calibration (essentially after we tuned walk, bike, car...) - but perhaps we were lucky.

Not sure if the theorists like to have costs for an access/egress mode different to the mode being used in isolation? My preference was to keep them the same.

I think SBB use access/egress specific modes. eg car_access_train. In which case you can play with costs in config (but you will still need RandomSelectOneModePerRoutingRequestAndDirection which is slow, or implement the costs correctly in the router class you link).

Also (a vague recollection) SBB were using these special modes not to fine tune costs - but rather to have more control over them (perhaps for example not permitting or forcing their use by certain agents/stations or teleporting etc).

Related issues with calibrating PT modes:

• buses getting stuck in traffic
• conversely - not enough congestion for other modes (car)
• ...basically to some "physical" validation first - eg check that journey speeds are reasonable
• not implement car ownership ie no car should equal no driving
• incorrect capacity scaling (generally recommend not scaling capacity down too hard for scaled sims)
• broken interchanges in schedule
• interchange and waiting costs

Hope this helps.

[markusstraub]

We stumbled over the exact same problem when using a calibrated population with walk and bike access egress modes that was calibrated with <param name="intermodalAccessEgressModeSelection" value="RandomSelectOneModePerRoutingRequestAndDirection"/>

My understanding was that <param name="intermodalAccessEgressModeSelection" value="CalcLeastCostModePerStop"/> should provide the exact same simulation results but lead to much faster equilibrium and I was astounded to see the modal split for pt to drop dramatically. After a while I came to the same conclusion as you: since SwissRailRaptor only takes the value of travel time into account the generated routes are not ideal for some agents (and better ones are never generated). constant, monetaryDistanceRate,.. are completely ignored.

Staying with RandomSelectOneModePerRoutingRequestAndDirection is not my preferred solution since already for only two modes it takes >700 iterations to come close to an equilibrium.

Imho a real solution for this issue could be to implement a custom RaptorIntermodalAccessEgress that takes all scoring parameters into account. @mrieser could you comment if this is a sensible approach? I could probably implement this, but it would be great to hear from an expert if this is a good idea (or we are simply using SRR in a wrong way).

[kainagel]

@vsp-gleich knows more about this, but it currently not in the office. Some remarks until then:

• It is discouraged to set the mode-specific constant of "walk" to something different than zero. Reason is that this constant will be added every time that mode is used, i.e. for every access, interchange, and egress.
• Evidently, you will have the same problem for other access or egress modes besides walk. I would argue that this is maybe less of a problem since these constants can be interpreted as "setup costs" which may also be plausible for access/egress, and they will probably not be used for interchanges.
• The link between the scoring function and the regular network router is already only partial. The link between the scoring function and the RailRaptor is even weaker. I think that at some point @vsp-gleich replaced the corresponding cost calculation manually. These difficulties are part of the reason why VSP has so far never published about this.