1. Computing needs of transport planners

2. Open source tools in statistics/transport

3. Case studies (stplanr + PCT)

• But first some context
• Then let's talk solutions

• The transport system is not working well for anyone

• To 'fix' it, policy interventions are needed

• Policy interventions can be more effective when locally targetted

• However, there are infinite potential interventions at the local level
• Evidence is needed to prioritise among the infinity of options

• Only a systematic and objective evidence base will do

• And that means data + statistics! 🔢

• And that means computing 🖥️

• And that means human-computer interaction 👨👩💻

• And that means software is vital for sustainable transport policy

• Nationally uniform transport policies have several advantages
  • Avoid 'mixed messages'
  • In some cases essential (e.g. fuel prices)
  • We're all in it together
• BUT, locally specific transport policies can boost cost-effectiveness
  • Should walking/cycle paths be the same width throughout?
  • Point facilities will be used more if they're located sensibly (e.g. bus stops)
  • Cycle share schemes much more effective when spatial configuration matches urban form

• Transport eats time. We spend on average 6% of our lives (sleeping/resting: 37%; commuting: 1%; paid work: 25%) (King and Bergh 2017).

• Transport eats space. More than half many US cities spaces are occupied by parking (~20%) and streets (~40%). In Texas, for example, 21.3% of land space was taken by surface parking (Source: oldurbanist.blogspot.co.uk)

• Transport eats energy. In 2015 it accounted for 39.9% of final energy consumption (DECC).

Final energy consumption (excluding non-energy use) was 1.9 per cent higher than in
2014 [0.3% seasonally adjusted], with rises in the domestic, transport and services sectors but with a fall in the industrial sector. The rise in consumption was due to increased
transport demand likely due to lower petroleum prices.

(DECC 2016)

• Book by Boyce and Williams (2015)

• "urban travel forecasting was definitely 'where the action was' for young transportation engineers and planners entering the field in the 1960s" (Boyce and Williams 2015, 67).

• heavily restricted by computing power

• no consideration of walking or cycling

Source: Who will save us from transport models (Hollander 2015)

See also work by Robert Bain

• Are black boxes

• Tools are blunt

• Are sometimes too complex!

• Implications for others

• General purpose products that have found many transport applications

• Python
• R
• QGIS

• Dedicated transport programs

• MATSim
• SUMO

• Add-on packages that providing transport planning capabilities to existing (mature) programs

• stplanr
• AequilibraE
• activitysim

• Open data
• Publicly accessible
• The wider community

• We can learn from 'early adopter' sectors

install.packages("stplanr")

library(stplanr)

## Loading required package: sp

data("flow")
nrow(flow)

## [1] 49

flow[1:3, 1:3]

##        Area.of.residence Area.of.workplace All
## 920573         E02002361         E02002361 109
## 920575         E02002361         E02002363  38
## 920578         E02002361         E02002367  10

data("cents")
cents@data[1:2,]

##       geo_code  MSOA11NM percent_fem  avslope
## 1708 E02002384 Leeds 055    0.458721 2.856563
## 1712 E02002382 Leeds 053    0.438144 2.284782

desire_lines = od2line(flow = flow, zones = cents)
plot(desire_lines)
points(cents)

See http://www.pct.bike/

• Setup:

# load data
rf_schools = readRDS("~/npct/pctSchoolsUK/pctSchoolsApp/rf_leeds_schools_all.Rds")
rf_commute = readRDS("~/npct/pct-data/west-yorkshire/rnet.Rds")

# create bounding box polygon
bbox_poly = stplanr::bb2poly(rf_schools)
proj4string(bbox_poly) = proj4string(rf_commute)

## Warning in ReplProj4string(obj, CRS(value)): A new CRS was assigned to an object with an existing CRS:
## +init=epsg:4326 +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0
## without reprojecting.
## For reprojection, use function spTransform

# spatial subset
rf_commute = rf_commute[bbox_poly,]

## tmap mode set to interactive viewing

Practical reasons

• It's cheaper
• Faster evolving
• More robust: more eyes on it

Philosophical reasons

• Transport Planning is intertwined with democracy and power relations
• People will try to manipulate it for own benefits - transparency/reproducibility = key
• Control of public sector organisations over their data and analysis capabilities
• Hypothesis: Use open source -> greater good

• It's not user friendly
• It's not where jobs are (now)
• It doesn't have the support of trusted suppliers
• Anyone can come and 'hack' your code!
• Developer's don't get paid
• Any more?

See https://twitter.com/thosjleeper/status/793107956632084480

• Both require 'systemic' change (Beddoe et al. 2009)
• They seem like technical problems on the outset but are highly political
• It takes time, commitment and persuasion
• The benefits take time to realise

Could there be a mutually reinforcing feedback loop:

Shift in (digital) infrastructure -> change in behaviour and priorities?

Most people agree that:

• Transport models are not working optimally
• Open source software is 'good'
• It would be good to save money and switch

Areas of disagreement:

• How to get there
• Whether it's a slow transition or 'cold turkey'
• Who should write the code
• Any volunteers (or funders)?

• Incentivise low carbon, healthy travel

• Build cycle paths (where they are most needed, of appropriate design)
• Embed walking and cycling - urban realm improvements, facilities sign-posting
• Subsidise car sharing solutions

• Disincentivise high carbon solutions

• Creative approaches > - Reducing worktime hours: "The three best performing scenarios were those that involved employees working a four-day week as they enabled companies to reduce energy use, and employees to reduce commuting" (King and Bergh 2017).