Proposal talk:Key:is sidepath

From OpenStreetMap Wiki
Jump to navigation Jump to search

Flipped yes/no under Tagging

Under the Tagging heading the top bulleted list appears to have the yes and no labels swapped. --Adamfranco (talk) 12:59, 2 December 2022 (UTC)

Oh, you're right! Thanks a lot, it has been there for weeks and I didn't notice it ;) Have now swapped it. --Supaplex030 (talk) 13:15, 2 December 2022 (UTC)
Resolved: Fixed. --Supaplex030 (talk) 14:44, 17 February 2024 (UTC)

Inverse of cycleway=separate?

Isn't this just the inverse of cycleway=separate or sidewalk=separate which uses the road to mark if a cycleway or sidewalk nearby accompanies the road. This just happens to be the 'roads first' perspective that was implemented first, this is the 'bike-ped first' perspective equivalent. I don't see either as right or wrong but I'm calling this out as the proverbial 'elephant in the room' that we probably should address and talk about. --- JPinAR (talk)

The problem is that in OSM we often understand the street centerline as a "representation of the entire street" - especially since there is almost always only one road line in the "middle". You don't want to "project" a road to one of its two parallel cycle paths but all sidepaths to the road. So you need the information at the sidepath and not at the road. --Supaplex030 (talk) 11:16, 3 December 2022 (UTC)
I guess we need a both directional link and this is an argument for using relations. --Langläufer (talk) 20:14, 7 December 2022 (UTC)
This method of tagging seems to better designate the relationship between roads and sidewalks. As of now it is nearly impossible to navigate pedestrian infrastructure using just voice cues and without looking at the map - e.g. if a left sidewalk diverges slighly away from the road to lead to an offset crossing you will get an instruction first to make a slight left turn and then a 90° right turn where actually you need to continue going straight ahead. If a navigator knows that this is a sidewalk of a named street it should be able to tell you to "Proceed *** m along the left side of XXX Street" ignoring all slight deviations from a direct line. This would however require some new tag values like:
  • is_sidepath=left/right/middle - it is not strictly important which side is which as the navigator should tell you the side relative to your destination; house numbering order or highway destination as stated in the name could be used as a reference point;
  • is_sidepath:of=noname - for urban roads having all qualities of a street but lacking an assigned name; should be compatible with noname=yes --VileGecko (talk) 13:41, 28 January 2023 (UTC)

Maybe the ideal solution is neither cycleway=separate OR is_sidepath
I realize that I made my original post about there already being a tag that functions as a pointer between street and side path a little over a year ago and it's one of the few item still not recently resolved. Having come back to the proposal with a fresh set of eyes I'm less inclined to like cycleway=separate as a solution for informing a bike-pedestrian-disabled user that a sidepath is part of what I'd describe as a 'common right-of-way' as a street/road. However, I'm also not entirely inclined to see is_sidepath=* even with is_sidepath:of=* as the 'fix' in many ways for the same reasons we run into a circular pointer issue there side paths can point to roads and roads can point to side paths. I'm going to throw on my "software engineer" hat for a second and when you run into circular pointer references in programming you have issues. In programming when this happens you can't continue to use pointers you have to stop and start using some sort of 'relationship' to accomplish you goals. As it turns out OSM already has a Relation more over the the proposal already points to Relation:street as an alternative and it this that I would submit actually makes for a more practical solution which in a way merges the best aspects of cycleway=separate and Proposal:Key:is_sidepath making this more of the "both" alternative that each could merge into instead of maintaining the 50-50 split on adoption there seems to be today which itself supports that the best answer to this opportunity is in a way 'neither' and 'both'.

What would this look like and what are the pros and cons compared to cycleway=separate and Proposal:Key:is_sidepath collectively?
First, the use of relationships are a way to group and then assign roles to the nodes, ways, and areas within a relationship is nothing new. Look no further than Public Transport where for buses as a good road centric use case the varying roads that make up a route are grouped but then platforms, stops, stations, and so much more are related to a route and themselves can have added details about lighting, shelter, posted schedule and more.

More narrowly we can look at an existing example of Relation:street itself specifically Fresh Pond Parkway (Boston, MA) the first thing you should be able to see upon looking at this relationship already looks a lot like the Illustrations section of the proposal which I believe indicates that this is already a good model for meeting this type of need. The only change to this existing Relation:street model that might be needed is instead of a role of 'pedestrian' for both highway=cycleway and highway=footway an alternative role like 'sidepath' which equates this nicely to 'is_sidepath' as a role neatly, this also opens up a lot with respect to 'bikelane' but I'll cover that further down but the distinction being namely a 'sidepath' being larger 2.4m or greater with a distinct surface from that of the road (as opposed to a bike lane that generally shares a common surface as vehicles with varying level of separation ranging from paint to physical barriers and everything in between).

