We are three public agencies, working together, trying to create better tools to analyze human-scale travel in congested, urban cities
What is Fast-Trips?

Fast-Trips is an open-source code base that has been developed at the University of Arizona and the University of Texas at Austin via a series of Federal grants to simulate transit passenger route-finding and user experiences.

Why are we (three public agencies) implementing Fast-Trips?

Many of the questions confronting urban transportation planners today concern moving people rather than vehicles. However, most advanced operational planning analysis tools still operate on the vehicle as the primary unit of analysis and use a geographic scale incompatible with the measures of concern to human-scale travel. When our ability to analyze solution A far surpasses our ability to analyze and understand solutions B, C, and D, we may be more likely to pick option A even though it isn't the best.

Great strides in advanced operational planning for vehicles have been widely supported and are starting to be adopted by the mainstream. This includes technology known as Dynamic Traffic Assignment which routes vehicles through an entire area using a second-by-second time resolution. While transit is often represented in Dynamic Traffic Assignment, its performance can only be measured based on how well the vehicle performs in traffic, not the quality of the route to the person taking transit. While this enables engineers to analyze how much faster a bus might get through an intersection with transit signal priority, it doesn't let planners understand the levels of investment necessary to ameliorate over-crowding or engineers and service planners understand the system-level effects of strategies to address transit reliability.

Who is "We"?

We are a team of three public-agencies with similar goals for analyzing human-scale transportation investments who came together in 2014 to apply for and win a Federal grant through the SHRP-2 program ( specifically, C10 Implementation Assistance ). This will be the first attempt to implement a production-ready and calibrated person-based dynamic transit component to a regional transportation planning model based on the Fast-Trips code base.

This website will document our plans, journey, and lessons-learned.

Updates from the Field

What is a hyperpath, anyway?
By Lisa
21 April 2016

What is a hyperpath, anyway?

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]
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

  • li 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.
  • Pa is the set of available links (transit vehicle trips or transfers from stop i)
  • cpi 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 cpi = lj + link_costp

[ 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, Pa) 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.

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.
» Read More
Two Metro-Area Transit Networks – Take One
11 January 2016

Are you enjoying running Fast-Trips on the small test network but ready for a “big time” network? Today is your lucky day.

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

» Read More
SF Transit Demand - Take One
11 January 2016

We have transit demand – a version of it, anyway. I started with a script that Lisa Zorn developed back in 2012 when she and Alireza Khani worked on the paper Integration of the FAST-TrIPs Person-Based Dynamic Transit Assignment Model, the SF-CHAMP Regional Activity-Based Travel Demand Model, and San Francisco’s Citywide Dynamic Traffic Assignment Model. The script currently does two things: reformats the data, and assigns disaggregated preferred departure and arrival times. In the future, it may combine data from other sources and perform minimal variable synthesis.

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.

» Read More
Test Me
16 December 2015

Good news – we just put up some instructions and sample data for you run Fast-Trips at home!

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
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.

» Read More
Fall 2015 Update
15 December 2015

Over the past few months, we have made substantial progress on our standards, the network preparation, and the Fast-Trips software itself. Paperwork has delayed some of our progress in the Travel Behavior task, but that is now behind us and we can push on. Here is a brief summary of a few of the things we have been working on.

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.

» Read More
Version Controlling a Data Standard
02 October 2015

We have a number of data standards that we are creating as a part of this project (see my previous post about the development of a few). As we progress in the project, we realize that the standards will evolve and need to be updated. As good little developers, we knew that we needed to start version controlling the data standard as well as the software that uses it. You can see the finished result of a version-controlled standard on GithHub, but if you are interested in the journey to get there, read-on!

Starting

We started with using different saved copies of the memo that described the standard:

Network Standard v0.1.pdf
Network Standard v0.2.pdf
Network Standard v0.3.pdf

While sufficient, there are a number of obvious drawbacks with this approach. Most notably, is that in order to see the differences between versions you have to compare each entire PDF document. Even if we were to include a changelog, it would require somebody to cycle through multiple documents if they wanted to understand differences between multiple versions.

What are others doing?

I did some online research to find out how other data standards are controlled and found a variety of examples, which are described below.

