Travel demand

A/B Street simulates people following a schedule of trips over a day. A single trip has a start and endpoint, a departure time, and a mode. Most trips go between buildings, but the start or endpoint may also be a border intersection to represent something outside the map boundaries. The mode specifies whether the person will walk, bike, drive, or use transit. Without a good set of people and trips, evaluating some changes to a map is hard -- what if the traffic patterns near the change aren't realistic to begin with? This chapter describes where the travel demand data comes from.

See these slides for this this recorded talk for up-to-date information as of March 2022.

Scenarios

A scenario encodes the people and trips taken over a day. See the code.

See here for details how vehicles are initially placed and used by the driving trips specified by the scenario.

Data sources

Seattle: Soundcast

Seattle luckily has the Puget Sound Regional Council, which has produced the Soundcast model. They use census stats, land parcel records, observed vehicle counts, travel diaries, and lots of other things I don't understand to produce a detailed model of the region. We're currently using their 2014 model; the 2018 one should be available sometime in 2020. See the code for importing their data.

TODO:

  • talk about how trips beginning/ending off-map are handled

Berlin

This work is stalled. See the code. So far, we've found a population count per planning area and are randomly distributing the number of residents to all residential buildings in each area.

Proletariat robot

What if we just want to generate a reasonable model without any city-specific data? One of the simplest approaches is just to spawn people beginning at residential buildings, make them go to some workplace in the morning, then return in the evening. OpenStreetMap building tags can be used to roughly classify building types and distinguish small houses from large apartments. See the proletariat_robot code for an implementation of this.

Census Based

Trips are distributed based on where we believe people live. For the US, this information comes from the US Census. To take advantage of this model for areas outside the US, you'll need to add your data to the global population_areas file. This is one huge file that is shared across regions. This is more work up front, but makes adding individual cities relatively straight forward.

See the code for the very simple activity model using the census data.

Preparing the population_areas file

See this script for updating or adding to the existing population areas. Once rebuilt, you'll need to upload the file so that popdat can find it.

Grid2Demand

Collaborators at ASU are creating https://github.com/asu-trans-ai-lab/grid2demand, which does the traditional four-step trip generation just using OSM as input. The output of this tool can be directly imported into A/B Street. From the scenario picker, choose "Import Grid2Demand data" and select the input_agents.csv file.

abstr

Robin Lovelace is working on an R package to transform aggregate desire lines between different zones into A/B Street scenarios.

Desire lines (for the UK)

The UK has origin/destination (aka desire line) data, recording how many people travel between a home and work zone for work, broken down by mode. We have a tool to disaggregate this and create individual people, picking homes and workplaces reasonably using OSM-based heuristics. See the pipeline for details about how it works. The code that parses the raw UK data is here. If you have similar data for your area, contact me and we can add support for it!

Custom import

See here.

Modifying demand

The travel demand model is extremely fixed; the main effect of a different random number seed is currently to initially place parked cars in specific spots. When the player makes changes to the map, exactly the same people and trips are simulated, and we just measure how trip time changes. This is a very short-term prediction. If it becomes much more convenient to bike or bus somewhere, then more people will do it over time. How can we transform the original demand model to respond to these changes?

Right now, there's very preliminary work in sandbox mode for Seattle weekday scenarios. You can cancel all trips for some people (simulating lockdown) or modify the mode for some people (change 50% of all driving trips between 7 and 9am to use transit).

Research

Future ideas

UK data sources

Currently A/B Street is using 2011 flow data -- specifically WU03UK (the location of usual residence and place of work by method of travel to work).

There are some others to consider:

  • WF01AEW_oa from here has even more granular home<->work zones
  • https://www.nomisweb.co.uk/sources/ukbc could be used to understand how many people work at different places
  • NTEM has forecasted OD pairs
  • QUANT and SPENSER are two other population and activity/time-use datasets, used by another project I'm working on called RAMP

Use cases

What're all the uses of an accurate travel demand model? And when might it be helpful to represent synthetic people with more info than just their daily trips?

  • the obvious: traffic simulation
  • Ungap the Map's mode shift calculation -- look for short driving trips, then check the network to see if there are common gaps that might prevent cycling. Do we need to understand the demographics of people taking these "possible to switch" trips?
  • the LTN tool's impact predicton -- without using traffic simulation, just calculate routes before and after changes
  • Equity and health analysis
    • If we think some interventions might cause higher traffic (and thus noise/air pollution and safety issues) on major roads, who lives near the affected area?

Validation / calibration

How do we judge whether a given travel demand model is "good"?

For comparing two different models, one idea is to "re-aggregate" individual trips from each of them and see if overall counts look similar. For example, partition the map into zones (maybe using zones that one of the models being compared used originally, or maybe making up new ones), count the trips between zones, and compare between models -- grouping by departure time and mode, or not.

This comparison could sanity check that roughly the same number of people live and commute to the same places. But it's not a very satisfying judgment, because it's not really what we're trying to measure. I think the validation that makes sense is to plug the model into an analysis we actually care about and where we have real observations. One of the simplest -- and most useful for LTN impact prediction, particularly -- is just estimating traffic volumes at different roads and intersections.