The pros:

  • In a few ways this might even be better:
  • As is a street changes between road types the relationship shows all of them
  • If a street changes names or has segments there the naming is inconsistent or is very segmented because of speed, lane number, bridges, and other assorted items that break up a street the name=* associated with the Relation:street can greatly simplify this.
  • This is not something that is_sidepath:of:name=* is going to be able to handle
  • Road type changes and even percentages of typing can be done using this over Proposal:Key:is_sidepath:of
  • With roads being broken into countless segments there is no way is_sidepath:of:ref=* would be practical without capturing the road references as a group which this route does already.
  • I mentioned above the linked example already gives the renders in the Illustations section all that is needed would be coloring or emphasis added based on role.
  • With respect to the comment in the proposal, "While there are alternative approaches to this issue in OSM, they are not practical for large-scale use for different reasons". I would say the existence of Public_transport makes relationships proven and practical for this sort of use case at large scale.
  • Realistically the benefits of both side are shared and improved in finding a middle common ground.
  • Ready for the future
  • A good example from bus routes is that with apps and tech some locations aren't definitive stops where a bus would stop every time but can be stop upon request through a mobile app. This type of item could easily be added and roles changed on the fly as technology disrupts how we might presently think about side paths today. A Relation is much more up to the task of being flexible for future cases we can't even think of right this moment.

The cons:

  • If you ever try and remove/change elements that are part of a relationship the process can be complex and difficult.
  • Even this has a silver lining in that newer users are less likely to mess up more complex mappings.

--JPinAR (talk) 20:25, 21 February 2024 (UTC)

Additional considerations
Coming back to the role this proposal plays in a larger landscape of bike-pedestrian-disability mapping. You could title this section, "When side paths and bike lanes collide," but honestly just switching the side of the road a bike lane along breaks things. The issue here is that when you connect two highways that are "roads/streets" to other you have the ability to add a Relation:restriction to say "straight ahead only," "no right/left/u turn", "no entry/exit", and more but some of these start to solve problems that bike lanes not being treated as lanes of traffic but as special add-ons introduces like except=bicycle and restriction:bicycle=*. The issues arise when for instance you have a bike lane on both sides of a road and then a side path enters that road from one side but not the other from at present there isn't a Relation layer that says:

  1. Which bike lane of the two you are joining
  2. How to merge from side path bike lane
  1. Are there crossings?
  2. Are those crossings with traffic or merged into sidewalk?
  1. Because the crossing laws can differ wildly based on which it is
  1. Is there an Advance Stop Line/Bike Box cycleway=asl?
  2. Does any merging happen before, after, or in an intersection?
  1. If a bike lane switches sides at an intersection how does that crossing take place?

And the list goes on. My idea isn't just that Relation:street could or should be only capture side paths but that this relationship layer could be expanded to cover a bigger 'complete streets' view of how roads/streets and bike/pedestrian/disability elements interact with each other in a way that is non-disruptive to the existing road/streets infrastructure. This includes the types of non-covered scenarios might require a highway=cycleway withing a Relation:street with a role of 'bikelane' to cover scenarios where the cycleway:right/left/both=* (but still missing middle as an example of a scenario where an explict highway=cycleway with 'bikelane' role could be needed). Also tagging for how the merging between cycleway and side path should occur covering those complex scenarios.

I added this last part not because it fully relates to the Discussion around this tagging specifically but because it casts perspective on why I think there is more to using a Relation:street to capture this 'side path' idea but also a lot more with a wider vision of "Complete Streets" --JPinAR (talk) 20:25, 21 February 2024 (UTC)

Highway value in is_sidepath:of

Moved to Proposal talk:Key:is sidepath:ofNot related to this proposal anymore, since is_sidepath:of=* has been extracted. --Supaplex030 (talk) 14:44, 17 February 2024 (UTC)

Integrate with Key:side_road?

You probably want to check out side_road=*. It focuses on wider side-carriageways instead of narrower side-paths, but serves a similar purpose. --JeroenvanderGun (talk) 16:36, 2 December 2022 (UTC)

Thanks! I wasn't aware of that. It fits very well with the issue of the Proposal. Using a Key named "sidepath" on roads like this would not be very elegant semantically - and might show even more the need for a general term that does not refer to a specific feature like a "way". For example, I would also like to assign street_side parking spaces to a street. --Supaplex030 (talk) 11:24, 3 December 2022 (UTC)
Resolved: side_road=* is mentioned as an alternative for motorized ways. --Supaplex030 (talk) 14:44, 17 February 2024 (UTC)