Google and GTFS

Google does keep a record of the changes they have made to the GTFS specification but does not assign each change a unique version number or track it in any other way than a change-log. While the specification is very openly “not set in stone”, one of the guiding principles for changes is that they should be backward compatible.

» Read More
The Wheel of Progress - Summer 2015
17 September 2015

The following is a brief update on the overall status of the Fast-Trips implementation project.

The Tri-Agency group implementing Fast-Trips has been making significant technical progress on: software development, data standards, network development, demand evaluation, and evaluating route choice methodology. In administrative news, Mark Simonson has joined the Management Team from PSRC and Jeff Hood has joined from our consultant bench in order to take a lead on the route choice estimation task.

In software development, we have completed a refactoring of Fast-Trips to Python and fixed many bugs along the way. In order to have a tolerable run time (<6 hours), we:

  • vectorized some of the operations so they could be completed in Pandas data frames;
  • instituted multi-processing for the path-building; and
  • used a C++ extension for loops that could not be vectorized.

Representing a 40X speedup in itself, the C++ extension is as generalized as possible in order to keep all the day-to-day and month-to-month control within the much more usable and legible Python. The next step is to do feature development on modal biases and selections and then to optimize for skimming procedures.

In data standards, we have developed both a transit network data standard that is an extension of GTFS (the most complex part being fare representation) and a demand data standard](/library/T3-TransitDemandData-WorkingCopy-July2015.pdf) that will work equally well for auxiliary and activity-based demand.
The networks team has moved on to develop Python code to create the networks from both EMME/SoundCast and SF-CHAMP/Network Wrangler using agreed upon methodology for translating headways to schedules, while the demand team is finalizing methodology to adjust our demand that we will use for route choice estimation based on the GPS data from the California Household Travel Survey, On-Board Surveys, and Automated Passenger Counter data.

Not far behind, the route choice team completed a draft literature review and is evaluating various possible methodologies while they await some contracting hurdles to pass and data availability milestones to be reached by other parts of the team.

The goal is to have all task teams converge at a mid-October time point and be able to begin route choice model estimation.

» Read More
Speed Demons
By Lisa
01 September 2015

In my previous post, I unveiled the size of our “performance problem” for Fast-Trips and discussed various ways that we had and were planning on attacking it. I had already made some speed ups by using the multi-processing for pathfinding (while making sure the random number seeds that were used were unaffected), but the big question mark was if a c++ extension would make a big-enough dent into our run time to be tolerable enough to run in at least a “development mode”.

I spent the past two weeks creating, testing, and documenting the c++ extension and am happy to say that when combined with the multi-processing across 64 cores (reasonable for our case), the projected runtime will be four hours (as opposed to four weeks/months). The c extension alone represented a 40x processing speedup.

Phew!

Next up:

  • explore allowing non-additive costs in path search
  • improve usability and parameterizing the c-extension
  • input/output reading and writing for new Fast-Trips data standards
  • allow modal biases / selectivity
» Read More
Standard Deviation
21 August 2015

There were two main sets of interim deliverables that we assigned to ourselves to complete fairly early on:
1. detailed methodology development and planning (after we had read all the literature, etc. ) and
2. data standards that would enable us to use the same tools and talk the same lingo.

This update discusses data standards (and our lack thereof). Our task was to find a common way for Fast-Trips to be able to interact with our three model systems: SF-CHAMP (SFCTA), SoundCast (PSRC) and Travel Model One (MTC).

Standards everywhere you look

First, let’s talk about the standards that we already have, use, or will use as a part of this project at PSRC, MTC and SFCTA:

  • OMX for skim matrices and aggregate demand files (i.e. visitor travel)
  • Cube Networks:
    • .NET highway, bike, and pedestrian network files
    • .lin and .link transit network and service files
    • .access, .zac, .xfer, and .pnr SF-CHAMP network wrangler files
  • EMME data bank
  • APC data dumps
  • GTFS schedule based transit service
  • HDF5 disaggregate demand files

