Hussein Mahfouz 18/8/2020
This repository contains the code used for the dissertation of my MSc in Smart Cities and Urban Analytics at CASA UCL. Below is an explanation of the scripts used, and how the analysis can be reproduced.
The paper can be found in the repo, or through this link
There are a couple of files that cannot be synced to github due to their size. These files are neseccary for the scripts to run. Below are links to where you can download them, and instructions on where to place them in the repo file structure
Flow Data (2011 Census Origin-Destination Data):
Middle Layer Super Output Areas (December 2011) Boundaries:
The scripts should be run in the order they are numbered in (and listed in here). The only exception is _x_dodgr_weighting_profiles.R.
This script matches MSOA to major towns and cities using data from here. It then matches the results to the Census flow data so that all OD pairs have an Origin City and Destination City (MSOAs in rural areas are not matched to a city)
In this script, you choose which city you wish to run the analysis from this list of available towns and cities:
## [1] "Barnsley" "Basildon" "Basingstoke"
## [4] "Bath" "Bedford" "Birkenhead"
## [7] "Birmingham" "Blackburn" "Blackpool"
## [10] "Bolton" "Bournemouth" "Bracknell"
## [13] "Bradford" "Brighton and Hove" "Bristol"
## [16] "Burnley" "Burton upon Trent" "Bury"
## [19] "Cambridge" "Cardiff" "Carlisle"
## [22] "Chatham" "Chelmsford" "Cheltenham"
## [25] "Chester" "Chesterfield" "Colchester"
## [28] "Coventry" "Crawley" "Darlington"
## [31] "Derby" "Doncaster" "Dudley"
## [34] "Eastbourne" "Exeter" "Gateshead"
## [37] "Gillingham" "Gloucester" "Grimsby"
## [40] "Guildford" "Halifax" "Harlow"
## [43] "Harrogate" "Hartlepool" "Hastings"
## [46] "Hemel Hempstead" "High Wycombe" "Huddersfield"
## [49] "Ipswich" "Kingston upon Hull" "Leeds"
## [52] "Leicester" "Lincoln" "Liverpool"
## [55] "London" "Luton" "Maidstone"
## [58] "Manchester" "Mansfield" "Middlesbrough"
## [61] "Milton Keynes" "Newcastle upon Tyne" "Newcastle-under-Lyme"
## [64] "Newport" "Northampton" "Norwich"
## [67] "Nottingham" "Nuneaton" "Oldham"
## [70] "Oxford" "Peterborough" "Plymouth"
## [73] "Poole" "Portsmouth" "Preston"
## [76] "Reading" "Redditch" "Rochdale"
## [79] "Rotherham" "Salford" "Scunthorpe"
## [82] "Sheffield" "Shrewsbury" "Slough"
## [85] "Solihull" "South Shields" "Southampton"
## [88] "Southend-on-Sea" "Southport" "St Albans"
## [91] "St Helens" "Stevenage" "Stockport"
## [94] "Stockton-on-Tees" "Stoke-on-Trent" "Sunderland"
## [97] "Sutton Coldfield" "Swansea" "Swindon"
## [100] "Telford" "Wakefield" "Walsall"
## [103] "Warrington" "Watford" "West Bromwich"
## [106] "Weston-Super-Mare" "Wigan" "Woking"
## [109] "Wolverhampton" "Worcester" "Worthing"
## [112] "York"
This is done in line 17. For example:
chosen_city <- "Manchester"
The script then filters all flow data where both the Origin MSOA AND the destination MSOA are in the chosen city
If you wish to run the analysis on London, then make sure you have a computer that is up to the task. I didn’t :(
This script is used to get the distance and slope between each OD pair
This script is used to estimate where additional cycling demand will come from. Let’s say that the target for Manchester is a 10% increase in cyling mode share, how many additional cyclists do we assign to each OD pair to reach that target mode share
These three scripts plot the results of __3.0_potential_demand.R .
The methodology in __3.0_potential_demand.R insures that OD pairs that have a low cycling mode share are allocated more cyclists than OD pairs that already have a high cycling mode share. In the figure below, the x axis is a ratio of the cycling mode share of the OD pair to its expected cycling mode share. The expected cycling mode share is obtained from a glm where distance, sqrt(distance), and slope are used as predictors. Looking at the resulting cycling mode share, we see that OD pairs between 2-8km have the highest mode share (consistent with bell-shaped distribution of cycling vs distance), and that mode share increase is highest for OD pairs that have lower than expected cycling mode shares.
The dodgr package is used to route the cycling demand (flow) onto the road network. This is done using different weighting profiles, as explained in the documentation of the package. This script is used to download a json file of the weight profile and edit the ‘bicycle’ entries. Weights are assigned to all OSM road types (for example, we assign a weight of 0 to make sure that no cycling routes utilize them). The weighting profiles used are explained in the methodology.
The weighting profiles used in the analysis are in the data file of the repo. These are: * weight_profile_unweighted.json: unweighted shortest paths * weight_profile_weighted.json: weighted shortest paths (weighting profile explained in methodology) * weight_profile_no_primary_trunk.json: weighted shortest paths with cycling banned on primary and trunk roads
These weighting profiles are used in script __4.0_aggregating_flows.R
This script uses the The dodgr package is used to route potential cycling demand onto the road network. This is done for the different weighting profiles used in the analysis
This script is used to identify all road segments that have segregated cycling lanes. This includes all roads that match any of the 3 following tags:
Here we analyze the street network configuration of the city by comparing the unweighted shortest paths to the weighted shortest paths (check methodology for explanation of weighted shortest paths). The aggregated flow shows us which road types are used, and it is clear that cycleways are not utilized unless the road network is weighted to create a hierarchy of road type preference.
Using the potential cycling demand between OD pairs, we are able to define communities in the network. The nodes are the population-weighted MSOA centroids (location obtained from the pct package) and the links between them are weighted by the potential cycling demand between them. The Louvian algorithm is used to assign each MSOA centroid to a community, and then each road segment on the network is assigned to the same community as the MSOA centroid closest to it. The results for Manchester are shown below
This script contains all the functions for prioritizing road segments for dedicated infrastructure. It is necessary to run this script before 8.1 and 8.2. The speed of the functions is inversely proportional to the size of the city being analyzed (Script 8.2 takes almost 2 hours for Birmingham on a 2.7 GHz Intel Core i5 laptop with 8GB of RAM)
Here we obtain results for the utilitarian growth functions (Algorithms 1 and 2 in the paper)
Logic:
Results:
Logic:
Results:
The results show the priority of each road segment (Roads are grouped into 100km groups for vizualization purposes)
Here we obtain results for the egalitarian growth function (Algorithms 3 in the paper). We also compare the connectivity of the network proposed by both algorithms
Logic:
Results:
Priority of each road segment, and utilization of different OSM road types:
We check the number of connected components and the size of the Largest Connected Component as road segments are added to the solution (the components are the road segments). The initial number of components depends on the existing bicycle network of the city. For Manchester, we can see that the existing bicycle network has over 120 disconnected components (Remember we are only looking at segregated bicycle infrastructure, not painted bicycle lanes).
The algorithms seem to provide comparable connectivity gains.