Closed DavidOry closed 1 month ago
I recommend being as aggressive as we reasonably can in setting these. The tree map shows 21 journey levels. The initial recommendations included 8 journey levels:
A few possibilities:
Those two changes could potentially get us from 8 down to 5 journey levels.
And one more question: Does EMME include the concept of fare links? If so, can we use them to customize as we need? For example, we could merge Ferries with express buses, but have an additional $10 fare link at the dock.
@gregerhardt I was thinking we start even more aggressive. One thing to note is that the journey levels are states. So, if a system like Caltrain does not give any discounts after riding Caltrain, then it does not need a separate journey level. Said another way, being in the state of having already boarded Caltrain does not change how you interact with the other services. We can accurately (well, after transforming it to a distance-based approximation) represent the Caltrain (and Ferry, and BART) fares without them being separate journey levels. The only thing we get wrong is the transfer discount when moving to another operator. I did not fully understand this -- probably still do not, thankfully we have @inrokevin to help us -- when I wrote the original recommendation for eight.
I think to start we go down to 2 journey levels (plus the others we'll need for park and ride and to prevent walking all the way), as follows:
This is a minimum configuration in which we are acknowledging the free transfers on Muni (which is important), but ignoring all other transfer discounts. We can then assign the on-board demand with this configuration and see what we need to add, e.g., the discount when going from AC Transbay to AC Local, which @e-lo said was a problem in a long ago SFCTA calibration.
@inrokevin: what do you think about this approach?
You have the right approach Dave. Small clarification (probably what you meant but just to be clear) the base state would be not yet boarded Muni, i.e. would include not having boarded at all and having boarded any other services. So this proposal would no longer differentiate initial and transfer boardings.
A 3-level approach (1. not boarded anything, 2. boarded muni, 3. boarded anything else) is something to consider if transfer behavior is really off. This would also allow preventing "walk all the way" trips at the same time.
Any additional operator-to-operator fare discounts should be considered in the context of the number of transfers. A review of operator-to-operator transfers and important fare discounts might reveal some reasonable "over-discount" options. SO, for example, for the AC Transbay / Local case: if few transfers from other operators occur we could give the "from AC Transbay" discount for all transfer boardings to AC Local, knowing that fares for some passengers will be under-represented.
Of course, I would recommend trying a simpler version first and seeing if there are problems and only adding complexity as necessary.
Fare links and virtual stops can be used to represent special transfer combinations. This can be much more efficient for very local and well defined cases, e.g. special transfers between ferries, or ferries to certain bus services. However, the network visualization and maintenance can be a little more difficult.
Thanks @inrokevin. Can you explain the "additional operator-to-operator fare discounts" a bit more? Is this another journey level or something else?
By "additional operator-to-operator fare discounts" I am referring to the real world cases, for example the AC Transbay & Local transfer fare discount. Before we decide to allocate a journey level to representing this case, we should consider that there are options for representing the fares without journey levels.
My main point was that in order to prioritize, we should consider the number of passengers affected by analyzing the operator-to-operator transfers.
Initial test results are in. The test includes three journey levels, as follows:
Headline of run-time comparison: for the morning commute period congested assignment of the on-board survey demand:
See the below spreadsheet for additional details, including the compute spec.
observed-transit-assign-journey-level-runtime.xlsx
The two assignments give highly similar results (for the morning commute). See this Tableau workbook. The key differences are as follows:
Recommend moving forward with this configuration for next round of testing and to discuss the user experience on our July 3 call. Additional calibration to the address Caltrain and Ferry can occur if the pattern replicates in the 2023 base year.
@lmz, @vivverma9, @gregerhardt, @FlaviaTsang, @inrokevin
@vivverma9 Here's what I'm thinking in terms of the user experience:
@vivverma9, @AshishKuls Updates per our conversation https://github.com/BayAreaMetro/travel-model-two-config/blob/fa7d224dd4151931e5818315e664a94908d2ee34/2015-tm22-dev-sprint-03/model_config.toml#L865-L873
Some additional runtime statistics for a test with four journey levels for morning commute assignments:
Excel: observed-transit-assign-journey-level-runtime-update.xlsx
Here are Tableau summaries showing the outcomes of the above two tests, with three and four journey levels respectively.
User Story
The initial translation of the Cube transit assignment scripts were faithfully translated to EMME. This included the translation of the fare matrix. Mechanically, this was done via an algorithm that considered the distance between services and their differences in fares, with a goal of creating fewer than the maximum number of 30 journey levels. Because EMME considers the fare in the path building stage, there is a severe runtime penalty for each journey level. An analysis of the algorithmically created journey levels revealed that a lot of them were working to create accurate representations of fares for low ridership services (that have complicated fare structures) -- see tree map below.
As a first step in assessing the impact of reducing the journey levels on runtime and outcomes, we will manually specify journey levels within
tm2py
, starting with @inrokevin's recommendations. Subsequent efforts will create a set of procedures so that the specifications can be derived from a set of GTFS files and guidance documents.Progress:
Priority
High
Level of Effort
~80 hours
Resolution Ideas
model_config.yml
file that specifies the desired journey levels. Per @inrokevin, this could look something like:Project
MTC's ActivitySim/Emme Conversion, Task Order 5
Who should be involved?
Users: @lmz Reviewers: @inrokevin, @gregerhardt
Risk
Yes. The outcomes from the assignment may be different due to changes in the fare assumptions. However, manually specifying a small number of journey levels should make the code simpler and more robust. Right now, the algorithm can return more than the maximum number of journey levels.
Tests
We want to run the following tests: