## Brussels Cycling Potential **Let’s use Open Data to find out which streets are under- or over-used by cyclists** Manuel Claeys Bouuaert Thursday 17 November 2022 FOSS4G / State of the Map Brussels, Belgium <aside class="notes"> 25 min talk (including questions) on 2022-11-17 @ FOSS4GBE Talk in NL, slides in EN TODO: - Spell check </aside> --- I’m cycling through Brussels and wondering… <aside class="notes"> I’m biking in Brussels Navigate with maps and mind Favourite streets, shortcuts, main lines => Mental map </aside> --- *Is my mental map any good?* *What would a map of generally useful streets look like?* *Do people know and use the useful streets?* <aside class="notes"> Other people? Global main lines? Are they used? </aside> --- There’s Open Data on this!  > Adopted by Open Knowledge Belgium <aside class="notes"> "Citizens collecting cycling data to make cities more bike-friendly." Connect Strava, Fitbit or GPS, and upload your GPX Matched to road network, aggregated, anonymised, served as Open Data for planners, researchers, … Data: Bicycle counts, Origin Destination trees per edge Data for Brussels, later world A little dormant now </aside> --- ## What’s the question? How does actual and predicted cycling compare for each street > In other words: are bikers taking the shortest, or unexpected routes? <aside class="notes"> Could closer inspection learn us which shortcuts or detours are popular or under-used? </aside> --- ## What’s the plan? - Draw the actual trips from Open Data - Compute and draw predicted trips through each street - Compare both <aside class="notes"> Count the number of trips on each street Predicted trips by shortest path between all pairs of nodes Hope to show you how QGIS shines at this, and Open Data becomes useful. </aside> --- ## QGIS features that make this possible <aside class="notes"> Detailed recipe includes uninteresting details: projections, clipping Brussels region, merging counts in both directions, … Graph: streets = edges, crossings = nodes Key features of QGIS that make this possible </aside> --- ## 1) Computing all shortest paths ‘Betweenness Centrality’ from the GRASS tools! Implemented as `v.net.centrality`  <aside class="notes"> Predicted trips by drawing the shortest path between all pairs of nodes. ‘Betweenness Centrality’ from the GRASS tools Implemented as `v.net.centrality` Together with other centrality measures </aside> --- ## 2) Extracting vertices from the network `Extract Specific Vertices` in Processing Toolbox <aside class="notes"> Betweenness: Implemented for vertices. So work with vertices and transfer findings to edges later on. `Extract Vertices` in Vector Geometry Tools Don’t need all intermediate vertices in bended roads `Extract Specific Vertices` in Processing Toolbox Specify the vertex indices, and we’ll use `0, -1` to indicate the first and last vertex of a line. Compute the betweenness centrality `length` column as edge traversal cost. 140 000 vertices and 70 000 edges. 20 minutes. </aside> ---  ---  ---  ---  ---  --- ## 3) Data geo-juggling Smooth results to account for nearby parallel roads. Then bring predicted trip count from nodes to (touching) edges. Using `Join attributes by location (summary)`, twice <aside class="notes"> Difficult to handle close parallel streets. Average out over 60 meters (width of ring road) `Join attributes by location (summary)` with `max` to give each node the value of most popular node within 60 meters. Again `Join attributes by location (summary)` to join these node values to the edges that touch the nodes (now with `min`) </aside> ---  ---  --- ## 4) Making data comparable using virtual field Using a virtual field (It's fast and light-weight) <aside class="notes"> Put both counts on same scale Inspect values in histograms Cap off to high counts (10000000 for predicted, 100 for actual) New virtual field with formula: values from -1 to 1 </aside> ---  ---  --- ## Time to put it on the web The `mbtiles` format is useful here. Had to make them custom, using the FOSS tool `tippecanoe`. <aside class="notes"> Webmap, so `geojson` > `mbtiles`. Generate with tippecanoe to have more zoom-levels (not QGIS?) </aside> ---  [link](https://manuelclaeysbouuaert.be/bikedataproject_centrality_webmap/) --- ## What we find - Actual trips seem quite recreational - Predicted trips include long straight roads and clever connections - Comparison shows a.o. that chaussée/steenwegen are under-used <aside class="notes"> - Popular cycling tracks: canal, parks, forest. Big lanes in the East - Local and regional official cycling itineraries don’t show. - Notable predicted: lines, connections, ‘tunnels’. Not small ring! - East-West passage through the city center - Some big lanes are underused. The most notable is Nijvel. Indeed: no counts. Less data in west, but even then! Bad road condition. - Unpopular shortcuts: from Bruxelles West to Ossegem. Keizer Karellaan-Avenue Charles-Quint. - Some over-used roads ~ individual contributions - More over-used in the East </aside> --- ## What do you see? --- ## Caveats - The data is sparse, recreational and from willing donors. - The algorithm computes the simplest shortest paths and ignores alternatives. <aside class="notes"> Donated tracks: - Recreational cycling (more then commuting) - Affluent cyclers, more data in from richer part of town Relatively low number of counts: lower signal to noise Basic shortest path: no elevation/steepness, straightness, track simplicity or intersection avoidance. Handling of second-best options: not done by betweenness centrality algorithm, ad-hoc solutions with max-min </aside> --- ## How might we take this further? <aside class="notes"> - Overlay with (local and) regional cycling infrastructure - Compare BikeData and cycling infrastructure / road conditions - Use by city officials and traffic managers: special care to under-used </aside> ---