A Scalable Methodology for Identifying and Mapping Missing Cycling Infrastructure in OpenStreetMap through Street-Level Imagery and Community Validation

Abstract

2 High-quality and complete representations of cycling infrastructure are essential for transport re3 search, planning, and publicly funded projects. In many countries, OpenStreetMap (OSM) serves 4 as a primary open data source for modelling and decision support in this domain. At the same 5 time, limitations of OSM data completeness – especially for cycling infrastructure – are frequently 6 reported. Detecting infrastructure that is entirely missing from OSM remains particularly challeng7 ing, as such gaps cannot be identified through internal data consistency checks alone, while compre8 hensive authoritative reference datasets are often unavailable. This paper presents a methodology 9 for systematically detecting such gaps by combining automated object detections from crowd10 sourced street-level imagery with spatial analysis of the existing OSM road network. Traffic signs 11 and road markings serve as indicators of cycling infrastructure not yet represented in OSM. Can12 didate locations are filtered through spatial, temporal, and contextual criteria and translated into 13 community validation tasks via MapRoulette. Applied across Germany, the approach generated 14 over 1,200 validation tasks with false-positive rates below 20% among completed tasks. Through 15 the resulting campaigns, more than 500 km of previously unmapped cycling infrastructure were 16 added to OpenStreetMap. 17 Keywords: cycling infrastructure, data completeness, OpenStreetMap, street-level imagery, crowd18 sourcing, volunteered geographic information (VGI), community mapping

19 1 Motivation and Background 20 OpenStreetMap (OSM) (OSM contributors, 2026) has become a widely used spatial data founda21 tion for transport research and applications (Lißner & Huber, 2021; Boeing, 2017; Ziemke et al., 22 2017). At the same time, limitations of OSM data completeness, especially for cycling infrastruc23 ture, are frequently reported (Vierø et al., 2023). 24 In recent years, significant progress has been made in analyzing and refining existing cycling in25 frastructure in OSM. In Germany, platforms such as TILDA radinfra.de (FixMyCity and OSM 26 Verkehrswende Community, 2026) support this process by interpreting OSM tagging schemes and 27 visualizing cycling infrastructure through rule-based representations of the data. Beyond visu28 alization, the platform also provides interactive tools that support users in inspecting and im29 proving OSM tagging, including direct links to relevant OSM wiki documentation and workflows 30 for contributing edits. In addition, radinfra.de integrates MapRoulette challenges that help the 31 community systematically refine and complete existing cycling infrastructure attributes in OSM. 32 However, these approaches primarily focus on improving the quality and completeness of infras33 tructure that is already represented in OSM. They cannot reveal cycling infrastructure that exists 34 on the ground but is entirely absent from the database. A key limitation therefore remains: cy35 cling infrastructure that exists in reality but is completely missing from OSM cannot be detected 36 through internal data consistency checks alone. Until now, detecting such gaps has been requiring 37 extensive local knowledge or manual field surveys, which do not scale to larger regions. 38 This paper proposes a methodology to systematically identify such missing infrastructure by 39 combining street-level imagery, automated detection of cycling-related signs and markings, and 40 community-based validation workflows within the OSM ecosystem. 41 Previous research has extensively examined the completeness and usability of OSM for represent42 ing cycling infrastructure. Several studies compare OSM with authoritative or municipal datasets 43 in order to evaluate data quality. For example, Hochmair et al. (2014) assess the completeness

44 of bicycle trails and lanes in OSM by comparing them with official planning data, while Ferster 45 et al. (2019) analyze OSM cycling infrastructure against municipal open data from several cities. 46 More recently, the BikeDNA framework, introduced by Vierø et al. (2023), provides a system47 atic approach for assessing the quality of cycling infrastructure data in OSM. In their study, the 48 authors apply this framework in a nationwide comparison between OSM and the Danish GeoDan49 mark dataset and show that neither dataset alone provides a complete representation of cycling 50 infrastructure. 51 At the same time, recent work has highlighted the potential of crowdsourced street-level imagery for 52 deriving infrastructure-related information from visual observations. Platforms such as Mapillary, 53 a crowdsourced street-level imagery service, provide large-scale visual data that can be used for 54 infrastructure analysis. For example, Kapp et al. (2025) use Mapillary (2026) images to analyze 55 road surface type and quality and compare the resulting observations with OSM data. 56 In parallel, community-oriented platforms such as MapRoulette (2026) demonstrate how dis57 tributed microtasks can support targeted improvements of open geographic data. Majic et al. 58 (2021) generate candidate errors using spatial reasoning to identify potentially inaccessible build59 ings in OSM and publish them as MapRoulette tasks for community review. 60 Our contribution connects these strands by using street-level image detections not only for analysis, 61 but for the systematic identification and community-based validation of potentially missing cycling 62 infrastructure in OSM. This is particularly relevant in countries like Germany, where comprehensive 63 authoritative datasets for cycling infrastructure are not publicly available and comparison-based 64 approaches therefore cannot be applied nationwide.

65 2 Observing Infrastructure through Street-Level Imagery 66 A central challenge in assessing the completeness of cycling infrastructure data is the lack of 67 reliable ground truth. Verifying the presence of infrastructure through direct field surveys would 68 require extensive local knowledge and large-scale observation efforts, which are difficult to achieve 69 consistently across larger regions. 70 Street-level imagery provides an alternative form of observational evidence. While commercial 71 platforms such as Google Street View or Apple Look Around offer extensive image coverage, their 72 licensing terms do not permit the use of imagery for direct contributions to OSM OSM contributors 73 (2026). In contrast, crowdsourced platforms such as Mapillary (2026) explicitly support OSM-based 74 mapping workflows and provide open access to machine-learning-based object detections derived 75 from the imagery. 76 Mapillary hosts large collections of georeferenced images documenting road environments at differ77 ent locations and points in time. In addition to the imagery itself, Mapillary provides precomputed 78 object detections generated by its machine-learning pipeline1 . These detections identify objects 79 such as traffic signs (Figure 1a) and road markings (Figure 1b) and can be accessed as georeferenced 80 features. 81 In the context of cycling infrastructure, such detected objects can serve as indicators of the likely 82 presence of cycling infrastructure in the surrounding road environment. Rather than relying solely 83 on existing OSM data, these observations make it possible to infer candidate locations where 84 cycling infrastructure may exist, but is not yet represented in the database. These observations 85 form the conceptual basis for the methodology described in the following section.

Cf. https://www.mapillary.com/developer/api-documentation?#traffic-sign-tiles, last accessed 26 March 2026.

(a) Traffic sign detection (traffic sign at the (b) Bicycle marking detection (source: Mapilright edge, source: Mapillary). lary).

Figure 1: Examples of cycling-related object detections in street-level imagery.

86 3 Methodology

87 The proposed workflow identifies candidate locations of potentially missing cycling infrastructure 88 by combining automated detections from street-level imagery with the existing OSM road network.

89 1. Detection data preparation 90 Automatically detected traffic signs and road markings related to cycling infrastructure are 91 extracted from the Mapillary detection dataset. These detections provide spatial indicators 92 of cycling-related infrastructure in the road environment. 93 2. Filtering of detections 94 To reduce noise and false positives, detections are filtered based on the following criteria:

95 • Temporal recency: Only detections with a timestamp newer than January 1, 2025 are 96 considered. 97 • Multiple independent observations: At least two observations of the same object are 98 required. These observations must be separated by a minimum time interval of nine 99 months to ensure that temporary objects (e.g., construction-related signs) are excluded. 100 • Contextual constraints: In the context of German motorways, several blue-and-white 101 signs visually resemble bicycle signage, which can lead to false positives. Therefore, all 102 detections within a radius of 30 m from motorways are excluded.

103 3. OSM network preparation 104 The current road network is extracted from OSM data via Geofabrik extracts (Geofabrik, 105 2026) using the Osmium toolkit (Topf, 2026) and processed to obtain cycling-relevant road 106 segments. Existing cycling-related tags are identified in order to distinguish already mapped 107 infrastructure from potential gaps. 108 4. Spatial association and gap inference 109 Detected objects are spatially associated with nearby road segments in the OSM network. 110 For each detection, all road segments within a predefined search radius (25–30 m, depending 111 on the task configuration) are identified, accounting for positional uncertainties in both the 112 detection data and the OSM geometries. 113 The associated road segments are then examined for the presence of cycling-related tags (e.g. 114 highway=cycleway, cycleway=*, or bicycle=designated). 115 If at least one such segment exists, the detection is assumed to correspond to already mapped 116 cycling infrastructure and is discarded. Otherwise, the detection is retained as a candidate 117 mapping gap. 118 This conservative heuristic prioritizes a low false-positive rate over exhaustive detection and 119 provides a reliable basis for subsequent community validation. While some edge cases may 120 therefore remain undetected, the resulting candidate locations provide a reliable basis for 121 community validation tasks.

122 5. Operationalization via community tasking 123 The resulting candidate locations are translated into microtasks and published as MapRoulette 124 challenges2 . Human mappers inspect the associated imagery and local context in order to 125 verify the observation and update the OSM data if necessary.

(a) Situation before mapping. (b) Cycling infrastructure added to OSM after validation.

Figure 2: Example of a candidate mapping gap identified by the workflow and the corresponding OSM update. (Source: TILDA radinfra.de)

126 As such, the workflow is semi-automated: detection, filtering, and task generation are automated, 127 while final validation and mapping decisions remain with human contributors.

128 4 Implementation and Supporting Tools

129 The proposed workflow is implemented through a set of open-source tools that support the different 130 stages of the pipeline, including the processing of street-level imagery detections and the generation 131 of community validation tasks:

132 Processing of Mapillary detections.

133 Automated detections of traffic signs and road markings are retrieved and processed using dedicated 134 scripts3 developed for this project. The tool extracts cycling-related detections from the Mapillary 135 dataset and applies the filtering procedures described in the methodology section (cf. sec. 3), 136 including temporal filtering and aggregation of repeated observations. The processing pipeline is 137 designed to run on a regular basis (e.g., weekly), ensuring that newly available detections from 138 street-level imagery are incorporated into the workflow. The set of considered bicycle-related traffic 139 signs and their corresponding Mapillary labels is summarized in Table 1.

MapRoulette challenges: Traffic Signs, Road Markings, last accessed 30 March 2026.

Cf. https://github.com/vizsim/mapillary_trafficsigns, last accessed 30 March 2026.

Table 1: Overview of bicycle-related traffic signs used in the analysis (‘TS Code’ is traffic sign code according to German traffic law).

TS Code Description Traffic Sign Mapillary Label DE:237 Bicycle path regulatory–bicycles–only–g1

DE:240 Shared pedestrian and regulatory–shared–path– bicycle path pedestrians–and–bicycles–g1

regulatory–dual-pathDE:241 Segregated pedestrian pedestrians-and-bicycles–g1 and bicycle path regulatory–dual-pathbicycles-and-pedestrians–g1

DE:244.2 End of bicycle road regulatory–end–of–bicycles–only–g2

DE:1022-10 Bicycles permitted complementary–except–bicycles–g1

DE:1000-33 Contraflow cycling complementary–bike–route–g1 permitted

140 Generation of MapRoulette challenges.

141 Candidate locations identified by the workflow are automatically converted into microtasks for the 142 MapRoulette platform. Separate tools generate tasks for different types of infrastructure indicators:

143 • traffic sign detections4 144 • road marking detections5

145 Each task links the detected object to the corresponding street-level imagery and the nearby OSM 146 road segment, allowing mappers to quickly inspect the visual evidence and update the map if 147 necessary. 148 All tools used in this workflow are openly available and may be adapted for related infrastructure 149 mapping tasks in other regions.

150 5 Results and Evaluation 151 The effectiveness of the proposed workflow is evaluated along two dimensions: first, the plausibility 152 of the generated candidate tasks and the resulting validation outcomes, and second, the measurable 153 additions of previously unmapped cycling infrastructure to OpenStreetMap.

154 Task validation through MapRoulette.

155 The first evaluation dimension concerns the plausibility of the generated candidate tasks. Task 156 outcomes from the MapRoulette platform provide a direct indication of whether the automated 157 detections correspond to real mapping gaps. Contributors can either confirm the task by updating 158 OSM or mark it as “not an issue”. 159 Two large-scale MapRoulette challenges (as described in sec. 4) were generated, focusing on traffic 160 signs and road markings respectively. The proportion of confirmed fixes serves as an approximate 161 indicator of the false-positive rate of the detection pipeline.

Cf. Task generator for traffic signs on GitHub, last accessed 30 March 2026.

Cf. Task generator for road markings on GitHub, last accessed 30 March 2026