Clearly that is a lot to consider and we were hesitant to add even more standards to the mix.
We could have opted to code a lot of flexibility into Fast-Trips itself and have it accept a wide variety of inputs, or we could standardize the input that it was expecting and use outside forces to commandeer the variety of data we needed into that standard. We chose the latter approach, not just because of the sheer variety of formats, but also the variety in how those formats are used at each agency. For example, while MTC and SFCTA both use Cube, the data that they include within their Cube networks varies, and some common data elements use different units as well.

Where a Fast-Trips data standard fits in

Our chosen approach for dealing with the varying input data is shown in the figure below.
The blue items on the left represent the unique standards and uses for each individual agency along with the variety of data that might be available in each region. The green boxes in the middle represent the “glue code” that Tasks 2 and 3 (Networks and Demand) are responsible for developing alongside Task 8 (Implementation). The scripts that glue the individual model data to the Fast-Trips standard will make use of a shared library that has a standard set of writing methods and checks. The grey box, represents the network and demand standard that Fast-Trips will be reading in. The read methods for Fast-Trips will be developed as a part of Task 6 (Software Development). The next step was to agree upon the format that the scripts would write and that Fast-Trips would read so that they would be aligned with each other.

Input Data Flow
Input Data Flow

Source: MTC, PSRC, & SFCTA

» Read More
Not So Fast? Not So Fast...
By Lisa
29 July 2015

The Good!

Translating Fast-Trips from C++ to Python turned out to be a fairly straight forward task. I completed the straight translation within a few weeks, fixed a few bugs in the C++ version, and verified that the Python results were producing the same output as the fixed C++ version.

Voila, a working version of Fast-Trips in Python!

The Bad…

We had always expected Python to not be as fast as C++, but did not anticipate just how many orders of magnitude slower it would be. I have been using a test batch of 121,000 riders in the San Francisco Muni network to test Fast-Trips, which I used to calculate the run times in the image below.

Comparison of Python and C++ Run Times
Comparison of Python and C++ Run Times

Source: MTC, PSRC, & SFCTA

Out of the box, Python was over 20 times slower. However, in order to satisfy our target performance of six hours (for the entire Bay Area…which has several million transit trips per day) we would need to get to a point where Fast-Trips was running much faster than the C++ version.

scary numbers:

  • Performance Target for Bay Area: 6 hours
  • Initial Python Fast-Trips Performance (estimated): 1,666 hours
  • Needed speedup: 300X

Undaunted, we plowed ahead with the search for 300X worth of performance improvements.

» Read More
Communication Station
09 June 2015

When our agencies (MTC, SFCTA, and PSRC) were in the early stages of discussing a potential collaboration between us, there were three primary themes that we were all in agreement on:

  1. using this money for its intended purpose: implementing a planning-ready dynamic network model within a public agency, that is useful and capable of answering important and relevant questions;
  2. making the implementation sustainable from a staffing and operations point of view, so that the investment isn’t lost a few years later; and
  3. sharing the knowledge of what we learn about the viability and issues surrounding implementation of dynamic network models with agencies which weren’t lucky enough to win this grant (or weren’t ready to apply) and with academics and funders.

This post discusses our third pillar: communications.

Target Groups

We want to reach out to, learn from, and also disseminate information to three groups: academics, technical practitioners, and planners/managers. I should emphasize that we seek to both gain information from these sources as well as disseminate it to them.

» Read More
What does Fast-Trips do differently?
01 June 2015

A question we understandably get a lot is what is so different about Fast-Trips compared to what you do now? The generic answer [ for most model development projects] is that it helps us answer important questions relevant to planners and decision-makers that we can’t answer now. Realizing that the lack of specificity in this response leaves a little to be desired, we thought we would dedicate a post to diving a little deeper:

  • what are the specific features that differentiate it from the conventional process?
  • what questions will in answer?

Promising Characteristics of Fast-Trips

1 - Heterogeneity of riders.

What does that really mean?

Fast-Trips uses simulation, which enables it to consider the spectrum of unique combinations of why riders might choose one route over another. It has the ability to know that some riders might prefer shorter walking distances and seats while others will prefer the fastest possible route.

Fast-Trips doesn't assume that everybody is average.
Fast-Trips doesn't assume that everybody is average.

Source: MTC, PSRC, & SFCTA

