OpenStreetMap (OSM) is widely used as a foundational data source for road network analysis and transportation applications [1,2]. Its road model, however, is built around centerline geometries — efficient for routing and navigation, but not designed for lane-level detail. Existing reconstruction approaches [3,4] typically treat these centerlines as geometric midlines of road surfaces, which produces inconsistent lane connectivity and unrealistic road boundaries when pushed to higher resolution. At the same time, many transportation and simulation applications demand lane-level or trajectory-like representations [5,6]. This study investigates how far high-resolution road representations can be systematically reconstructed from existing OSM data, and under what conditions such reconstruction remains valid.

The paper's central contribution is a conceptual reinterpretation: rather than treating OSM centerlines as geometric midlines, we treat them as structural representations of dominant traffic flow. This interpretation builds on the concept of road strokes [7,8], where adjacent segments are grouped into continuous paths based on topological connectivity [9]. Even where lane counts vary between segments, the connected sequence of centerlines preserves movement continuity by linking successive segment endpoints. The original road network — a directed graph [10] of single centerlines — is then expanded into a directed multigraph of lane centerlines, capturing detailed traffic flow relationships at the lane level [11]. Lane placement is derived from the underlying movement logic of the network, not assigned arbitrarily from geometry (Figure 1a). This reframing makes lane connectivity — rather than geometric position — the organising principle of reconstruction, ensuring that topology, geometry, and OSM tag semantics are addressed together [12].

Before lane reconstruction begins, the raw OSM data is pre-processed into a complete directed graph. Two-way streets encoded as single undirected edges are split into forward and backward directed edges using the oneway=* tag. Cycle lanes embedded within roadways — tagged as cycleway=lane, cycleway:left=lane, or cycleway:right=lane — are extracted as separate directed edges, since they would otherwise be invisible to the reconstruction. Lane counts and per-lane turning functions are then completed for each edge using lanes=* and turn:lanes=*, with turn:lanes also serving as a fallback for deriving lane count where lanes=* is absent. Road segments are grouped into strokes — continuous directional paths representing coherent movement routes [13] — using name, highway=*_link. Ramps as the fork from main stroke are identified and labelled by the bearing angle between the stroke flow the ramp road. The result is a directed graph of topologically clean movement paths, each carrying the lane-level attributes needed for hierarchical reconstruction.

Within each stroke, lane placement is anchored to the basic number of lanes (Smin): the minimum number of through lanes running continuously across every segment of the stroke [14]. This basic number of lanes defines the reference from which all other lanes are positioned outward. Single-direction roads are reconstructed in three hierarchical levels (Figure 1b). First-order segments — where all lanes are through lanes and the count equals the stroke minimum lanes (Smin) — are placed directly from this reference with no matching required. Second-order segments share the same through-lane count but carry affiliated cycle lanes or auxiliary lanes — turn lanes, slip lanes, or merge lanes — alongside through lanes. Thus, second-order lanes inherit through-lane offsets from first-order segments, with cycle lane positions extended using cycleway=* to preserve cycling continuity, and auxiliary lanes offset to the corresponding turning sides. Third-order segments carry different through-lane count and auxiliary lanes, so their configurations cannot be inherited directly. A lane-matching algorithm traverses third-order segments sequentially through the stroke, finding the best-matching slice between the turn:lanes sequences of each segment and its predecessor. For example, where two through lanes (turn:lanes=through|through tag) connect to a segment with turning lanes (turn:lanes=left|through|right tag), the algorithm identifies which slice of the wider sequence aligns with the narrower one, determining the correct lane offset inheritance and alignment across the boundary. Bidirectional roads are processed independently: their OSM centerline is reinterpreted as the dividing line between forward and backward flows, with lanes offset to the right and left respectively.

Lane polygons generated from lane centerlines cannot simply be merged — adjacent polygons overlap at segment boundaries, and converging polygons at intersection nodes produce geometrically incorrect surfaces. A dedicated post-processing pipeline resolves this. A node-degree-based method identifies and trims overlapping polygons at segment boundaries. Intersection polygons are then generated at multi-segment nodes using a buffer-and-retract approach to produce smooth turning corners [15]. The post-processing ensures that the final road polygons have smooth, continuous boundaries free of spikes or abrupt geometry changes, reflecting the physical requirement of real road design. Because semantic information is preserved throughout the pipeline, each polygon type retains its traffic mode identity and can be queried or visualised independently.

The framework is tested on OSM data for Delft, the Netherlands, retrieved from public OSM extracts via the Overpass API. Pre-processing expands 393 raw centerlines into 554 directed edges, adding 41 extracted cycle lanes and 120 backward carriageways. A complete directed representation of all traffic flows is built before lane reconstruction begins, the grouped strokes are identified subsequently. Further, hierarchical reconstruction expands 393 raw centerlines into 657 typed lane trajectories, including through lanes, turning lanes, cycle lanes, and bidirectional carriageways. The positional and functional attributes of lanes are derived from OSM tags, demonstrating that a single centerline encodes enough semantic information to support detailed lane-level modelling. The results show that the framework handles a broad range of real-world urban configurations, including asymmetric turn lane layouts, embedded cycle lanes, dual carriageways with slip roads, and mixed motorized-cycleway intersections (Figure 2). Visual comparison with satellite imagery (Figure 3) confirms that reconstructed road boundaries, lane widths, multiple lane types and intersection shapes correspond to observable road structures across the study area.

This study reframes how centerline data relates to higher-resolution road models: accurate road geometry emerges from the interaction of topology, geometry, and semantics, not from geometric data alone. The results reveal a dual role for OSM tagging — it is both the primary input that enables lane reconstruction and the factor that defines its limits. Where tagging is complete, the framework produces detailed and spatially coherent lane networks. Where it is incomplete, reconstruction uncertainty cannot be resolved by topology or geometry alone, pointing to concrete directions for improving OSM tagging practices. The implementation relies entirely on open-source libraries for working with spatial networks such as shapely, OSMnx, and NetworkX. By shifting reconstruction from geometric interpretation to connectivity-driven logic, this framework expands OSM's functional capacity for traffic simulation, multimodal infrastructure analysis, and urban digital modeling, etc.