Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grouping roads/intersections together into logical units #248

Open
dabreegster opened this issue Mar 22, 2024 · 1 comment
Open

Grouping roads/intersections together into logical units #248

dabreegster opened this issue Mar 22, 2024 · 1 comment

Comments

@dabreegster
Copy link
Contributor

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

image
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

@dabreegster
Copy link
Contributor Author

One use case is in the taipei example, figuring out which side to put the sidewalk for https://www.openstreetmap.org/way/1064488314 vs https://www.openstreetmap.org/way/1064488313. Need to know orientation relative to the road

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant