a-b-street / a-b-street/osm2streets
Grouping roads/intersections together into logical units
- Dominant language
- Jupyter Notebook
- Stars
- 155
- Forks
- 14
- PR merge metrics
- No merged PRs in 30d
Description

The big pink intersection is surrounded by crossings that overall better define the overall shape of the junction.

The east/west road similarly has a loop of sidewalks/crossings surrounding it. (Actually this case is more interesting, because there are service roads interrupting things)
In both of these cases, a higher-level logical "view" on the raw edges and nodes is starting to become clear. There have been a few attempts before to handle this kind of thing, like the "zip sidepath" experiments in #210, but they've never made it far. Now that separate footways are showing up much better, I'd like to try again with a fresh idea.
# Part 1: just find a cycle
Starting from a manually chosen node, use DFS to find the smallest distance cycle in the undirected graph. It'd be best to start from nodes connecting only sidewalks (and footway crossings), to represent those corners on a junction. Maybe constrain the search to only/mostly use sidewalks, or wind up with both cycleways and regular road in the resulting loop. Just start by displaying all the matching Intersections and Roads along the way.
# Part 2: trace a polygon
Next, turn that cycle into a "face" / polygon by walking around the cycle's geometry in order. Previous work in the LTN blockfinder, route snapper area mode, and references in topojson / mapshaper. Just start with the original OSM center-lines. If rendered geometry is very nice, then we could try the edges of road and intersection polygons, but that ambition is what makes LTN blockfinding so buggy. So probably just stick to center-lines.
By looking at what a cycle contains, then we can maybe decide to render these polygons. In between sidewalk/crossings and regular road, we could infer that as the full shape of the pavement. Or maybe there's a grass verge between the road and sidewalk.
# Part 3: consider merging / zipping things
This is where previous attempts too quickly leapt. But sometimes it might be useful to simplify the graph structure and copy over the lanes to the "main" road. Many parts of this process are hard, so that's why it'll be an optional step and only after the other two parts work reasonably. If it works, would be an alternate approach to something like https://github.com/nptscot/networkmerge
Contributor guide
Research direction
The issue describes a multi-part algorithm to find cycles in a graph of sidewalks and roads, trace polygons from them, and optionally merge geometry. Start by exploring the existing graph structure in osm2streets, likely in modules handling OSM conversion and geometry. Look for prior work like the 'zip sidepath' experiments (#210) and LTN blockfinder. The goal is to produce a visual polygon representing logical units like junctions or road loops.
Written by the indexing model from the issue text.
Assessment
- Domain
- data-visualization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100