You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: