https://github.com/robinlovelace/open-gat
Open source software for geographic transport data analysis and planning
https://github.com/robinlovelace/open-gat
review software transport transport-planning
Last synced: about 1 year ago
JSON representation
Open source software for geographic transport data analysis and planning
- Host: GitHub
- URL: https://github.com/robinlovelace/open-gat
- Owner: Robinlovelace
- License: gpl-3.0
- Created: 2019-05-09T08:18:18.000Z (about 7 years ago)
- Default Branch: master
- Last Pushed: 2020-11-08T22:57:02.000Z (over 5 years ago)
- Last Synced: 2025-04-03T16:12:21.227Z (about 1 year ago)
- Topics: review, software, transport, transport-planning
- Language: TeX
- Homepage: https://doi.org/10.1007/s10109-020-00342-2
- Size: 2.88 MB
- Stars: 90
- Watchers: 15
- Forks: 16
- Open Issues: 1
-
Metadata Files:
- Readme: README.Rmd
- License: LICENSE
Awesome Lists containing this project
README
---
title: "Open source tools for geographic analysis in transport planning"
date: '`r Sys.Date()`'
# header-includes:
# - \usepackage{coloremoji}
output:
# bookdown::github_document2: default
bookdown::pdf_document2:
latex_engine: xelatex
header-includes:
- \usepackage{amsfonts}
# word_document: default
bibliography:
- references.bib
---
```{r, include=FALSE}
library(tidyverse)
```
```{r, echo=FALSE, include=FALSE, eval=FALSE}
pdftools::pdf_subset(input = "README.pdf", pages = 1:2, output = "title-page.pdf")
browseURL("title-page.pdf")
citr::tidy_bib_file(rmd_file = "README.Rmd", messy_bibliography = "~/uaf/allrefs.bib", "references.bib")
```
```{r, include=FALSE}
knitr::opts_chunk$set(echo = FALSE, warning = FALSE)
online = curl::has_internet()
```
# Abstract {.unnumbered}
Geographic analysis has long supported transport plans that are appropriate to local contexts.
Many incumbent 'tools of the trade' are proprietary and were developed to support growth in motor traffic, limiting their utility for transport planners who have been tasked with 21^st^ Century objectives such as enabling citizen participation, reducing pollution, and increasing levels of physical activity by getting more people walking and cycling.
Geographic techniques --- such as route analysis, network editing, localised impact assessment and interactive map visualisation --- have great potential to support modern transport planning priorities.
The aim of this paper is to explore emerging open source tools for geographic analysis in transport planning, with reference to the literature and a review of open source tools that are already being used.
A key finding is that a growing number of options exist, challenging the current landscape of proprietary tools.
These can be classified as command-line interface (CLI), graphical user interface (GUI) or web-based user interface (GUI) tools and by the framework in which they were implemented, with numerous tools released as R, Python and JavaScript packages, and QGIS plugins.
The review found a diverse and rapidly evolving 'ecosystem' tools, with 25 tools that were designed for geographic analysis to support transport planning outlined in terms of their popularity and functionality based on online documentation.
They ranged in size from single-purpose tools such as the QGIS plugin AwaP to sophisticated stand-alone multi-modal traffic simulation software such as MATSim, SUMO and Veins.
Building on their ability to re-use the most effective components from other open source projects, developers of open source transport planning tools can avoid 'reinventing the wheel' and focus on innovation, the 'gamified' A/B Street simulation software, based on OpenStreetMap, a case in point.
The paper concludes that, although many of the tools reviewed are still evolving and further research is needed to understand their relative strengths and barriers to uptake, open source tools for geographic analysis in transport planning already hold great potential to help generate the strategic visions of change and evidence that is needed by transport planners in the 21^st^ Century.
# Introduction: geographic analysis in transport planning {#intro}
Transport planning is an applied discipline involving developing local policies and the design and placement of physical infrastructure including ways --- highways, railways, cycleways and footways --- for the greatest economic, social and environmental benefit [@oflaherty_transport_1997; @parkin_designing_2018]. Planning also involves thinking about the future, envisioning scenarios of change and making the case for change [@timms_imagineering_2014]. Successful transport plans are therefore a combination of geographically specific recommendations (e.g. "build this way here") and long-term strategies guided by citywide, regional and national visions (e.g. "imagine the benefits of making the city free from private cars by 2030"). The rewards can be great: transport planners who have designed --- and helped to implement --- plans appropriate to the needs of an area leave a legacy that will benefit people and the environment for generations to come.[^1]
[^1]: Articles about successful transport planners illustrate the point. Ben Hamilton-Baillie (1955 - 2019), for example, was an influential transport planner and street designer whose obituary emphasised the "hundreds of thousands of people who are safer and happier as a result of his achievements" (Tim Stornor, quoted in [TransportExtra](https://www.transportxtra.com/publications/local-transport-today/news/60655/obituary-ben-hamilton-baillie/)).
Transport planning can be considered as "more of an art than a technique", although *good* transport plans also rely on robust analysis and modelling of sometimes large and usually spatial input datasets [@ortuzars._modelling_2011]. Ways and other pieces of transport infrastructure must *go somewhere*; transport planning involves consideration of where investment and other interventions are most needed. Tools for geographic analysis have been used in transport planning since at least the 1990s, when local transport planning bodies in the United States started using geographic information systems (GIS) software to support their transport planning activities [@anderson_applying_1991], taking advantage of newly available software and hardware such as the Intel 80386 processor (first released in 1985) which could run early proprietary GISs such as 'SPANS' [@ebdon_spans_1992].
Despite the inherently geographic nature of movement, and the growth of GIS in transport planning, the importance of geographic in transport systems has long been overlooked [@rodrigue_geography_2013], notwithstanding efforts to formalise the field of 'GIS-T', described in the next section. Geographic methods --- such as origin-destination modelling, route assessment and spatial network analysis --- are prominent in the literature, providing evidence for a range of transport planning interventions [e.g. @jappinen_modelling_2013; @larsen_build_2013; @tribby_highresolution_2012]. But there has been less research into digital geographic *tools*, as discussed in Section \@ref(the-current-landscape), despite the fact that geographic methods must be accompanied by software and a user interface if they are to be of use in practice.
A range of data driven transport planning approaches has evolved in recent years to take advantage of new datasets and technologies. Large movement datasets from disruptive 'ride hailing' firms have been used to better understand parking patterns [@aryandoust_cityscale_2019]; 'deep learning' has been used to forecast demand for transport services in near real-time [@liao_largescale_2018]. Such novel geographic approaches can be defined as Geographic Data Science, a still emerging field that calls for the tighter integration between data science and geographic research [@singleton_geographic_2019]. While there is much academic activity in this direction, the extent to which new geographic tools have gained traction in practice, and in transport planning practice in particular, is debatable. In this context, the goal of this paper is to add to the literature on geographic tools in transport planning, with a focus on open source options.
At this point some definitions are in order. Although ubiquitous in the literature, terms such as 'tool', 'software' and 'model' are often used interchangeably, relying on the (potentially unsafe) implicit assumption that everyone shares the same idea of what they mean [see @salter_digital_2009 for an example]. For the purposes of this paper, a **tool** is a broad term referring to a modular piece of software or online service; a **model**, by contrast, is method or process that is expounded in theoretical terms; **software** is the collection of computer instructions that underlies digital tools, encoded in publicly available and transparent programming languages (in **open source software**) or in a 'binary' file that has "limits against usage, distribution, and modification that are imposed by its publisher" [@dhir_adoption_2017], the inner workings of which are obfuscated from the user (in **proprietary software**). An increasingly used but seldom defined term in this context is **ecosystem** which, following @franco-bedoya_open_2017, we define as the wider community of people organizations that support the development of open source software. The paper focuses on tools, as opposed to software or software ecosystems, because tools are tangible and widely understood (unlike software ecosystems) entities that the end user sees (as opposed to software, which is a rather esoteric concept).
The focus on *open source* tools for geographic analysis in transport planning is timely because this is an area of rapid growth, as outlined in Section \@ref(open-source-tools). The topic has yet to be explored in the academic literature, to the best of the author's knowledge. A deeper reason that transport planning benefits from levels of transparency and citizen participation that are more easily reached with open source solutions than proprietary solutions [@peters_citizen_2020]. Transport planning involves decisions about how public funds, spaces and other shared resources are used. It is, to a greater or lesser extent, part of wider democratic processes that reflect contemporary political and societal priorities [@legacy_there_2016]. These priorities have shifted substantially over the past few decades, meaning that transport plans based on out-of-date ideas or faulty model assumptions (such as the assumption that congestion can be tackled by building more roads) can lead to unwanted impacts (such as increased congestion), which can be fatal [@hollander_transport_2016].
The importance of transparency and democratic accountability in transport planning (and hence the importance of open source tools in transport planning) has increased alongside wider campaigns for evidence-based decision making and 'participatory democracy' [@monbiot_out_2017; @hackl_promoting_2019], and growing evidence that transport systems cause substantial damage to the environment and human health and wellbeing. Roads are now the "leading cause of death for children and young adults aged 5-29 years" with 1.35 million people killed and tens of millions injured and disabled each year due a range of factors including unsafe speeds, weak road traffic laws, lack of enforcement and poor infrastructure that forces pedestrians and cyclists to mix with motorised modes [@worldhealthorganization_global_2018]. The air pollution impacts could be even greater, with a growing body of research linking air pollution to Alzheimer's disease, lung cancer and heart disease among hundreds of millions of sufferers worldwide [@kampa_human_2008; @kilian_emerging_2018]. Transport is responsible for a quarter of global greenhouse gas emissions and growing [@harrison_environmental_2017], and is one of the hardest sectors to decarbonise [@moriarty_prospects_2008], meaning that reducing transport energy use is an urgent priority.
Transport planning is inherently embedded within local geographic contexts because transport systems, and associated networks of physical infrastructure, are highly localised [@barthelemy_spatial_2011; @levinson_network_2012] and to some degree dynamic [@xie_evolving_2011] phenomena. Transport planning is therefore fundamentally a *geographic activity*. All accurate geographic coordinates are defined with reference to the Earth's surface, either via geographic or projected coordinate systems [@sherman_desktop_2008]. By extension, transport planning is a geographic enterprise.
The influential textbook *Modelling Transport* outlines the main stages of transport planning as follows [@ortuzars._modelling_2011].
1) problem formulation
2) data collection
3) modelling/analysis
4) evaluation
5) implementation of solutions
Each of these stages, illustrated in Figure \@ref(fig:schematic), has geographic components. The 3^rd^ stage, can refer to at least three distinct processes: the 'four stage' transport model (left box); scenario modelling (central box) or geographic analysis and modelling (right box, Figure \@ref(fig:schematic)). The wider point is that geographic techniques can supplement and in some cases replace traditional modelling, and the classic four stage transport model. Many of the inputs (datasets with geographic coordinates) and outputs (maps and geographically specific recommendations) shown in Figure \@ref(fig:schematic) are spatial, suggesting the importance of geographic tools throughout the transport planning process.
```{r schematic, fig.show='hold', out.width="100%", fig.cap="Schematic diagram illustrating the modelling process, geographic analysis and the four-stage in the context of the wider transport planning process (adapted from Ortúzar and Willumsen, 2011, with the 'Geographic analysis and modelling component' added for this paper).", fig.align='center'}
# knitr::include_graphics(c("4stage.png", "geo-4stage.png"))
knitr::include_graphics("flow-diagram.pdf")
# knitr::include_graphics("flow-diagram.png")
```
**Formulation of the problem** (stage 1 in the transport planning process illustrated in Figure \@ref(fig:schematic)) and identification of the scope of solutions that the transport planning process can propose is inherently geographic. The first step of many projects is defining the 'region of interest'. This step has important implications because it can focus the analysis on areas where solutions are most likely to be implemented and, conversely, highlight the potential for inter-regional collaboration. Although the region of interest may be pre-determined by administrative boundaries over which a planning authority presides, geographic analysis this first stage in the transport planning process can help refine the definition of the 'region of interest' to include different 'spheres of influence' such as the wider catchment area, the administrative region, and the area that is the focus of the study.
**Data collection** (stage 2) is an explicitly geographical activity, although in some cases the geographic components of valuable data are not used (origin-destination datasets in which the coordinates of origins and destinations are excluded represent a common example). Geographic analysis tools can support this stage not only by providing descriptive overviews of the datasets available to planners (and their limitations such as parts of a city lacking in data), but by flagging places where additional monitoring is needed [e.g @lindsey_minnesota_2013].
Likewise, **modelling** (stage 3) is a central component of data-driven transport planning. Whether the modelling involves a four stage model, statistical modelling or geographic analysis, it inevitably contains some geographic analysis. Geographic analysis is implicit in the classic four-stage model: 1) trip generation (the number of trips generated by each zone in a region) is influenced by geographic factors such as number of buildings in the direct surroundings; 2) the distribution of these trips to destinations depends on explicitly geographic factors such as absolute and relative distances; 3) mode split is influenced by geographic factors such as the gradient and motor traffic speeds and volumes associated with routes between origins and destinations; and 4) assignment to the route network clearly depends on a realistic representation of footways, cycleways, highways and other geographic entities such as traffic lights that affect route choice. Likewise statistical modelling includes consideration of trip distances and destinations, which imply some level of geographic analysis. Four-stage and statistical modelling options can be supplemented by **geographic analysis and modelling**, something that has been recognised since at least the 1990s [@anderson_applying_1991]. Critical to any modelling exercise are scenarios, which can be either 'global' (such as a nationwide increase in fueld tax) or 'local' (such as the creation of new public transport routes on specific roads) in nature. The latter type of scenario require geographical inputs, such as simulating a new cycleway or bus stop. These are arguably more tangible and relevant to the city and regional levels at which many transport plans are developed than abstract 'global' changes [e.g. @larsen_build_2013].
Geographic considerations are particularly important in stage 4, **evaluation of solutions and recommendations** to policy makers, but are often overlooked. If recommendations resulting from an 'optimal' model have geographically uneven impacts, it risks exacerbating existing spatial inequalities. Geographic analysis of the results of the transport planning process, in addition to geographic analysis of input data, can support more spatially equitable development which could have a co-benefit of reducing travel demand: wage and other differences between cities are a major driver of (often energy intensive) inter-city travel demand [@schmutz_frictional_2019].
And of course the the implementation of effective solutions relies on results that are specific, including being geographically specific and presented in clear and accurate geographic visualisations [@pensa_supporting_2013].
The stages represented in Figure \@ref(fig:schematic) have been criticized for being simplistic, linear and 'top-down', with particularly strong criticisms focusing on the lack of stages for impact assessment and public participation [@lofgren_considering_2018; @tornberg_making_2018], and more sophisticated representations of key stages in the planning system have been expounded for some time [@batty_planning_1995]. However, there is little doubt that the 'formulate → collect → model → evaluate → implement' approach continues to be popular and that, within this framework, each stage (particularly 'modelling' which includes geographic analysis and modelling) could benefit from increased access to geographic insights. Due partly to data and computing limitations (outlined in the next section) geographic considerations are not always considered, with consequences for the solutions resulting from the transport planning process and the extent to which they adapt to local geographic factors. Lack of access to, knowledge of and skills in the use of tools for geographic analysis represent another reason why geographic factors may be excluded from transport plans (although evidence of the tools that transport planners use and can use is scarce, suggesting areas of future research, as discussed in Section \@ref(conclusion)). There *is* evidence that these 'barriers to entry' for geographic analysis --- at high resolution based on high quality data and high performance software --- are being removed, as outlined in Section \@ref(open-source-tools). In this context, the aim of this paper is to explore emerging open source tools for geographic analysis in transport planning, with reference to the literature.
The increased availability of open access geographic data and high performance computing technologies (in addition to policy drivers increasing demand for geographic analysis) over the last few decades is discussed in the next section. Despite the increasing availability of open source options, proprietary tools still appear to dominate transport planning in practice, as we will see in Section \@ref(the-current-landscape). The nature and functionality of open source tools for geographic analysis in transport planning is outlined in Section \@ref(open-source-tools). Section \@ref(conclusion) concludes by summarising the state and future prospects of open tools in transport planning, highlighting gaps in the current crop of open source options, and flagging ways of getting involved to improve the provision of open source tools for the benefit of researchers, companies, governments and interested citizens with stakes in transport planning processes.
```{r, eval=FALSE}
library(gtrendsR)
# res_all <- gtrends(c("transport geography", "geographic information systems", "geocomputation"), time = "all")
res <- gtrends(c("transport geography", "geographic information systems", "spatial planning"), time = "2010-01-01 2019-08-01")
head(res$interest_over_time)
tail(res$interest_over_time)
head(res$interest_over_time$time)
class(res$interest_over_time$time)
unique(res$interest_over_time$keyword)
nrow(res$interest_over_time) / 3 / 12
nrow(res$interest_over_time) / 3
res$interest_over_time$date = rep(seq(from = as.Date("2010-01-01"), to = as.Date("2019-07-01"), length.out = 116), 3)
start_rows = 1
end_rows = nrow(res$interest_over_time) / 3
res$interest_over_time$hits_smoothed = c(
zoo::rollmean(res$interest_over_time$hits[start_rows:end_rows], 6, fill = "extend"),
zoo::rollmean(res$interest_over_time$hits[(start_rows:end_rows) + end_rows], 6, fill = "extend"),
zoo::rollmean(res$interest_over_time$hits[(start_rows:end_rows) + 2 * end_rows], 6, fill = "extend")
)
ggplot(res$interest_over_time) +
geom_line(aes(date, hits_smoothed, colour = keyword), size = 2) +
ylab("Relative number of hits") +
theme(legend.position = c(0.7, 0.8))
ggplot2::ggsave("google-trends.png", width = 6, height = 4)
```
```{r, fig.cap="Relative level of interest in search terms related to 'geographic information systems', 'geocomputation' and 'transport geography' inferred from google search data, obtained with the gtrendsR R package. Code to reproduce the plot is hosted in this paper's code repository.", out.width="70%"}
# knitr::include_graphics("google-trends.png")
```
# Policy and technological drivers
Two major drivers of change in transport planning tools have historically been technological development and shifting political priorities [@boyce_forecasting_2015].
Environmental, health and equality regulations --- which can be seen as a manifestation of political change --- have also influenced transport planning practice and some specific transport planning tools have emerged to tackle particular issues [e.g. @vandenbulcke_mapping_2009]. Environmental concerns, including fears about the impact of climate change, have risen up policy agendas in recent years, meaning that such environmental policy drivers a likely to become more important in the coming years.
In parallel, the 'obesity crisis' and mounting evidence of the health benefits of physical activity have provided impetus to plans that prioritise walking and cycling, with environmental co-benefits.
There have also been calls for more 'bottom-up' and participatory approaches, although transport planning practice has been slow to change in this direction [@legacy_there_2016].
No less important is the demand for localised results; while a national transport model can provide a high level overview of the transport system for policy-makers, tools that provide geographically specific results, potentially down to the street level, can support transport planners 'on the ground'.
Environmental and (local participatory) political factors drive demand for transport planning tools that enable geographic analysis: sustainable modes such as walking and cycling (and to a lesser extent public transport) require greater consideration in the spatial variation in trip origins and destinations at high levels of geographic resolution: analysis with limited consideration of geographic factors, such as the spatial distribution of locations within walking distance of new infrastructure, is less able to inform investment in active travel or provide citizens with localised information.
A final driver of demand for such tools is technology.
Rapidly emerging digital technologies could transform transport planning, with two-way communications between planning authorities and citizens, and even peer-to-peer communications on transport planning issues, now feasible.[^2] These drivers of change provide the context in which open source tools for transport planning are being developed.
[^2]: See for an example of such a peer-to-peer transport planning tool.
## Political drivers
The history of transport modelling shows that transport planning software was originally designed in the late 1950s and onwards to plan for "increased use of cars [for personal travel], and trucks for deliveries and goods movement" [@boyce_forecasting_2015].
Policy drivers have changed dramatically since then:
climate change mitigation, air quality improvement and public health are prioritised in the emergent 'sustainable mobility paradigm' [@hickman_transitions_2011; @johansson_impacts_2017; @departmentfortransport_decarbonising_2020].
Yet many traditional transport planning tools focus on motor traffic, emphasising travel time savings impacts over environmental and health savings [@hall_saturn_1980; @ortuzars._modelling_2011], often at low levels of geographic resolution [@hollander_transport_2016].
These observations have led to criticism of transport models which are deemed unable to represent transport network details such as pavement and way widths that are needed effectively design for active transport [@parkin_designing_2018] or capture [community](https://www.researchgate.net/publication/246480147_Inside_the_Blackbox_Making_Transportation_Models_Work_for_Livable_Communities) input [@beimborn_blackbox_1996].
Tools for 21^st^ Century transport planning need to tackle very different questions, such as: What are the barriers preventing people from switching to more sustainable modes of transport, and where are these barriers located? How are transport behaviours likely to shift in the future, in response to technological changes including autonomous vehicles and the continued rise of online working? Where will different types of intervention be most effective? And how can citizens be engaged in transport decisions? Tools that can help answer these questions are becoming an increasingly important part of the transport planner's cabinet [@tebrommelstroet_developing_2008].
As the gap between what the science seems to say is necessary in the near future and the reality of polluting and unhealthy transport systems grows, so does the need for transparent models that stand up to scrutiny and enable participation and informed debate. This has been well documented in with respect to energy models by @morrison_energy_2018, who observed that "opaque policy models simply engender distrust". The same could be said of transport models, driving demand for tools that are open to public scrutiny and community involvement. In parallel, growing awareness of the need for sustainable transport planning solutions has also driven demand for geographically locallised transport planning tools.
## Demand for localised results
With the emphasis shifting to reducing travel by building 'liveable' communities and enabling mode shift [@sallis_use_2016], localised and geographically specific considerations may become increasingly prominent in future plans. To illustrate this point, imagine being the mayor of a major city that has declared a 'climate emergency' and who has been given the task of leading the transition away from fossil fuels [@hadfield_financing_2019]. Policies such as carbon taxes would undoubtedly be needed at the national level but your focus would naturally be on the bounds of the local authority over which you have some power. Except for specific national transport policies such as fuel tax, transport policies tend to have geographic outcomes (to build new cycle infrastructure, for example, which must go somewhere) and this is especially so for low-carbon transport plans which tend to operate over distances of hundreds of metres rather than dozens of kilometres, due to inherent limits in the speeds of active modes [@iacono_measuring_2010].
Even high level national plans for a walking and cycling revolution must be implemented locally, down to the level of streets, as illustrated by the still ongoing local implementation of Dutch cycling ambitions [@pucher_making_2008]. The political-democratic and local-geographic aspects of transport planning can be considered in isolation, but an integrated approach is necessary for effective policies [@hull_policy_2008]. This is well illustrated by prominent Mayoral transport policies in cities such as London,[^3] Paris[^4], and Bogotá,[^5] where geographically specific interventions (such as congestion charges in carefully demarcated central zones) combined with citywide vision have enabled modal shift.
[^3]: Transport is a major electoral issue in London and the current Mayor, Sadiq Kahn, has made tackling air pollution a policy priority. See [tfl.gov.uk/corporate/about-tfl/the-mayors-transport-strategy](https://tfl.gov.uk/corporate/about-tfl/the-mayors-transport-strategy).
[^4]: The current Mayor of Paris, Anne Hidalgo, sees transport as a priority and has plans to make public transport free. See [paris.fr](https://www.paris.fr/rechercher/transport).
[^5]: Bogotá has an innovative and prominent transport policy, led by the two times mayor Enrique Peñalosa, who has led the roll-out of major bus and cycleway projects in the city. See [sitp.gov.co](https://www.sitp.gov.co/).
With issues such as climate change, air pollution, obesity and social inequalities high on the political agenda, and the benefits for 'early adopters' of evidence-based interventions to accelerate the shift away from the motor car in cities such as London, Paris and Bogotá, pressure is growing on local, city and national transport planning departments to act. But what should they do, and where should they intervene? Geographical data and to some extent analysis (e.g. calculating distances) was integral to this 'computational transport planning' activity, but input datasets were limited in size and accuracy. Partly in response to such drivers for geographic analysis in transport planning, there have been various attempts to define a more applied GIS approach transport research. @miller_potential_1999 advocated a new field, GIS for Transport (GIS-T), posited as an academic field at the interface between transport planning and GIS. Although the label gained limited traction in academia or practice, Harvey Miller's call for a shift to methods and tools has been answered in the 2000s and 2010s by researchers who have developed ideas and software that transport planners can actually use, including the Australian Research Infrastructure Network (AURIN), which is widely used for transport planning and public health research in Australia [@pettit_australian_2014] and the Propensity to Cycle Tool (PCT, publicly available, including source code, at [www.pct.bike](https://www.pct.bike)) [@goodman_scenarios_2019].
## Technological drivers
Technological change has increased the capabilities of transport planners since the the beginning of the discipline, with transport planning tasks being an early use case of mainframe computers [@boyce_forecasting_2015]. With unprecedented access to increasingly detailed datasets on transport behaviours and infrastructure, transport planners today require tools that enable them to make sense of this 'data revolution' [@transportsystemscatapult_transport_2015]. The sheer volume and complexity of new datasets require new approaches that can scale and integrate multiple data sources [@lovelace_big_2016]. Advances in software and hardware allow not only for current transport systems to be modelled at high temporal and geographic resolution, but for future scenarios and 'model experiments' to be developed, which can support identification and implementation of the most effective interventions [@klosterman_what_1999].
With the explosion in open source software, which has risen to prominence data science, policy, data and technological drivers are pushing for geographic analysis to be better integrated in transport planning tools, alongside wider shifts for towards more data driven, transparent and democratically accountable transport planning workflows. At present this dream is far from reality, despite the long history of geographic methods, public involvement and technological innovation in transport planning.
```{=html}
```
# The current landscape
In broad terms, digital transport planning tools are like any other computer program in that they take inputs which are processed to generate outputs [@knuth_art_1997]. The broader term 'transport model' is sometimes used interchangeably with transport software but in this paper we follow [@hollander_transport_2016] in using 'model' to refer to the theories and mathematics underlying transport planning software, rather than the software that implements the model.[^6] In relation to the narrower concept of 'algorithm', transport planning software can be seen as a computing environment or system that provides a user interface to run a range of algorithms interactively on a range of input datasets to generate outputs that can feed into the wider transport planning process [@boyce_forecasting_2015].
[^6]: There is of course a close relationship between transport planning software and models because theoretical models can inform the direction of software developments, as was the case with the development of spatial interaction models [@boyce_forecasting_2015]. Conversely, 'upstream' developments in computer languages affect the range of models that can be implemented, as can be seen with the current shift towards cloud-based and more visual and interactive transport models such as the open source [Streetmix](https://streetmix.net) and the Institute of Transport Engineers endorsed [StreetPlan](https://streetplan.net) tools for visualising 1D street layouts and cloud-based transport planning services such as [Remix](https://www.remix.com/).
Software for transport planning can be grouped by the scale at which it operates, with broad categories being microscopic and macroscopic (macro) models [@kotusevski_review_2009; @hildebrand_comparative_2014]. Microscopic transport models represent individual vehicles on the road network and are therefore able to represent localised phenomena such as traffic congestion. Macro models, by contrast, represent aggregates of vehicular traffic over large spatial scales, in which "the total flow is studied" and behaviour of individual vehicles is omitted [@hildebrand_comparative_2014]. Of course the distinction is, in reality, an oversimplification: there is a continuum between macro and microscopic transport models; advances in computing increasingly enable both approaches to be combined, enabling researchers to choose the most appropriate spatial scales for their application [@moeckel_trends_2018]. The focus of this paper is on macro models which enable modelling of the implications of future changes in transport behaviour and infrastructure on flow at city scales, with results down the route network level (microscopic models tend to be used to model individual route segments and intersections), and their geographic analysis capabilities.
This history is detailed in Chapter 10 of *Forecasting Urban Travel* [@boyce_forecasting_2015] called "Computing environment and travel forecasting software", which provides an insight into how software has been used in transport planning over the years. Of course, software development has always depended on the physical hardware on which it runs and the early days of transport planning software were characterised by bespoke programs running on mainframe computers and maintained by domain experts. Transport planning bodies and researchers in the USA led developments in the 1960s and 1970s when computers first started to be used for transport planning, when the main problem that they addressed was how to deal with the explosive growth in car ownership and use that was taking place during those decades. More overtly political factors also influenced the direction of transport planning software: "certain private firms complained to US DoT [Department of Transport] that its agencies were developing software in competition with the private sector", leading to the abandonment of publicly funded transport planning software development projects, notably UTPS [@boyce_forecasting_2015].[^7] This transfer of transport planning software development to the private sector contrasts with the history of GIS. The example of GRASS (Geographic Resources Analysis Support System) illustrates this point and helps explain the dominance of proprietary software in transport planning. Like UTPS, GRASS was a publicly funded software project. Unlike UTPS, it was made freely available to the public and was open sourced (in 1999), meaning that it has been under continuous development by state, academic and commercial organisation since 1982 [@neteler_open_2008]. Would the landscape of transport planning software have been different if the DoT had continued to fund software development projects? That question is outside the scope of this paper. What is certain, however, is that software used in transport planning over the past three decades has been dominated by companies and that the sector has been slow to adopt open an open source approach.
[^7]: UTPS stands for the UMT (Urban Mass Transportation Administration, an agency of the DoT responsible for transport planning) Transportation Planning System (UTPS).
In response to the 'siloed' development of GIS and transport software, there have been calls for greater integration. @loidl_gis_2016, building on the observation that "geography and GIS remained a niche topic within traditional transport modeling", made a case for strengthening the 'spatial perspective' in transport modelling. The paper emphasised the growing importance of well-defined data types, disaggregating detailed (and difficult to interpret) transport model outputs, and geographic data visualisation and concluded that much further research is needed: "future research and development is needed to combine geospatial functionalities with transport modeling, while providing an efficient, interactive, visual interface for data exploration, manipulation, analysis and visualization" [@loidl_gis_2016]. Although the paper focussed on conceptual issues rather than software per-se, it did identify mention four open source programming languages that could provide the foundation for future developments, two of which (R and Python) are covered in the next section.
Data preprocessing and analysis stages are generally done in dedicated transport planning and spreadsheet software. Geographic analysis and cartographic visualisation stages are often done in a dedicated GIS. Some prominent transport planning software products, and levels of support for geographic data analysis, are summarised in Table 1, which shows that popular transport planning tools have differing levels of geographic capabilities.
```{r, echo=FALSE, message=FALSE, warning=FALSE, eval=TRUE}
# geo_capabilities = "I, B, E, P"
# tms = readr::read_csv("https://github.com/ITSLeeds/TDS/raw/master/transport-software.csv")
# # tms$`Source of citations`
# tms$`Source of citations`
#
# tms$I = c("Y", "Y", "Y", "Y", "Y", "Y", "Y")
# tms$G = c("Y", "?", "Y", "?", "Y", "?", "Y")
# tms$R = c("Y", "Y", "Y", "?", "Y", "?", "Y")
# tms$RNA = c("Y", "Y", "Y", "Y", "Y", "Y", "Y")
# tms$SV = c("Y", "Y", "Y", "Y", "Y", "Y", "?")
# tms$IV = c("?", "?", "?", "?", "?", "?", "?")
# tms$EX = c("?", "?", "?", "?", "Y", "?", "?")
#
# file.edit("transport-modelling-software.csv")
# tms_new = DataEditR::data_edit(tms)
# readr::write_csv(tms_new, "transport-modelling-software.csv")
tms = readr::read_csv("transport-modelling-software.csv")
tms = arrange(tms, desc(Citations))[1:5]
knitr::kable(tms, caption = "Sample of transport modelling software in use by practitioners, with citation counts based on citation from searches for the product name (plus company name for the common word 'cube') and 'transport planning'. Data source: Google Scholar searches, August 2020.", booktabs = TRUE)
# knitr::kable(tms, booktabs = TRUE, caption = "Sample of transport modelling software in use by practitioners. Note: citation counts based on searches for company/developer name, the product name and 'transport'. Data source: Google Scholar searches, October 2018.", format = "latex")
# tms$`Geographic capabilities` = c(
# "Plotting, editing, import, buffer, intersections", # https://www.ptvgroup.com/fileadmin/user_upload/Products/PTV_Visum/Documents/Release-Highlights/PTV_Visum_18_release_highlights_EN.pdf # http://www.traffic-inside.com/2014/11/27/ptv-visum-tip-catchment-areas-accessibility-of-places-in-the-network/
# "I, E, P, R"
# )
```
An interesting observation is that the open source options --- MATSim, SUMO and sDNA --- all have limited 'in house' geographic capabilities. This can be explained by the 'Unix philosophy', the second tenet of which is modularity, meaning that "each program should do one thing well", reducing duplication of effort and allowing the best tool to be used for each job [@gancarz_linux_2003]. The next section describes the this modularity in more detail, including outstanding support for geographic data in open source software.
There are many barriers reducing access to prominent tools in the current landscape of transport planning. Proprietary tools are expensive (costing up to hundreds of dollars for a single license), ensuring that only a small fraction of transport planners, let alone the public, has access to them. Many proprietary tools are tied to a particular Windows, preventing use in on other operating systems such as Linux, Mac and FreeBSD. This reduces reproducibility of results and prevents 'citizen science' and educational projects that use the same tools as professional planners.
A wider barrier is that organisations' GIS and Transport functions tend to be siloed into their respective departments/teams with little communication between them, meaning that transport planners may not have access to the latest geographic data or software.[^8] This relates to tools because if transport planners and GIS analysts are using different programs for their work, transport planners will be less likely to collaborate with people with geographic analysis skills or identify potential geographic solutions to their domain-specific problems. The extent to which these barriers can be overcome by open source software ecosystems is explored in the next section.
[^8]: Thanks to Crispin Cooper, author of sDNA, for raising this barrier.
```{r, echo=FALSE, eval=FALSE}
# alternative way to get citation data (WIP)
library(fulltext)
ft_search("visum", from = "crossref", scopusopts = )
scopus_search(query = "visum", key = Sys.getenv("SCOPUS"))
```
# Open source tools for geographic analysis in transport planning {#open-source-tools}
Technological, environment and societal changes are driving demand for accessible tools for geographic analysis transport planning.
This section reviews prominent open source tools that are already being used to tackle transport planning challenges.
Open source tools for geographic analysis in transport planning have not emerged in a vacuum.
They were developed in the wider landscape of open source software [@dhir_adoption_2017].
These tools could be classified by the five main stages illustrated in Figure \@ref(fig:schematic) (data collection, processing, routing, modelling and visualisation). Instead, because many tools can be used in multiple stages, can be more usefully classified from the user's perspective. Based on open tools identified through web searches, they can be classified into the follow broad, and to some extent overlapping,[^9] user interface (UI) types (see Table \@ref(tab:open-tools)):
[^9]: Some tools can be used through multiple interfaces but most have a dominant interface type.
- command-line interface (CLI) tools, primarily controlled by typing commands
- graphical user interface (GUI) tools, primarily controlled by mouse clicks
- web user interface (WUI) tools that users access through a web browser
- web application programming interfaces (API) that computers access over the web
In this paper we will focus on projects in the first three categories. Numerous open source 'routing engine' projects provide a range of high performance routing and other transport data analysis services via a web application programming interface (API). While technically these can be used for geographic analysis tasks, they are more commonly used by transport planners as remote services, and are usually the preserve of software developers, so were excluded from Table \@ref(tab:open-tools).
## Defining open source
Before describing open source tools for transport planning, classified by their main user interface, is worth considering what 'open source' means.
Open source software differs from proprietary software in that users are free to see, download and modify the source code. Freedom is central to open source software, which is sometimes referred to simply as 'free software', defined by the Free Software Foundation (FSF) as follows:[^10]
[^10]: See for a full definition and context.
> software that gives you the user the freedom to share, study and modify it.
This adaptability is conducive to collaboration, the creation of mutually supportive user/developer communities and rapid evolution, making open source software ecosystems fast moving and highly diverse. It is impossible to discuss all software options that could be used for geographic transport planning: there are literally thousands of software projects written in dozens of programming languages, many of which are no longer actively maintained [@coelho_this_2020]. Transport planners should use solutions that are future proof and actively maintained.
## Methods to identify open source tools
To identify open source tools for transport planning, a search approach was used to incorporate projects that have been written-up in the academic literature, and projects which exist only as software projects, with a minimum level of popularity. The method was as follows:
1. Undertake searches of Google Scholar, DuckDuckGo and the popular code hosting platform with search terms set to identify open source projects for transport planning.
2. Combine results from the searches into a single dataset and rank the projects according to evidence of usage.
3. Verify that the projects are open source and actively maintained by analysis of package documentation and source code.
4. Classify and the projects based on their main user interface, resulting in Table \@ref(tab:open-tools) (see [open_tools.csv](https://github.com/Robinlovelace/open-gat/blob/master/open_tools.csv) for a more complete list that includes web APIs). These tools are described in more detail in the following three sections.
The following search terms were used to find relevant projects using Google Scholar, the result of a search shown in Figure \@ref(fig:scholar-search):
> software transport "open source" "transport planning" OR "geographic data" OR "geographic analysis" OR "spatial data" OR "spatial network"
```{r scholar-search, fig.cap="Illustration of the Google Scholar search terms used to identify open source software for geographic analysis in transport planning.", out.width="60%"}
knitr::include_graphics("scholar-search.png")
```
To identify open source projects on GitHub's [advanced search page](https://github.com/search/advanced) a 'snowball' method, analogous to that used by @grabowicz_social_2012 in the context of social media, was used. The 'topic' descriptions of previously identified open tools were used to identify additional projects and search terms. This method worked as follows:
- The GitHub page of the previously identified project stplanr project was visited.
- One of the 'topics' in the stplanr repository was was the broader term `transport`, which was used to identify the SUMO project
- The SUMO project had the topic 'simulation', leading to the discovery of the A/B Street project
The list of GitHub topics used to identify projects was as follows (manual reading of the README for each project was used to confirm if the projects were related to transport planning, many were not, e.g. because they were for web transport rather than transport planning):
> [transport planning](https://github.com/topics/transport-planning), [transport](https://github.com/topics/transport), [transportation-planning](https://github.com/topics/transportation-planning), [traffic-simulation](https://github.com/topics/traffic-simulation), [simulation](https://github.com/topics/simulation), [trajectory](https://github.com/topics/trajectory)
To overcome the limitation that not all open source software projects are hosted on GitHub *or* described in academic papers, snowballing via web pages such as the [QGIS plugin homepage](https://plugins.qgis.org/), links in project README files and [social media](https://twitter.com/robinlovelace/status/1290636806078201856) were used to find additional projects. Only projects with the following criteria were included (see [open_tools.csv](https://github.com/Robinlovelace/open-gat/blob/master/open_tools.csv) for online version):
1. The tool was designed to support transport planning using geographic data analysis and supports the design and placement of physical infrastructure for urban mobility, based on the project's website or code repository
2. Evidence that the tool is being used in practice, via citations, 'stars' or other type of 'upvote'
3. Evidence that the tool is actively maintained, with activity in the last 12 months
4. Availability of source code with a visible open source license
A secondary filter was used to focus attention on tools for analysis: projects whose primary purpose is to provide an interface to an existing software/services, such as the R package **opentripplanner** [e.g. @morgan_opentripplanner_2019; @R-osrm] and routing engines [@luxen_realtime_2011; @padgham_dodgr_2019] are omitted from Table \@ref(tab:open-tools) for brevity (routing engines are mentioned in the final section of the paper). Tools can be classified in a variety of ways from a developer's perspective including sometimes tribal 'ecosystems' such as R packages, Python packages and QGIS plugins. From a transport planner's perspective, however, the technology or developer community from which tools emerge may be irrelevant: what is important is what the tool can do and its ease-of-use. We therefore describe the tools in order of their primary user interface, in chronological order of the interface's development (CLIs predate GUIs which predate WUIs), acknowledging the fact that most tools with a prominent GUI and WUI can also be used from the command line. While sDNA and AequilibraE *can* be used from the command-line, their documentation suggests they are more likely to be used from graphical interfaces via QGIS plugins, resulting in the categorisation shown in Table \@ref(tab:open-tools).
```{r open-tools, echo=FALSE, message=FALSE}
library(kableExtra)
# Include these?
# https://github.com/UDST/pandana
# https://github.com/dymium-org/dymiumCore
# https://github.com/bistro-its-berkeley/BISTRO
# https://github.com/LBNL-UCB-STI/beam
open_tools = readr::read_csv("open_tools.csv")
# table(open_tools$emphasis)
# edit the data:
# remotes::install_github("DillonHammill/DataEditR")
# open_tools_new = DataEditR::data_edit(open_tools)
# readr::write_csv(open_tools_new, "open_tools.csv")
names(open_tools) = tools::toTitleCase(names(open_tools))
open_tools_filtered = open_tools %>%
filter(Emphasis != "interface") %>%
filter(Emphasis != "GIS") %>%
filter(Emphasis != "routing engine") %>%
filter(Type != "Routing engine")
readr::write_csv(open_tools_filtered, "open_tools_filtered.csv")
open_tools_filtered %>%
mutate(Tool = paste0("\\href{http://", Website, "}{", Tool, "}")) %>%
# mutate(Tool = paste0("[", Tool, "](", Website, ")")) %>%
select(Tool, Type, Licence, Language, Stars, Citations, Reference) %>%
# nrow()
# knitr::kable(caption = "Open source tools for geographic analysis in transport planning, based on data from Google Scholar, GitHub and web searches and classified in by their primary user interface. CLI, GUI and WUI refer to command-line, graphical user and web user interfaces respectively.", format = "markdown")
kable(format = "latex", escape = F, booktabs = T, caption = "Open source tools for geographic analysis in transport planning, based on data from Google Scholar, GitHub and web searches and classified in by their primary user interface. CLI, GUI and WUI refer to command-line, graphical user and web user interfaces respectively.") %>%
pack_rows(group_label = "CLI", start_row = 1, end_row = 12) %>%
pack_rows(group_label = "GUI", start_row = 13, end_row = 19) %>%
pack_rows(group_label = "WUI", start_row = 20, end_row = 25) %>%
kable_styling(bootstrap_options = c("hover", "condensed"), latex_options = c("scale_down"))
```
```{r, eval=FALSE, echo=FALSE}
library(tidyverse)
query = "geographic spatial network transport software open source"
scholarsearch::scholarsearch(query = query)
scholarsearch::scholar_get_citations()
res = scholarsearch::scholar_get(query = query, as_ylo = 2020, as_yhi = 2020)
readr::write_csv(res, "res-scholar-2020.csv")
for(i in 2010:2019) {
Sys.sleep(time = 2)
res = rbind(res, scholarsearch::scholar_get(query = query, as_ylo = i, as_yhi = i))
}
res$n_citations[is.na(res$n_citations)] = 0
res$years_since_publication = 2021 - res$year
res$citations_per_year = round(res$n_citations / res$years_since_publication)
res = res %>%
arrange(desc(citations_per_year))
readr::write_csv(res, "res-scholar-2010-2020geographic spatial network transport software open source.csv")
# manual edit of that file
```
It should be clear that the 'Type' and 'Language' values shown in Table \@ref(tab:open-tools) are also fuzzy: open source software is by nature modular and flexible, meaning that the same piece of code can take multiple different forms and the same method can be implemented in multiple languages. The AequilibraE QGIS plugin [@camargo_aequilibrae_2015], for example, is also a Python package. Conversely, the MovingPandas Python package by @graser_movingpandas_2019 is also a QGIS plugin. The point is that the *most prominent* category into which each project seemed to fall, based on documentation, was used. The rest of this section outlines some of the capabilities of each tool presented in Table \@ref(tab:open-tools) based on the author's reading of easily available documentation: due to time constraints no systematic installation tests or benchmarks were undertaken, although this could be a direction of future research.
An interesting insight provided by the popularity metrics of 'Stars' (meaning the number of people who had 'starred' the project on GitHub) and Citations (to the main paper outlining the tool, where available) as of September 2020 is that the choice of metric has a large impact on perceived popularity.
While MatSIM is perhaps the tool in Table \@ref(tab:open-tools) that has most uptake in applied transport planning, it had only a moderate number of Stars (285) compared with the number of papers citing the tool's main reference the tool, which is in itself a free and open resource [@horni_multiagent_2016].
A/B Street, by contrast, had more than *twenty times* the number of Stars on GitHub but no academic paper that could be found in the public domain at the time of writing.
This highlights the fact that different user communities visit different forums and, furthermore, many transport practitioners will neither write academic papers not be active GitHub users, making the uptake of different software projects even harder to monitor, an issue we return to in Section \@ref(conclusion).
```{r, eval=FALSE}
# library(gtrendsR)
# res = gtrends(c("R programming", "Python programming", " VBA programming"), time = "2010-01-01 2019-08-01")
# res
# p = plot(res)
# class(p)
#
# head(res$interest_over_time)
# tail(res$interest_over_time)
# head(res$interest_over_time$time)
# class(res$interest_over_time$time)
# unique(res$interest_over_time$keyword)
# nrow(res$interest_over_time) / 3 / 12
# nrow(res$interest_over_time) / 3
# res$interest_over_time$date = rep(seq(from = as.Date("2010-01-01"), to = as.Date("2019-07-01"), length.out = 116), 3)
# start_rows = 1
# end_rows = nrow(res$interest_over_time) / 3
#
# res$interest_over_time$hits_smoothed = c(
# zoo::rollmean(res$interest_over_time$hits[start_rows:end_rows], 6, fill = "extend"),
# zoo::rollmean(res$interest_over_time$hits[(start_rows:end_rows) + end_rows], 6, fill = "extend"),
# zoo::rollmean(res$interest_over_time$hits[(start_rows:end_rows) + 2 * end_rows], 6, fill = "extend")
# )
#
# res2 = gtrends(c("RStudio", "Pycharm", " QGIS"), time = "2010-01-01 2019-08-01")
#
# p2 = plot(res2)
#
# devtools::install_github("thomasp85/patchwork")
# library(patchwork)
#
# p + p2
#
# end_rows = nrow(res2$interest_over_time) / 3
# class(res2$interest_over_time$hits) = "numeric"
#
# res2$interest_over_time$hits_smoothed = c(
# # slide::slide_dbl(res2$interest_over_time$hits[start_rows:end_rows], ~mean(.x), .before = 6, .after = 6)
# zoo::rollmean(res2$interest_over_time$hits[start_rows:end_rows], 6, fill = "extend"),
# zoo::rollmean(res2$interest_over_time$hits[(start_rows:end_rows) + end_rows], 6, fill = "extend"),
# zoo::rollmean(res2$interest_over_time$hits[(start_rows:end_rows) + 2 * end_rows], 6, fill = "extend")
# )
#
# res_all = rbind(res$interest_over_time, res2$interest_over_time)
#
# ggplot(res_all) +
# geom_line(aes(date, hits_smoothed, colour = keyword), size = 2) +
# ylab("Relative number of hits") +
# theme(legend.position = c(0.2, 0.8))
#
# ggplot2::ggsave("google-trends-open.png", width = 6, height = 4)
```
```{r, fig.cap="Relative number of searches for terms related to open source (R and Python) and proprietary-based (VBA) programming languages (left) and open source programs (Pychame, QGIS, RStudio) that can be used for transport planning. Code to reproduce the plot is hosted in this paper's code repository.", out.width="70%"}
# knitr::include_graphics("google-trends-facet.png")
```
## Command-line interface (CLI) tools
Tools based on a *command line interface* (CLI) are designed to be controlled primarily by typing commands. CLIs predate *graphical user interfaces* (GUIs), which are controlled by 'pointing and clicking' [@sherman_desktop_2008]. CLIs can take time to learn, especially for people who have been trained on GUI-based software such as Microsoft Word. After overcoming often steep 'learning curves', the advantages of CLI-based tools for *users* become substantial. The approach can be highly productive, with hundreds of commands only a few keystrokes away and the benefits of reproducibility and scalability associated with representing computational workflows in code. Programming also provides flexibility: the user is not constrained by the options provided in the GUI and in many CLI-based tools can define new functions. The approach also has advantages for *developers*: it is substantially easier to write software without the burden of having to develop a GUI, reducing the barrier to entry for potential contributors. Ease of development explains why CLIs represent the most common type of open source tool for geographic analysis.
The longest standing and still actively maintained CLI tools for geographic analysis in transport planning shown in Table \@ref(tab:open-tools) are **SUMO** (first released in 2001) and **MATSim** (first released in 2006). Both projects operate at the 'microscropic' (street) level and simulate individual vehicles at high spatial and temporal resolution, although the emphasis of **MATSim** is more on citywide analysis compared with the emphasis on modelling traffic at junctions in **SUMO**. There is evidence of uptake of both projects in applied transport planning contexts, with **MATSim** in particular being [cited](https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=%22matsim%22+%22transport+planning%22) in dozens of applied transport planning papers. Neither project focusses on geographic analysis but both rely on geographic inputs (detailed road geometries) and produce geographic outputs.
**MATSim**, which stands for Multi-Agent Transport Simulation, is perhaps the more ambitious project, enabling the transport systems of entire cities to be simulated, creating opportunities for detailed model experiments based on transport networks that can be edited using a plugin to the [JOSM GIS](https://github.com/matsim-org/josm-matsim-plugin) [@horni_multiagent_2016]. **SUMO** is focussed on modelling traffic on road segments and junctions and although the emphasis is not on geographic analysis, the inclusion of a geographic road network editor (called NETEDIT) means that the tool can be used to analyse geographic scenarios of change [@lopez_microscopic_2018]. With complex installation and usage instructions, **SUMO** and **MATSim** are both aimed at advanced users. This has the advantage of enabling many research and (particularly in the case of **MATSim**) applied use cases due to the flexibility of the tools, but has the disadvantage of reducing accessibility.
The remaining CLI-based tools in Table \@ref(tab:open-tools) are smaller, simpler and more accessible R/Python packages that fit within the framework of these pre-existing open source software ecosystems. **OSMnx** is a Python package for downloading and analysing transport networks from OpenStreetMap that has a focus on urban transport network analysis [@boeing_osmnx_2017]. **OSMnx** has been used for a wide range of research and real-world applications, with a focus on spatial network analysis via functions for calculating a range of transport network measures. **Movingpandas** is a Python package and QGIS plug-in for visualising a wide range of movement datasets, with a focus on trajectory data [@graser_movingpandas_2019]. **momepy** is a Python package for measuring 'urban morphology', meaning the measurement and analysis of collections of geographic entities that constitute cities [@fleischmann_momepy_2019].
The other Python packages in Table \@ref(tab:open-tools) have broader (and to some extent overlapping) remits, aiming to support a range of transport planning objectives. **UrbanSim** and **UrbanAccess** are Python packages that are part of the [Urban Data Science Toolkit](https://github.com/UDST) project, with the former oriented towards statistical analysis of citywide transport systems and the latter focused on analyzing geographic transport network data from an accessibility perspective. The documentation describing these tool highlights their ability to assist metropolitan planning organizations (MPOs) to prioritise investments that cost-effectively increase accessibility for those most in need [@blanchard_urbanaccess_2017]. In addition to using OSM data, **UrbanAccess** can import and process GTFS data to calculate multi-modal travel times and other metrics. [**UrbanPy**](https://github.com/EL-BID/urbanpy) has similar objectives and includes functionality for spinning-up Docker containers to do routing using the OSRM routing engine, highlighting the interoperability between open source tools.
Like **momepy**, the **spaghetti** package (which stands for SPAtial GrapHs: nETworks, Topology, & Inference) is focussed on street network analysis, but focusses less on urban morphology and more on segment-level statistics [@Gaboardi2018]. **scikit-mobility** implements a framework for statistical modelling of travel behaviour, including functions for estimating movement between geographic zones using spatial interaction models, as well as route assignment [@pappalardo_scikitmobility_2019].
The JavaScript package **Trip-simulator**, from the not-for-profit organisation Shared Streets, enables geographic analysis for transport planning by simulating GPS flows on street networks. Its command-line interface allows a wide variety of trip types and volumes to be simulated which can, given a new street network layout, be used to estimate the impact of changes to the network.
The remaining two CLI-based tools in Table \@ref(tab:open-tools) are R packages focussed on applied transport planning. **stplanr** (which stands for sustainable transport planning with R) contains a range of functions for processing origin-destination, routes and route networks. The package takes an explicitly geographic approach to transport planning and many of the functions use geographic operations such as buffers and spatial aggregation in workflows that start with origin-destination data and end with estimates of travel demand down to the route network level under different scenarios of change [@lovelace_stplanr_2018]. **opentripplanner** is an R package for multi-modal routing and accessibility analysis that provides an interface to the OpenTripPlanner Java library, enabling not only calculation of travel times and route geometries but also monetary costs and accessibility isochrone maps where GTFS data allow [@morgan_opentripplanner_2019].
## Graphical user interface (GUI) tools
Other than A/B Street, all of the GUI-based tools presented in Table \@ref(tab:open-tools) are QGIS plugin. This came as a surprise: given the dominance of GUIs in many areas of computing one would expect a range of stand-alone transport planning tools to have been developed (the criterion that tools must be actively maintained to be considered explains the exclusion of some tools such as Tranus [@delabarra_tranusj_1984]).
A/B Street does not market itself as a transport planning tool but instead as a game and educational tool. However, that does not mean that it lacks capabilities. A/B Street combines the real-time capabilities of MATSim with the usability of online tools such as Streetmix, discussed in the next section, taking a 'SimCity' approach to transport planning, while still allowing the user to zoom in to single vehicles (while they are in motion via a moving camera!) and change the geometries of street layouts with an intuitive in-built editor.
QGIS plugins for transport planning are explicitly focussed on geographic analysis for transport planning. **AequilibraE**, **QNEAT3** and the **Networks** plugins provide various transport planning tools from the mature and popular QGIS GUI-based Geographic Information System (GIS). **AequilibraE** provides a broad range of functions for processing transport networks and assigning traffic [@camargo_aequilibrae_2015], as detailed in the project's substantial [documentation website](http://aequilibrae.com/python). [**QNEAT3**](https://root676.github.io/) provides a narrower but well documented set of algorithms for transport planning applications, including shortest path, network buffers and OD matrix visualisation. The **Networks** plugin uses an interface to external software [**Mulsiw**](https://github.com/crocovert/Musliw) to enable multi-modal routing and GTFS data import. The **AwaP** plugin uses data on urban 'blocks' (typically buildings) to calculate indicators relating to walkability. The tool can been used to compare the urban morphologies of different areas cities from a walkability perspective [@majic_awapic_2019].
Finally, the sDNA QGIS plugin provides an interface to the C++ project sDNA, a tool for spatial network analysis that has been developed to support transport planning for walking and cycling [@cooper_sdna_2020]. A range of route network analysis functions are available, enabling the user to parameterise models to best represent travel behaviour at city scales base on the high performance routing between every vertex on the network. By changing network characteristics and geometries or adjusting parameters, model experiments can be undertaken in sDNA to represent scenarios of change [@cooper_predictive_2018].
## Web user interface (WUI) tools
Installing and running code on sufficiently powerful computers has long been a barrier preventing people from accessing software, and transport planning tools are no exception. In this context web user interfaces (WUIs, by which I mean an in-browser graphical user interface rather than a web API) can provide multiple advantages in terms of participatory planning (although cloud-based solutions also pose risks in terms of concentration of processing and economic power).
Like **A/B Street**, [**CityBound**](https://github.com/citybound/citybound) takes a gaming approach to transport planning, with an interactive editor and an agent-based approach that allows hundreds of vehicles to interact on city scale networks in real time. Perhaps its most interesting feature from a transport planner's perspective is the editing framework, which offers "the power and expressiveness of professional CAD tools while being much more intuitive and fun to use." Also like **A/B Street** the project does not originate from a transport planning context, instead approaching city planning from a computer science perspective using recent developments in digital technology such as [WebAssembly](https://webassembly.org/) to push boundaries, which in part explains the project's popularity among developers as evidenced by the fact it has more than 6k 'Stars' on GitHub.
**Streetmix** is primarily available and used as a free and open web service hosted at [streetmix.net](https://streetmix.net/), but it is also an open source software project supported by free software giant Mozilla that enables anyone to create a locally hosted instance of the service. Unlike the other projects listed in Table \@ref(tab:open-tools), **Streetmix** does not use 2 dimensional (longitude/latitude) data but instead allows the user to interactively edit a 1D street profile, from the edge of buildings on one side to the other side. You can add pavements, cycleways, aesthetic features such as trees and other items to support more sustainable planning policies and designs [@riggs_streetplan_2016]. As discussed in Section \@ref(conclusion), the combination of the emphasis on participatory design for sustainable futures in **Streetmix** with the technology for 2D (and even 3D) intiutive editing in **CityBound** represents a promising possibility for future research and development.
**Conveyal Analysis** represents a step in that direction, providing a hosted service for city-wide scenarios of change. With only 19 Stars on GitHub and limited documentation, however, the **Analysis** tool has some way to go before it builds a 'community of practice' of the type enjoyed by more established and well-documented projects such as **MATSim**.
The JavaScript/TypeScript-based projects **flowmap.blue** and **TrajAnalytics** are interactive, web-based geographic mobility data visualisation tools at opposite ends of the spectrum in terms of size and complexity. **flowmap.blue** is a lightweight tool that focusses on ease of use and, via an R package of the same name, inter-operability for people working with origin-destination data. **TrajAnalytics** is a large (83 MB zipped) project providing a visualisation framework for displaying and analysing large trajectory datasets. Unlike **Streetmix**, which focusses on the individual street level, both projects are designed for visualising citywide and regional scale transport systems.
The Propensity to Cycle Tool (PCT) is an interactive map-based web tool designed to support cost effective investment in cycling infrastructure [@lovelace_propensity_2017]. The emphasis is on where to build to maximise cycling uptake. By exploring scenarios of change including Go Dutch --- in which cycling levels are simulated to grow to Dutch levels nationwide --- planners, active travel advocates and other stakeholders build business cases for investment along desire lines with high cycling potential and better understand health and environmental benefits of interventions in different places.
## Geographic capabilities
The brief descriptions of CLI, GUI and WUI-based tools for transport planning above show diversity of approaches to geographic data, ranging from 1D editing in **Streetmix** to full geographic data editing and analysis functionality available to users of QGIS-based tools. With reference to the transport planning process shown in Figure \@ref(fig:schematic), the geographic capabilities of the tools is shown in Table \@ref(tab:capabilities). The columns in \@ref(tab:capabilities) broadly match the main stages of transport planning as follows:
2) data collection: supported by download (Dld) functionality
3) modelling/analysis: supported by routing (Rou) and geographic analysis (Geo)
4) evaluation: supported by modelling and data analysis (Mod) capabilities
5) implementation of solutions: supported by visualisation (Vis)
Additional important considerations include the geographic resolution, support for time series analysis (over seconds to years), the scale at which the tools are documented to run at and the level of expertise needed to install, set-up and use the tool.
Many tools provide functionality through documented interfaces to other packages.
R has a mature ecosystem of packages for geographic analysis, with particular strengths in statistical analysis @bivand_progress_2020 and visualisation [@lovelace_geocomputation_2019, Chapter [8](https://geocompr.robinlovelace.net/adv-map.html)].
Likewise, there is a growing ecosystem of Python packages for geographic analysis [@garrard_geoprocessing_2016], some of which are available as QGIS plugins, placing the user in an advance GIS.
Another key finding from Table \@ref(tab:capabilities) is that there is no single tool that every desirable feature of tools for geographic analysis in transport planning. There is generally a trade-off between the complexity of the tool and ease-of-use, with **MATSim** and **SUMO** being sophisticated yet hard to use and **Streetmix** providing an intuitive interface yet limited geographic capabilities, for example. There are exceptions: **A/B Street** provides a user friendly interface and even a 'demo' mode inspired by computer game design yet also has sophisticated functionality, although due to the nascent nature of the project and focus on education/fun rather than real-world transport planning these capabilities have yet to be documented in applied settings.
```{r capabilities, message=FALSE}
open_tools = readr::read_csv("open_tools_filtered.csv")
# table(open_tools$emphasis)
# edit the data:
# remotes::install_github("DillonHammill/DataEditR")
# open_tools_new = DataEditR::data_edit(open_tools)
# readr::write_csv(open_tools_new, "open_tools.csv")
names(open_tools) = tools::toTitleCase(names(open_tools))
open_tools_filtered %>%
select(Tool, Type, Dld, Rou, Geo, Mod, Vis, Resolution, Time, Scale, Expertise) %>%
mutate_if(is.character, str_replace_all, pattern = "✓", replacement = "y") %>%
mutate_if(is.character, replace_na, replace = "") %>%
# kable(escape = F, caption = "Geographic capabilities and features of open source tools for transport planning. Dld, Rou, Geo, Mod and Vis refer to Downloading, Routing, Geographic analysis, Modelling and Visualisation capabilities, respectively. Cell values y, i, and e mean Yes (with in-house capabilities), yes via Interfaces to other packages/software and Editing capabilities. a, od, p, s and t refer to Agent, Origin-destination, Point (transect), Street (segment) and Trajectory as the main level of geographic resolution of data used by each tool, respectively. Values in the Time column report whether the tool has inbuilt support and documentation for incremental time simulations. Scale refers to the most common scale of analysis that the tool is documented to work at, with values p, c, n and g referring to Point, City, National and Global scales respectively. Expertise refers to the level of expertise needed to install, set-up and run the tool, ranging from 1 (easy) via 2 (intermediate) to 3 (expertise required).")
kable(format = "latex", escape = F, booktabs = T, caption = "Geographic capabilities and features of open source tools for transport planning. Dld, Rou, Geo, Mod and Vis refer to Downloading, Routing, Geographic analysis, Modelling and Visualisation capabilities, respectively. Cell values y, i, and e mean Yes (with in-house capabilities), yes via Interfaces to other packages/software and Editing capabilities. a, od, p, s and t refer to Agent, Origin-destination, Point (transect), Street (segment) and Trajectory as the main level of geographic resolution of data used by each tool, respectively. Values in the Time column report whether the tool has inbuilt support and documentation for incremental time simulations. Scale refers to the most common scale of analysis that the tool is documented to work at, with values p, c, n and g referring to Point, City, National and Global scales respectively. Expertise refers to the level of expertise needed to install, set-up and run the tool, ranging from 1 (easy) via 2 (intermediate) to 3 (expertise required).") %>%
pack_rows(group_label = "CLI", start_row = 1, end_row = 12) %>%
pack_rows(group_label = "GUI", start_row = 13, end_row = 19) %>%
pack_rows(group_label = "WUI", start_row = 20, end_row = 25) %>%
kable_styling(latex_options = c("scale_down"))
```
Table \@ref(tab:capabilities) shows that there is great diversity of open source tools, even within the limited and still nascent niche of tools for geographic analysis in transport planning.
There seems to be more diversity *within* each software ecosystems such as R packages, Python packages and QGIS plugins than *between* them, despite the fact that software developers within each ecosystem are linked by an overarching language/approach.
Software is not developed in isolation but in a social context and the collaborative nature of open source tools tends to encourage solutions that are mutually supportive rather than competing [@dhir_adoption_2017].
Indeed, many of the tools presented in Table \@ref(tab:capabilities) have a particular speciality, ranging from analysis of citywide transport networks in OSMnx [@boeing_osmnx_2017] to the analysis of cycling potential in the PCT [@lovelace_propensity_2017] and the visualisation of origin-destination data in flowmap.blue.
A few of the tools can be seen as general purpose transport planning tools, with particular strengths.
Veins (which uses SUMO behind the scenes), MATSim and A/B Street are well suited to a wide range of geographic transport planning tasks, ranging from the simulation of the impact of new infrastructure on the flow of individual vehicles to city-wide impacts of new policies.
All three have mechanisms to not only describe but to *change* transport networks interactively and all can work on scales ranging from single junctions to entire cities (although at the time of writing, A/B Street struggles to represent the central areas of large cities such as London, the performance of the other tools on large cities is not known).
Tools focussed on origin-destination data such as the PCT and flowmap.blue are not constrained by the need to visualise complex city networks, and can show the transport cities of entire countries.
This raises the question of scale.
Clearly, different tools have different capabilities and most tools can be used to analyse phenomena at more than one scale of analysis.
Furthermore, although a tool has a 'most common scale' that does not mean it cannot be used at larger or smaller scales.
MATSim, for example, is most often used to study city-level phenomena and requires substantial computing resources to study regional or even national systems at high temporal resolution, but that does not mean it *cannot* be done if sufficiently powerful hardware and set-up resources are available (the same point applies to the other microsimulation tools SUMO, A/B Street and Veins).
And although tools have a main level (Resolution) of analysis, that does not stop them from using or producing datasets at higher resolution, the PCT's production of data at the route network segment (s) level using OD data as inputs being a case in point [@morgan_travel_2020]