• A glossary of terms for describing Dynamic Transit Passenger Assignment,
• Lecture notes and teaching materials, and
• Interactive tutorials using open-source software.

While not perfect nor entirely complete, we hope that they are useful to a few different audiences:

• Consultants or agencies who may be interested in dipping their toe in and seeing what is there,
• Researchers who need to coalesce around terminology, and
• Academics who may be interested in providing an introduction to the topic.

DTPA Glossary

The DTPA Glossary was developed at the suggestion of Natalia Ruiz Juri at the University of Texas at Austin Network Modeling Center. When she participated in a review of our project in 2017 she noted how much the DTA Primer had done to promote a more broad understanding of DTA. While dynamic transit passenger assignment is not nearly as far along as DTA was at the creation of the Primer, she suggested a glossary of terms as a first step towards developing a shared understanding.

Glossary Website: https://fast-trips.github.io/dtpa-glossary/

Source: MTC, PSRC, & SFCTA

It was developed collaboratively first from within the project team, then more broadly via solicitations on the TMIP listserv and ResearchGate. We welcome feedback, suggestions, corrections, contributions, and debate on the glossary and hope that it can be a common resource for the community. It is anticipated that it can grow from a glossary to a more comprehensive resource similar to the DTA Primer.

Networks Page

Source: MTC, PSRC, & SFCTA

Lecture Notes

We have a class-worth of lecture notes developed by Alireza Khani, the original FAST-TrIPs developer and an Assistant Professor at the University of Minnesota. We are in the process of developing datasets within the Fast-Trips open source dynamic transit passenger assignment model code base so that the problems and assignments can be run and analyzed in real-time. We are also going to translate the notes from PDF to a Jupyter notebook where the problems can be run from within the notes.

Tutorials

We unveiled a series of five initial tutorials at the TRB Planning Applications Conference in Raleigh, NC and hope to expand them over time. The tutorials use the open-source Fast-Trips software which can be used on any Windows, Mac or Linux computer.

We hope that these materials will be useful to the community and look forward to working with anybody who wants to help expand and improve upon them.

1. Developed a shared understanding of issues affecting DTPA in practice (TRB Paper)
2. Conducted a literature review of relevant research in order to understand what problems had already been solved and what was outstanding
3. Identified high-priority research needs

The panel arrived at the following research needs that were also supported by the practitioners:

• Efficient and Effective Path Search Algorithms for Transit
• Service Unreliability in Schedule-Based Dynamic Transit Trip Assignment
• Empirically Valid and Computationally Efficient Transit Passenger Route Choice Model

We hope that defining and highlighting these research needs will promote an effective cycle from Practitionerville back to Academia in order to better evaluate current issues affecting transit planning.

We are looking for additional input as well as support for these high-priority research needs. We’d love your help!

• Submit your feedback on these research needs and how to fund them using the disqus comments below
• Comment on and suggest edits to the research needs statements themselves.

Fast-Trips Tutorial

Sunday May 14th; 3:00PM
Come learn some Fast-Trips basics. Please follow directions to download and software in advance at the GitHub Tutorial Site

Visualization Workshop

Sunday May 14th; 3:00PM
See how we are using various tools to explore the Fast-Trips calibration.
Presentation

Using Surveys for Dynamic Transit Calibration

Tuesday May 16th; 3:30PM
Learn about how we are using surveys [ and what we wish we had access to ] in our Fast-Trips calibration process. Presentation

The “Applications Track” of work is focused on standing up the Fast-Trips model such that it can be used in projects by agencies. This track’s plan, as denoted in the memo Developing and Applications-Ready Route Choice Model, is to first develop a set of performance targets and calibration tools to allow the team to efficiently identify and remedy issues. Subsequently, the plan is to complete three phases of calibration. Phase I focuses on making sure Fast-Trips makes sense at the individual trajectory level when compared with the on-board survey and California Household Travel Survey GPS data. Phase II will then scale this to full Bay-Area Fast-Trips runs and comparisons to route level and screenline-level validation data. Phase III will include a full Bay Area validation when integrated within the SF-CHAMP travel demand model and run with feedback.

