Sidewalks are a relevant part of the living space in urban environments, but there are still few mapped sidewalks. In recent years, the mapping of sidewalks has grown in importance among the OSM and academic communities. To cover up this gap, we propose a Github-hosted, fully open-source QGIS Plugin entitled "OSM SidewalKreator" to automatically draw for OSM the geometries of sidewalks crossings and kerb crossing interfaces. Furthermore, the tool gives the user the capacity to control the process. Then, deepen, improve, and increase the amount of sidewalk mapping in OpenStreetMap to improve accessibility and mobility worldwide.
Sidewalks are a relevant part of the living space in urban environments. The existence of sidewalks and their condition is fundamental to locomotion in general and is critically important in mobility groups such as cyclists, wheelchair users, blind people, the elderly, and children. Also, the displacement along sidewalks can ensure safety from traffic, contributing to the well-being of citizens [1].
There is still an open debate about the best way to represent sidewalks in the OpenStreetMap community. Some users claim that they should be represented only as tags of the streets, using compound tags such as "sidewalk:left/right:surface=*", arguing that over-representation can pollute the map and create unnecessary complexity [2]. Biagi [3] and many OSM users nowadays [4] have been showing the representation of sidewalks as separated geometries as allegedly their best representation in OSM. There are many listed advantages [4]: crossings may be represented as lines, with the kerb interfaces as points (8 in a regular 4-way intersection); the actual traversing length will be represented (as it will include block corners and crossings); independence from the digitizing direction, as "left" and "right" may swap if someone inverts the way direction; ease of representation for pedestrian islands. Moreover, some cases cannot be represented correctly using the tag scheme or will need some cumbersome solutions, as it shall represent the portion of the sidewalk that is orthogonally projected from the street. Therefore, if a property is different on both sides, one may need to split the highway into four segments to represent it correctly. There are also other issues, e.g. geometric properties such as the distance from the sidewalk to the street will stay unclear.
Regardless of the form chosen for representation, there are still few mapped sidewalks. For example, according to Taginfo [5], as of April of 2022, there are approximately 201 million ways with the "highway" key, but only 16.8 million (7.61%) are tagged as "highway=footway", considering the key "footway", there are only 4.8 million (2.45% of 201 million) ways tagged as such (58% sidewalk, 41% crossing), considering the tag "sidewalk=*", there are only 2.6 million (1.3% of 201 million) ways tagged. So, considering that most features are located in urban environments [6;7], where the major part of streets may have a sidewalk, the sidewalks are underrepresented in both schemes. Historically, it has been an issue, as[8] showed that in Berlin, only 5.6% of the Highways have a "sidewalk" tag, growing to only 8.2% in 2017 [9].
Recently, the mapping of sidewalks has grown in importance among the OSM and academic [10;11;12;13] communities. For example, the Open Sidewalks Initiative [14]. They are both a community and a project, providing dedicated mapping with an elaborate scheme on how to map in a pedestrian-centered way, but only manually. Drawing sidewalks and crossings is time-consuming and can be error-prone. This effort can be inferred by examining the OpenSidewalk's own Tasking Manager [15], where in the most near-completion project [16], each task has taken 9.4 minutes to be mapped, but 22.7 minutes be validated. Thus, considering just crossing mapping, for the 1046 existing tasks, it will take approximately 163.9 hours of mapping and 395.7 hours of validation. This total encompasses an area of just approx. 6.17 km2, only 0.65% of the urban area of the city of Sao Paulo, for example.
To cover up this gap, we propose a Github-hosted, fully open-source QGIS Plugin entitled "OSM SidewalKreator" [17], which aims to automatically draw for OSM the geometries of sidewalks, crossings and kerb crossing interfaces, along with the basic descriptive tags. This tool gives the user the capacity to control and supervise the entire process. It contains a user-friendly GUI (Guided User Interface) that enables and disables the buttons according to the step in the process. The plugin methodology, encompassing the steps that the plugin runs through are basically: 1) Fetch Interest OSM data (highways and optionally buildings and addresses, when available) from a bounding polygon given by the user; 2) Generate a table for standard widths for the values for the "highway=*" tag, to provide widths to highways that have no "width=*" key; 3) remove ways that aren't streets, according to a value of width below 0.5m in the table; and split into segments at road intersections; 4) generate the sidewalk geometries based on a per-segment buffer (optionally checking if it doesn't overlaps buildings), dissolve, and a negative then positive buffer to create rounded corners (if wanted by the user) and then finally extract line geometries (inner holes outlines); 6) generate the crossings geometry, using vector that that grows iteratively in a direction perpendicular to the segment or parallel to adjacent segments (according to user's choice), until an intersection with the sidewalks (dissolved as a single multipart geometry) is found, there are also filtering options, to avoid badly generated crossings, such as too long geometries or too close to other crossings; 7) split the sidewalk geometries, since sidewalks properties (smoothness, surface material, etc.) may differ many times in the same block, it can split based on voronoi polygons of building centroids and/or addresses, or with a minimal length, minimal number of segments, only block façades or don't split; 8) output all features, to a single .geojson ready to be imported at JOSM editor, where more inspection on generated data can be carried out. The plugin also outputs other auxiliary files as a .txt with a pre-filled changeset comment and intermediary files for debugging. The tool's first use test was performed in April 2022 to map the Campus Centro Politécnico of the Federal University of Paraná, with transportation engineering students, for the Horus Nav Project [18] an open-source tool for route optimization for blind people.
The key idea that guides the present work is to provide a tool to help intermediary to advanced users to speed up the tedious task of manually drawing sidewalks, crossings and kerbs. The tool does not intend to be a fully automated (a challenging task [12;13]) one-click solution but always calls the user to check out the results, step-by-step, using the resourcefulness from QGIS and JOSM. After the data importing, the user is also encouraged to carry out a validation project on a Tasking Manager. The present work also advocates for the representation of sidewalks as separate geometries as an ideal way to represent the sidewalk network. However, the tag scheme still can be helpful in some specific situations, such as representing explicitly that some highway does not have a sidewalk on one or both sides. Taking advantage of previously available data, including tag schema, is one of the features that might be included in future releases of OSM SidewalKreator and integrating properly with previously drawn sidewalks and crossing restrictions. Finally, by joining awareness in mapping communities, detailed instructions, and tools for automation, we can deepen, improve, and increase the amount of sidewalk mapping in OpenStreetMap and present a solid foundation for improving accessibility and mobility in cities around the world.