Furthermore, rather than grouping every individual into a category (“market segment”) that chooses based on the average desire of the people in that category (i.e. all the speed-demons will pick the 38L despite there not being any seats), Fast-Trips has the ability to understand that “speedy” is relative - and that some speed-demons are more speed-driven than others (i.e. some might be okay with a trip that is a minute slower, but where you can get a seat to read your book.

» Read More
Updated Workplan: Completed
07 April 2015

When the Federal Highway Administration released this grant opportunity, they limited the scope of work in the proposal to less than one page. With such a big undertaking, we knew that our first order of business after getting the contracting in place would be to update the workplan with enough detail so that everybody was on the same page, but enough freedom to allow for innovation along the way.

While you can read the whole workplan, I thought it would be interesting to highlight a few interesting (from our perspective) components.

Tasks led by agency staff

Agency staff are task-leaders and managers. Not only are those who are closest to the problem most likely closest to the solution, but agency staff are more likely to develop solutions that work best in the public agency environment and workflow. We are lucky to have a strong cadre of innovative and motivated staff working on this project, but just in case they need help being pointed in the right direction, they can ask for the help of the technical lead or others on the team.

Defined group decision-making process

Since we are a large group coming from different backgrounds and implementation environments, we thought it was important at the outset to define how we would make decisions as a team. The process we agreed on was as follows:

  • Identify important decisions at the get-go and tag them (i.e. transit network data standard)
  • Task-leader is responsible for educating and consulting with the technical team on relevant background research, the pros and cons of potential options, and a proposed direction.
  • Once any concerns from the technical team are ironed out, send a revised proposal to the management team for approval
» Read More
Measuring ourselves
By Diana
07 April 2015

Federal Highways requested that we measure our performance on this project, including both monitoring our progress along the way (Are we on track?) and identifying the results of our efforts (How did it work out?). This post summarizes the performance measures that we selected.

Considerations

We wanted metrics that would tie to both outputs (did we do X?) and outcomes (did our work make a difference in Y?) for three categories:

  • Tool implementation and deployment
  • Capacity building and partnerships
  • Technology transfer / research dissemination

We wanted to use metrics that lend themselves to a definitive and objective answer (i.e. yes, no, 1, 9, 33, etc)

We wanted to be able to conduct the evaluation without a significant amount of effort (since this request was added after we had done our budget)

» Read More
Working Together
By Dave
01 March 2015

Never underestimate the benefit of compromising in the name of collaboration. This is a favorite saying of mine. The benefits of collaborating across agencies are so tempting: learning from your peers, building a more sustainable product, sharing risk. But the downsides are very real: you must compromise – on big, important decisions. This is difficult for program managers, like myself, who are used to steering projects – not co-steering projects.

In this post I talk a bit about what we’ve learned to date on the Fast-Trips project. I hope my words help at least one peer agency out there in a similar position.

Why did we decide to collaborate?

A pre-condition for successful collaboration is proper motivation. Our key reasons are as follows:

  1. Each agency brings a unique and useful perspective, specifically:
    • SFCTA brings experience with dynamic network models generally and Fast-Trips specifically. They also operate in a jurisdiction with very real transit crowding problems.
    • MTC is a large, sophisticated MPO, with top-notch in-house contracting, legal, and travel modeling staff. Further, we want to better leverage travel model research done by SFCTA for the benefit of our region.
    • PSRC brings software expertise, a talented, diverse staff, and, of course, a non-Bay-Area-perspective.
    • University of Texas Network Modeling Center brings a key collaborator from the original Fast-Trips development work and a deep reserve of transportation research skills.
  2. Shared risk: I often say that MPO modelers should not do anything they cannot convince two of their peers to go along with. Convincing others should prevent unwise investment decisions.
  3. Shared contingency: things come up at public agencies, diverting resources from planned activities. We hope at least two of us will be fully engaged with the project at any given time.
  4. More eyeballs: generally speaking, the more eyeballs you put on something, the more likely you are to find errors and improve ideas.
  5. Peer-to-peer learning: we work in a small community and need to take every opportunity we can to learn from each other. Working directly with each other is more rewarding than listening to each other talk at conferences.
» Read More