The “Research Track” of the workplan will focus on defining and prioritizing the problems at hand for researchers and developing a set of test cases that researchers might use in order to explore the problems and validate any solutions. This work, which is detailed in the Memo Research Track Workplan, will be undertaken in conjunction with researchers in the field in order to more accurately understand the methodological gaps and more meaningfully frame a roadmap for remedying them.

We have spent the past Fall completing work on the performance targets and calibration tools and working through the Phase I calibration as described in the memo as well as a procurement to create a bench of researchers who will comprise our research advisor panel for the research track. We look forward to sharing the Phase I calibration process and what we have learned thus far in a forthcoming post.

Passenger Route Choice Challenges

Lisa Zorn will be presenting her paper titled Dynamic Passenger Assignment Challenges and she and Elizabeth will be manning the companion poster and would love to chat with people about any insights they might have towards solutions.

• Presentation Tuesday January 10th, 2017 from 1:30 to 3:15 Convention Center 156
• Poster Wednesday January 11th, 2017 from 10:15 - 12:00 in Convention Center Hall E

Making Open Data Useful

Elizabeth Sall will be manning a poster on an important, but “meta”, topic on open data standards management. Her paper is titled Making Open Transportation Data Useful and Accessible: Recommendations for Good Practices in Open Data Standards Management.

• Poster Monday January 9th, 2017 from 1:30 to 3:15 in Convention Center Hall E

We look forward to discussing these topics and more with many of you there.

Over the past few months, our team has spent a lot of time exploring the methods in the existing Fast-Trips software.  The more we run the software with various examples, the more questions we had about how exactly the algorithm works as written in code (which is slightly different from published papers), so we thought we would document what the algorithm actually does in this blog post.

Let’s start with the literature.

Nguyen, S., S. Pallottino, and M. Gendreau, 1998

For any given destination, a strategy specifies a set of attractive lines for every stop and an alighting stop for every line that may be boarded when traveling toward that destination, and a hyperpathis the unique acyclic support graph of a strategy.” ( )

Khani, A., M. Hickman, and H. Noh, 2015

A hyperpath, as defined by Nguyen and Pallottino 1988, is an acyclic subnetwork with at least one link connecting the origin to the destination, and where at each node, there are probabilities for choosing the alternative links.”

I still find this a bit confusing, so let’s start with a visualization (based on Figure 5 from Khani et al 2015):

Hyperpath Example [ click to enlarge]

Source: MTC, SFCTA and PSRC based on Khani et al 2015

Some Definitions

In this graph, a preferred arrival time, or PAT, is an input to the algorithm.  dt is an input parameter, specifying the maximum time window for which outgoing links from a single stop are considered a hyperlink.  Hyperlinks consist of a set of links from a single origin to multiple possible destinations.  In this example, two transit vehicles travel from stop1 to stop5 within the time window, and they travel at the same speed, while another vehicle travels from stop1 to stop3.  Similarly, two vehicles travel from stop4 to stop5, and one vehicle travels from stop2 to stop3.  Stop5 is close enough to the destination to walk, and stop1 and stop2 are both walkable from the origin.  In total, this hyperpath contains five feasible paths between the origin and destination, but only three separate hyperlinks.

When a preferred departure time (PDT) is specified rather than a preferred arrival time, the graph elements (and algorithm described below) are reversed.  That is, hyperlinks consist of a set of links from multiple origins to a single destination.  For the remainder of this post, we will discuss outbound trips with a preferred arrival time.

Algorithm

The original SHRP2-C10 version of FAST-TrIPs as well as the version of Fast-Trips currently under development by our team currently both use the following algorithm to formulate a hyperpath given a preferred arrival time, PAT and time window, dt.  The algorithm is a variant of Dijkstra’s Algorithm for finding a shortest path, except it’s constructing a hyperpath in order to find a set of paths with probabilities associated with them.  The stop label represents our best guess of the overall generalized cost  ( or impedance ) of travelling from that stop to the destination, and it’s formulated as the following logsum (from (2)):

