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 and Dhir 2017).
These tools could be classified by the five main stages illustrated in Fig. 1 (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,Footnote 9 user interface (UI) types (see Table 2):
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 2.
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:Footnote 10
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 et al. 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:
Undertake searches of Google Scholar, DuckDuckGo and the popular code hosting platform with search terms set to identify open source projects for transport planning.
Combine results from the searches into a single dataset and rank the projects according to evidence of usage.
Verify that the projects are open source and actively maintained by analysis of package documentation and source code.
Classify and the projects based on their main user interface, resulting in Table 2 (see 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 Fig. 2:
software transport “open source” “transport planning” OR “geographic data” OR “geographic analysis” OR “spatial data” OR “spatial network”
To identify open source projects on GitHub’s advanced search page a ‘snowball’ method, analogous to that used by Grabowicz et al. (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, transport, transportation-planning, traffic-simulation, simulation, 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, links in project README files and social media were used to find additional projects. Only projects with the following criteria were included (see open_tools.csv for online version):
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
Evidence that the tool is being used in practice, via citations, ‘stars’ or other type of ‘upvote’
Evidence that the tool is actively maintained, with activity in the last 12 months
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 et al. 2019; Giraud 2019) and routing engines (Luxen and Vetter 2011; Padgham 2019) are omitted from Table 2 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 2.
It should be clear that the ‘Type’ and ‘Language’ values shown in Table 2 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 2015), for example, is also a Python package. Conversely, the MovingPandas Python package by Graser (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 2 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 2 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 et al. 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 Sect. 5.
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 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 2 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 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 (Horni et al. 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 et al. 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 2 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 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 2019). momepy is a Python package for measuring ‘urban morphology,’ meaning the measurement and analysis of collections of geographic entities that constitute cities (Fleischmann 2019).
The other Python packages in Table 2 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 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 and Waddell 2017). In addition to using OSM data, UrbanAccess can import and process GTFS data to calculate multi-modal travel times and other metrics. 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 (Gaboardi et al. 2018). 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 et al. 2019).
The remaining two CLI-based tools in Table 2 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 and Ellison 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 et al. 2019).
Graphical user interface (GUI) tools
Other than A/B Street, all of the GUI-based tools presented in Table 2 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 (de la Barra et al. 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 2015), as detailed in the project’s substantial documentation website. QNEAT3 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 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 and Pafka 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 and Chiaradia 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 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 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 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, 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 2, 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 et al. 2016). As discussed in Sect. 5, 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 Propensity to Cycle Tool (PCT) is an interactive map-based web tool designed to support cost effective investment in cycling infrastructure (Lovelace et al. 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.
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 Fig. 1, the geographic capabilities of the tools are shown in Table 3. The columns in 3 broadly match the main stages of transport planning as follows:
data collection: supported by download (Dld) functionality
modelling/analysis: supported by routing (Rou) and geographic analysis (Geo)
evaluation: supported by modelling and data analysis (Mod) capabilities
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 (2020) and visualisation (Lovelace et al. 2019, Chapter 8). Likewise, there is a growing ecosystem of Python packages for geographic analysis (Garrard 2016), some of which are available as QGIS plugins, placing the user in an advance GIS.
Another key finding from Table 3 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.
Table 3 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 and Dhir 2017). Indeed, many of the tools presented in Table 3 have a particular speciality, ranging from analysis of citywide transport networks in OSMnx (Boeing 2017) to the analysis of cycling potential in the PCT (Lovelace et al. 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 and Lovelace 2020).