is_sidepath proposal review

[dabreegster]

One of the main problems osm2streets tries to tackle is handling footpaths and cyclepaths parallel to a road. https://wiki.openstreetmap.org/wiki/Proposed_features/Key:is_sidepath is a new proposal. For the sake of this issue (and because it's actually quite a nice term), let's call these sidepaths.

Would this base tag be helpful? If it's used everywhere and we could simplify other detection algorithms, definitely. Until then, it'd give an extra clue and maybe help disambiguate some cases, but it wouldn't be essential. We could keep following our current detection heuristics. The most recent, #61, mostly looks at the graph structure and counts on a short "perpendicular" segment to connect the sidepath to the main road at some point.

I'm not sure is_sidepath:of:name and the further details would have much use for us. Full-blown street relations (a listed alternative) might. Also, there is an edge case with this to consider. The main road could be chopped into multiple ways and change name, highway type, or ref somewhere along. If the sidepath has a long section not split into multiple ways, it could be ambiguous which section of the main road to refer to -- it should be both. This is an imagined edge case for now; I don't have examples.

Another example for the "Edge Cases: When it's a sidepath and when it's not?" section is the Burke Gilman trail near https://www.openstreetmap.org/#map=18/47.66495/-122.30273. It's a separate trail for a while, but then becomes a sidepath of NE Blakeley St for a bit there.

My overall take: this proposal won't affect osm2streets much. https://wiki.openstreetmap.org/wiki/Proposed_features/separation is much more useful and interesting -- first, because it tells us what kind of "lane" we can insert to separate the sidepath and main road. And second, because it tells us which direction to expect the main road to be.

Any thoughts @BudgieInWA?

[BudgieInWA]

The problem of grouping all the parallel related ways together is a hairy one. The hardest thing about it is that there is no consistent definitive definition that everyone agrees on. I've been calling these collections "corridors" recently in my head-canon, though that term might have a conflicting definition in transportation planning.

There is definitely a universal (but fuzzy) concept of multiple ways being a part of the same corridor which is pointed out in the proposal: directions like "walk north on Main St, then take a left at Wattle Tce" are well understood to refer to the sidepaths along those roads. The proposal does a good job of pointing out different motivations for grouping corridors together, which all seem reasonable to me.

osm2streets has to decide what grouping it wants to do for what reasons. I think it would be really cool for osm2streets to have a layer which groups together entire the entire corridor in a way that matches up with the universal naming idea from the directions example. It would be useful for schematic/topologic maps (the ones that distort distances to show the graph topology clearly, like subway maps), for generating route descriptions, etc. all the reasons described in the proposal. It is always going to be a messy and tricky problem, so I think osm2streets is the right place to solve this problem.

I think the proposal does a great job at providing a specific definition to this fuzzy concept and explaining it in an understandable way. I also think that the is_sidepath tag is the perfect approach for OSM. Putting the tag on the sidepaths themselves is the best way to make it easy for mappers to incrementally add this detail to the map (and not inadvertently corrupt it) in a way that a street relation can never achieve. There will always be "is it a sidepath or not" edge-cases because the problem is not well-defined, but if we want to define a binary distinction, the line needs to be drawn somewhere (Burke Gilman trail is a sidepath for some stretches and not a sidepath for others). The exact boundaries of the definition will never be agreed on, but the tagging scheme is probably the most straightforward way of representing the conclusion that has been come to for any particular stretch of path. If is_sidepath was exhaustively mapped, with is_sidepath:of:name clarifying any ambiguity, I think osm2street's job of identifying the corridors would be relatively simple.

If osm2streets wants to snap parallel ways together for nicer rendering^ I think that is a different, more specific concept for which is_sidepath is unhelpful. Plenty of sidepaths wind around trees and other features for their entire length, or for short stretches, while still fitting squarely in the "sidepath" category. I think you're right taht the seperation tag is a much stronger signal here.

[tordans]

Thanks for sharing your thought!

---

One detail for the edge cases examples: As with other attributes, mappers would have to split a sidepath to follow add tags that correspond to it "main path".

If the sidepath has a long section not split into multiple ways, it could be ambiguous which section of the main road to refer to.

IMO, the sidepath needs to be split and have different is_sidepath:of:name=NAME attributes to clear up the ambiguity. We will need QA tools for that at some point …

the Burke Gilman trail near https://www.openstreetmap.org/#map=18/47.66495/-122.30273. It's a separate trail for a while, but then becomes a sidepath of NE Blakeley St for a bit there.

Same here, the path would have to be split with is_sidepath=no in one part and yes in the other. Which is part of the beauty of it, IMO.

---

On the topic of usefulness for osm2streets: I agree that this tag will not solve the "remerge-ways" issue; which will need some other main logic. However, I think you will need it to keep ways split off that are near a centerline but should not be part of the way. Just looking at parallel roads will produce edge cases where paths are next to each other in OSM, but in reality split of by a wall, or a slope or a level. All of which could be mapped with other tags/objects, but the processing will be easier to look at the is_sidepath=no or the fact, that is_sidepath:of:name does not match with the centerline.