Source: MTC, SFCTA and PSRC

where

• l_i is the label for stop i
• θ is the dispersion parameter used for modeling stochasticity.  This parameter is between 0 and 1.  Higher values for the parameter mean that higher cost links within a hyperlink are devalued compared to the lowest cost links in the hyperlink.  That is, if the lowest cost for a hyperlink is c, when a new link gets added to the hyperlink with a cost higher than c, when θ is closer to 1, the more the new link has a low probability compared to the lowest cost link.  The higher θ emphasizes the lowest cost link more.
• P_a is the set of available links (transit vehicle trips or transfers from stop i)
• c_pi is the cost to reach the destination from stop i using link p.  This cost is the label of the next stop (call it stop j) plus the link cost from stop i to stop j, so c_pi = l_j + link_cost_p

[ We will discuss the effects of these parameters and how to judge them in a separate post. ]

A stop state is the combination of a stop label (l) plus the list of links (transit trips, transfers, and access or egress links, P_a) from that stop to other stops (e.g. the links to the right of each of the stops in the figure above).  In our example, we have a preferred arrival time at a destination, so the algorithm sets labels and stop states backwards from the destination:  

1. Initialize stop states.  For each transit stop with an egress (e.g. walk) to the destination, label that stop.  Assume these walk links are as late as possible in time (so arrive at PAT) so that we have the the maximum number of options for getting to that transit stop; since the exact time of these walk links aren’t clear, they are represented as thick green bars in the above diagram.  The label at these stops is just the link cost, which in this case is typically based on the egress link travel time, and the stop state consists of just that egress link.  Add each stop and its label to a label stop queue.
2. Loop to label stops. While there are stops in the label stop queue:
   1. Remove the stop i with the lowest label from the label stop queue.
   2. Update the stop states for transfers to stop i.  That is, for all the transfer links from another stop j to stop i, update the stop state and stop label for that stop j so the hyperpath includes the possibility of transferring from stop j to stop i. So in the same way we treated the egress link times during stop initialization, we start with the assumption that these walk transfers are as late as possible in time (e.g. in time for the latest departure from stop i as determined by the stop state for stop i).  Add stop j and its label to the label stop queue.
   3. Update the stop states for trips to stop i.  That is, for all the transit vehicle links from another stop j to stop i, update the stop state and stop label for stop j so the hyperpath includes the possibility of taking that transit vehicle from stop j to stop i.  The trips are restricted to those which arrive in time to catch the latest departure in from stop i as determined by the stop state for stop i. Add stop j and its label to the label stop queue.
3. Finalize origin state.  After all the stop labels have been removed from the label stop queue, we need to initialize a stop state for the origin point by iterating through the access links and calculating a cost based on the labels of the reachable stop i combined with the cost of the access link.  Assume walk access link to stop i is right before the earliest departure from stop i so that none of the links out of i are excluded.
4. Enumerate paths.  In theory, the origin state now has a label that has a cost that encapsulates the costs of all the trip links and transfers.  However, recall all of our assumptions about the timing of walk links (egress, transfer and access).  These result in inaccurate assumptions about wait times which can only be determined when actual paths are enumerated.  We therefore walk the labeled hyperpath and generate all of the actual, realizable paths from it.  At this point, we can fix the timing of the walk links and therefore have actual wait times.  The path costs here are used to calculate the probability of each of these paths.

Issues

Now that we know how FAST-TrIPs defines and creates a hyperpath, a few issues arise that we are grappling with.

Label Stop Queue Order

In Dijkstra’s algorithm, nodes also get removed from the priority queue based on having the lowest label ( least cost ).  The proof of correctness for Dijkstra’s algorithm is based in the fact that label[v] = label[u] + link_cost[u,v].  However, for the Fast-Trips algorithm above, this is not true, and so the stops that get pulled off the label stop queue do not necessarily have final labels.  Fast-Trips labels can be updated at a later point, and the fast-trips algorithm does not then account for the subsequent updating of stop states for trips and transfers to that stop after that label update.

Link-Additive Costs

Before enumeration, hyperpath costs must necessarily be link-additive, and even then, the cost is not accurate until enumeration because of the uncertainty with the walk links.  This could cause problems with costs that are not link-additive, such as fares which can have complicated transfer rules.  For example, one could take a bus to rail to bus trip, and the second bus trip would be a free transfer.  When the path is enumerated, this would be easy to account for, but during the hyperpath generation, the links further down the hyperpath are uncertain.  

There is a risk is that we may not generate a reasonable path in the labeling stage, and then it can’t be corrected in the enumeration stage.  So why not generate all feasible paths in labeling?   For one, it would take forever, but also we don’t think it is possible to know if we didn’t generate all the feasible paths.  We welcome others comments on this topic, as it is one that we have been thinking about.

Path Overlap

When evaluating the value of a transit path, we typically take into account other path options to determine the value of that option.  That is, if two paths exist that are virtually the same except but with a small difference – for example, if a destination is between two stops, two options could be the same except for getting off the same transit vehicle at one stop or the other – then the value of those paths together should not be much greater than the value of one of those paths individually.  This affects probabilities as well; if there is a third option that is much different but as good as the other two, then the probability should be around 50% for the third option and 50% for the other two.  Therefore, accounting for path overlap needs to be included in both path evaluation and in calculating any overall “quality of transit” metrics.

References

1. Nguyen, S., S. Pallottino, and M. Gendreau.  Implicit Enumeration of Hyperpaths in a Logit Model for Transit Network.  Transportation Science, Vol. 32, No. 1, 1998, pp. 54-64.
2. Khani, A., M. Hickman, and H. Noh. Trip-Based Path Algorithms Using the Transit Network Hierarchy. Networks and Spatial Economics, Vol. 15, No. 3, 2015, pp. 635-653.
3. Noh, H., M. Hickman, and A. Khani, 2012, Hyperpath in Network Based on Transit Schedules, Transportation Research Record, Vol. 2284, PP 29-39.

Time blocks to time of day

In order to distribute the trips to discrete times from the five aggregate time periods that SF-CHAMP uses [ AM Peak, Midday, PM Peak, Evening, and Early AM ], the script uses cumulative density functions for preferred arrival and departure times derived from observed SFMTA Automated Passenger Counter (APC) boardings and alightings.

Data reformatting

The demand data is then reformatted to the Dyno-Demand format to be able to be read by Fast-Trips. The Dyno-demand format has one mandatory file (trip_list.txt) and two optional files [ household.txt and person.txt ].

One other item of note is that although SF-CHAMP currently models a variety of sub-modes in its trip mode choice model [ e.g., ferry, local-bus, express-bus, commuter-rail, etc ], the team decided that it would be better to let Fast-Trips make the sub-mode selection in the route choice model. Therefore, the transit sub-modes from SF-CHAMP are collapsed in this script to Walk-to-Transit and Drive-to-Transit.

Transit Travel Demand - Take One

If you are interested in reviewing our “first take” of the San Francisco disaggregate transit demand, you can download it here. Please note that this is by no means a finished product and still needs a fair amount of work, as documented in the various GitHub Issues. That said, if you want some demand that is bigger than the test network, here is something you can use in combination with Take-1 of the San Francisco Bay Area Network.

The general approach to creating networks is to take the travel demand model networks that each agency already produces and add information to them to create a schedule-based network as required by our GTFS-PLUS network specification [ and discussed in this blog post ].

Network Conversion Scripts

The team has created two network conversion scripts: one that converts PSRC’s SoundCast’s EMME networks into GTFS-PLUS networks that Fast-Trips can read and the other that uses SFCTA’s “Network Wrangler” to convert SF-CHAMP networks to GTFS-PLUS. While the PSRC version requires an EMME license, SFCTA’s Network Wrangler is based in Python and can therefore be run by anyone.

SoundCast Fast-Trips Network Builder

The SoundCast Fast-Trips Network Builder converts SoundCast’s Emme networks into GTFS-PLUS networks by completing a bunch of data transformations and simulating a transit schedule either based on average headways for a given time period [ good for future year data ] or by grabbing the GTFS schedule [ good for base year data where the schedule is known ].

Network Wrangler

Network Wrangler is the codebase that SFCTA uses to build their transit and highway networks. It has class objects for things like transit lines, nodes and transit networks. When possible, these classes were just extended to be able to write out GTFS-PLUS files. However, quite a bit of logic had to be built in in order to incorporate things such as complex fare structures.

The script can be run as follows:

python convert_cube_to_fasttrips.py network_specification.py

There is still a bit of work to be sorted out to come up with the version of the network that we will be happy with, but we can still get some good mileage out of this version. In particular, there are additional data fields that would be nice to populate and the base year schedule should be synched with existing GTFS data rather than randomized across a log-normal schedule.

Network File

Want to take Fast-Trips for a spin right now? Feel free to download Take-1 of the San Francisco Bay Area Network and use it in combination with the first draft of the San Francisco Bay Area Demand

The basic requirements are:

• Anaconda ( or equivalent ) installation of Python
• Microsoft Visual C++ Compiler for Python 2.7 (e.g. for Windows )
• TransitFeed for reading GTFS data

We have included a small, five-zone test network [ located in the subdirectory \Examples\test_network ] to facilitate tinkering with and testing various features before instituting a full-scale run.

Small Test Network

Source: MTC, PSRC, & SFCTA

Nothing is perfect, but we would love to know what you think! Please submit issues to our GitHub Issue Tracker. The more people who try it out now, the better and more usable it will be later.

Evolution of Standards

We have iterated some on our standards, and updated all of our tools to use them.

Network Standard

• Biggest pain is still the fares, which have changed slightly as we have worked through the various fare types in each region and realized that there were too many exceptions to our simplifications.
• The biggest changes to the standard are to decrease ambiguity.

Demand Standard

• Has remained more constant.

Network Creation

We have substantively completed the code to do the network creation process for Fast-Trips on the fly from within SoundCast and SF-CHAMP.

• Includes schedule creation from headways [ using GTFS if it is available ].
• Fares have been the most difficult component to “get right.” There are a multitude of fare rules by operator of multiple types [ zone, flat, station-to-station ], and multiple transfer policies. These were all roughly approximated in our current system and so transferring them to the new data standard requires a lot of care and thought.
• The PSRC Version has undergone small-scale testing and will be scaling to entire network this week. It utilizes the EMME API, so may be of limited use outside of EMME users.
• The SFCTA version is within their stand-alone NetworkWrangler and is slightly behind PSRC in maturity.

Demand Validation

Our initial investigation into validating the demand has been met with the [ not unexpected ] issue that the OD data we have [ on-board surveys and CHTS ] is significantly higher [ when weighted ] than the ridership data we have at screenlines. We are looking into this issue and hope to not get lost down this rabbit-hole if it isn’t going to benefit us too much in the long term since SF-CHAMP hits the screenline data fairly well.

Fast-Trips Travel Model Integration

Joe developed a white paper summarizing the various issues and potential strategies for feeding LOS information coming out of Fast-Trips back up to the travel demand models.

Joe, Elizabeth, and Lisa have been working to develop an approach that addresses these issues. The process is challenging, because SF-CHAMP and SoundCast have very different approaches to mode choice.

Software Released!

You can download and use Fast-Trips yourself! We had Bhargava [ somebody who wasn’t involved in the coding ] work through the small test scenario and make sure he could download, compile, and use it.

Instructions and code are on GitHub and will be summarized in a forthcoming blog post.