Additional attributes is_sidepath:of are not useful and self-contradictory

is_sidepath=* seems useful but the additional attributes is_sidepath:of=* and is_sidepath:of:*=* seem like a bad ideas.

  • The proposal suggests that is_sidepath:of=motorway is useful because it allows routers to avoid cyclepaths near motorways. However, this can be done much more reliably by geographically checking for the presence of highway=motorway in the vicinity of the cyclepath.
  • is_sidepath=yes means that the path is part of the same street as a larger carriageway next to it. In this case, both the sidepath and the main carriageway should have the same street name (because it's the same street) and one should simply tag name=* on the sidepath instead of is_sidepath:of:name=*. Conversely, if the "sidepath" has a separate street name, then it's not really a sidepath anymore (is_sidepath=no), and is_sidepath:of:name=* is essentially useless because navigation instructions can simply use the street name of the "sidepath". So is_sidepath:of:name=* contradicts itself.

So overall only is_sidepath=yes/is_sidepath=no are useful, while the other keys are not needed and only add unnecessary workload when creating/updating the map. The is_sidepath:of=* prefix also makes it harder to keep road classification and name/ref synchronized between main carriageway and sidepath.

Without the additional attributes, the rationale changes as follows:

  • Improved rendering:
    • If is_sidepath=yes is tagged, renderers can decide to not render the sidepath or it's name=*, or render them less prominently, e.g. hide at lower zoom levels.
  • Improved routing:
    • Routers can get the street name of the sidepath from name=* (which they already support), just like normal roads, but may use is_sidepath=yes to tweak the wording of navigation instructions.
    • Routers wishing to avoid sidepaths of busy roads can simply look whether there are high-level highway=*s in the vicinity of a cyclepath.

--JeroenvanderGun (talk) 17:08, 2 December 2022 (UTC)

At least the name=* argument is not valid, because in OSM there is great agreement that we don't use name=* on sidepaths. This is the "entire street" problem again: the "street" (consisting of carriageway, verges, footpaths, cycle paths...) has a name, not its individual parts. The fact that we leave the name on the centerline, i.e. on the carriageway, is due to the pragmatism that we don't have a street concept. --Supaplex030 (talk) 11:32, 3 December 2022 (UTC)
Why is it a " great agreement"? Rather it could be priorities or apathy. This is amplified by editing and applications, if not also renderers. There's no intrinsic difference with adding a name by is_sidepath:of:name=* or name=*, when each application already need to decide what to process.
Multiple carriageways (ie especially more than dual carriageway) already get their own name=*.
--- Kovposch (talk) 18:04, 3 December 2022 (UTC)
I approve is_sidepath=* and dislike is_sidepath:of=* and it's descendants too. In my oppinion, there should be a way to link back to the street where the sidepath is a sidepath of. Type, Name and Ref do not do this adequately, as one still has to do geometric search in the neighbourhood of the sidepath and might get wrong results. A better approach would be the ids of the ways of that street, which would be a relation. (I agree, that relations are a difficult concept and not allways well supported in editors, but the consequence should be to improve the editors.) --Kumakyoo (talk) 16:07, 14 November 2023 (UTC)
Resolved: is_sidepath:of=* is no longer part of the proposal but was extracted to a separate proposal page for documentation of it's status quo. --Supaplex030 (talk) 14:44, 17 February 2024 (UTC)

Attendance

The phrasing "attendant to a road" is so formal that native English speakers won't have any clue what it means and will wonder if there's a nuance beyond what's stated elsewhere in the definition. I think "adjacent and parallel to" is perfectly fine wording, even if it's more verbose. This is the same language used by urban planners. [1] That said, "sidepath" is usually meant in contrast to "sidewalk", which this proposal seeks to conflate with sidepaths. – Minh Nguyễn 💬 17:58, 2 December 2022 (UTC)

Thanks! I will correct the "attendant" issue and appreciate such feedback, as I don't speak English on an expert level, but precise terminology is very important. However, terms such as "sidepath" and "sidewalk" raise the issue that they may have different connotations in different English-speaking regions (or are rather uncommon at all) or between urban planning professionals and "common" language... --Supaplex030 (talk) 11:59, 3 December 2022 (UTC)
Resolved: Wording improved. --Supaplex030 (talk) 14:44, 17 February 2024 (UTC)

Highway landuse as another alternative

Under "Alternative concepts", this proposal could also mention landuse=highway. Aside from theoretically making it possible to collect dual carriageways and sidepaths without relations, this tag also makes it possible to render the highway landuse in a different color, which is a cartographic convention in some countries. [2] – Minh Nguyễn 💬 18:18, 2 December 2022 (UTC)

I will mention this, thank you! --Supaplex030 (talk) 12:00, 3 December 2022 (UTC)
I don't think there's an expectation that landuse=highway polygons would contain the segments and sidepaths for exactly one street? There's also the issue of streets on bridges or in tunnels which are typically not thought of as being part of "landuse" in the same way as a surface-level street. --Tordanik 14:20, 3 December 2022 (UTC)
@Tordanik: I think you're right. In the best case scenario, a single landuse=highway area would represent a single street corridor by analogy with man_made=bridge, but delineating one corridor from another is a challenge that all these approaches suffer from. I mention landuse=highway only because I imagine that some users of this tag have had the same goal in mind of collecting the various ways together. – Minh Nguyễn 💬 02:08, 4 December 2022 (UTC)
Resolved: Some more references to other concepts where added, including landuse=highway. --Supaplex030 (talk) 14:44, 17 February 2024 (UTC)

Areas?

From my point of view, this would heal a single wound created by separately mapped sidewalks, namely putting them back into the street, that they are in. Much like what street relations are set out to. From my observations, such relations are popular in the Boston area only, perhaps due to there living enough high brow mappers. I'd myself considered relations superior, only topped by mapping areas, that specified their traversibility for different means of transport. That would be the only way, to get away from mappers laying rails for cycle or pedestrian routing, however such rail-like routing accomodates current offers. --Hungerburg (talk) 01:47, 3 December 2022 (UTC)

Regarding the topic of street relations, I would like to refer to the thread in the forum in this context (quoting myself: "All street relations that I am aware of (there are not many existing anyway) are totally broken, especially because only a very small exclusive circle of users is able to create and maintain such relations. Therefore, these existing road relations are basically worthless and I don’t see any developments on the horizon that give me hope that this will change. Under these circumstances, I don’t think that’s a suitable way to broadly capture this kind of information.")
Areas could be an alternative approach that would certainly offer advantages for data consumers, but would be much more difficult for mappers to map and maintain (but not as difficult as relations). The existing area:highway=* reaches its limits to identify sidepath (as there are no shared edges) but landuse=highway was mentioned above. There would probably the need to develop a new approach from scratch that comes on top of area:highway=* (like building=* and building:part=*)... --Supaplex030 (talk) 12:14, 3 December 2022 (UTC)
Resolved: Some more references to other concepts where added, including area concepts. --Supaplex030 (talk) 14:44, 17 February 2024 (UTC)

Weak comparison with alternative

As a supporter of cycleway=sidepath, I don't understand the arguments against them.

  1. The difference between "sidewalk" and "sidepath" are not explained
  2. It doesn't conflict with other types
  3. Even if the above are valid, why is_sidepath=* instead of new *way:*=* and path:*=* suffix? There's already the precedence of cycleway:lane=*.

--- Kovposch (talk) 17:52, 3 December 2022 (UTC)

Superficially, 4% of footway=sidewalk has name=*, numerically equal to that on highway=footway. Of course this means it is underused, but it is not insignificant.
https://taginfo.openstreetmap.org/tags/footway=sidewalk#combinations
https://taginfo.openstreetmap.org/tags/highway=footway#combinations
https://github.com/OpenSidewalks/OpenSidewalks-Schema refers to name=* directly in its application.
--- Kovposch (talk) 18:59, 3 December 2022 (UTC)

There is no analysis with name=*, which almost immediately works with all applications. For extreme cases where the sidepath has a different name from the parallel road, you can do the opposite of using a new tag for that exactly.

There is no description on the necessity is_sidepath:of=*. This relates to the case of a sidepath paralleling multiple roadways with different highway=* class, and name.

--- Kovposch (talk) 17:59, 3 December 2022 (UTC)

The main argument against cycleway=sidepath for me at the moment is that a "grouping" concept should be applicable to as many cases as possible, not just footways, cycleways or paths. Looking closer, it also goes beyond e.g. bridleways or busways - in the discussion e.g. side_road=* was mentioned or parking=street_side. Yes, "is_sidepath" does not fit semantically here. We could think about something like related_to instead. But the principle would be similar. (And if we have a "grouping" concept, it doesn't matter if we use name or ...:name, that's right.) --Supaplex030 (talk) 20:15, 3 December 2022 (UTC)
Resolved: Alternative concepts and it's limitations are in the proposal. is_sidepath:of:name=* etc. are no longer part of the proposal. --Supaplex030 (talk) 14:44, 17 February 2024 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Key:is_sidepath&oldid=2667851"