Paths and ways along a road can be mapped separately in OSM, but those separate geometries cannot be identified as part of the road, or only with the significant effort of using geometric processing (which most applications can’t perform). However, the information whether a path is attendant to a road or not is important for many use cases and can offer various advantages.
Therefore, a sidepath concept using the tag “is_sidepath” as an additional tag on ways (in particular cycle ways or foot paths) is proposed to indicate whether a way is related/attendant to a road (i.e. adjacent and parallel to a road) or whether it runs independently/isolated without any relationship to a road. Furthermore, an extended set of sub-tags is proposed to allow to explicitly tag important road attributes on the sidepath itself.
I have seen in your rationale why you don’t want to use relations for that but I don’t think it is a good argument. Tags are easier but recording the relationship between two elements by using a string just seems wrong to me from a data structure point of view. Using a relation for a highway and everything that belongs to it has also the advantage that linking to and from Wikidata becomes much more straightforward.
I must strongly disagree 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.
This is also true about boundary relations, but I don’t think we should throw them into the bin and use is_in instead. I see where you are coming from, but I just don’t think “mappers don’t use this, so let’s create something worse that they might use” is the solution. If StreetComplete had a task “Does this cycleway belong to Main Street?” it wouldn’t matter at all from the mapper’s perspective if the data was added to a tag or to a relation. But the resulting data would be much more useful in case of a relation.
Edit: The same is true about the dual_carriageway tag. Don’t write into a tag that this road is part of a dual carriageway and let data consumers search for the other carriageway. Just put them both in a relation and you are done!
I’m interested in separating side paths from paths that are the whole roads by themselves. Mainly because bicycle only roads get rendered with the same thin line no matter the context. But I’m not sure I like is_sidepath for this. I would rather add something like function=sidepath/road/link and hierarchy=primay/secondary/tertiary to all paths
Sidenote:
I think Booleans are the worst. As you’re moving the value to the key. Instead of saying x is y you say y is true. Then you’re leaving out the other part.
I am not an English native speaker, but I only know the term “sidepath” being used with cycle ways, much as “sidewalk” with footways. Although, I haven’t decided yet, whether I like the proposal or prefer relations, wouldn’t cycleway=sidepath make more sense than is_sidepath=true? This would also align with footway=sidewalk which implies that it accompanies a road anyway. The reasons given on the RFC why this isn’t a good idea don’t resonate with me, because cycleway=* isn’t used for separately mapped cycle ways, except for cycleway=crossing. I don’t see how this poses a problem
This would also question whether the namespace sidepath: for the other tags is a good choice. Maybe alongside: or something more generic, which could then also be used for something else than highways.
I also remember that one of the reasons footway=sidewalk was introduced, was people putting the same name-tag on the sidewalk as on the street, and footway=sidewalk was simply a way to tell the renderer “don’t render the name”. It feels like we’re arriving where we started, and we’re now trying to hit the target from a different angle.
We were able to deprecate is_in because boundary relations, in contrast to street relations, are working. They are rather static, of finite number (and yet in many places they still exist only at higher administrative levels!) and there are “nerds” who deal with their maintenance on a large scale. Roads, on the other hand, exist - well - virtually everywhere and are changing permanently (because they are rebuild or mappers map new features).
Mainly also because you need to think this concept further and then you need bridleway=sidepath, busway=sidepath, service=sidepath and whatever…
I also thought about this, e.g. to assign street_side parking spaces to a street. But I am not yet sure whether this “:of” concept is a good idea at all. Therefore, I wanted to start with an open discussion of what already exists.
That’s the problem with single purpose taggings like footway=sidewalk - if there were a viable sidepath concept, we wouldn’t have to start all over again
That feels like you’re contradicting yourself. footway=sidewalk is too specific, let’s solve it with sidepath. And then next, we have the same issue again, this time for parking=street_side. And then later maybe for amenity=taxi, or, or …
I can see why we want to be able to “link” ways that “belong” to the same street together, and also why some people oppose the use of a relation (I am actually in favor of using relations). But first, I’d like to understand the actual problem we’re trying to solve here. As far as I understand, there are some:
The main issue is that it’s not easy to determine for an algorithm if a sidewalk/cycleway “belongs” to a street, therefore, we cannot give instructions like “drive 3 km alongside 5th road”. Is the reason, that it hasn’t been implemented, really that an algorithm cannot make the link? Are we sure that the suggested tagging would fix this issue? I’d like to hear the opinion of one of the authors of these routing engines, because footway=sidewalk+name=Foo was trying to solve this issue as well, is widely spread, and yet no router (that I know of) gives these instructions
The other issue is rendering. Some would like to render these side paths differently. This would definitely be solvable with your proposal
Data analysis (evaluating the quality of footway or cycle path networks): Not sure if this would be solved by it, but knowing your background, I suppose you know it would.
Your proposal is not making me (fully) happy for the following reasons:
The name sidepath seems confusing to me. Like I said, I only know this as a synonym for a cycle path.
The name sidepath would limit the usage to highway=* items. Don’t anyone tell me that we should tag is_sidepath=yes on parking spaces!
We’re copying a lot of information here, especially when adding :name, :ref and :of. What would happen to roads with several names in several languages? Would we have to copy them all? And etymologies? Relations would be far superior in this regard.
This also creates kind of a hierarchy, which I personally find unwanted. This makes the carriageway the “main” street, and everything else is just a “side path”. A relation wouldn’t have this issue. There are only roles, and one isn’t worth more than another.
As mentioned above, I’m not sure if your solution would actually solve the router issue. I’d like the opinion of someone who’s working in this field to confirm that
A) There is a problem to relate cycleway/footways to streets
B) This proposal would actually solve the problem
I hope I don’t come across negatively. Furthermore, I’m happy that there’s finally some momentum and visibility of this problem, and you’re taking it on. Hats off!
Deriving a cycleway name from an adjacent road is complex and error-prone. I’ve looked into supporting it for cycle.travel and decided against it because, although I could get a first pass at it by implementing a separate PostGIS preprocessing stage, the failure rate was just too high and would result in confusing directions.
I am aware of one routing engine that does it in some circumstances. I personally wouldn’t be happy with the results it generates but YMMV.
In many cases the cycle track should simply be tagged with the same name as the street. In this London example, the cycle track is no less Torrington Place than the vehicle lanes. But there are cases (particularly in rural areas) where I can see the logic of using is_sidepath:of instead.
cycle.travel does that already without any extra tagging
A challenge of using the street relation for the purpose of matching street segments and sidepath segments is that it collects all street segments with the same name. The result is not necessarily a linear or (even nearly linear) geometry, it can be a branching network of side streets.
I worry that the algorithmic challenge of deciding which of the branches a sidepath belongs to might not be any easier to solve than the general case.
I don’t understand how this is a problem the relation solution has but the tagging solution doesn’t have. Can you try to explain it, maybe with an example?
Because they got mentioned several times: Here’s to the Eldorado of street relation mapping - e.g. Relation: 11580909 | OpenStreetMap - this one quite a beast, yet may hint at the workload to expect from tagging all its associated members with is_sidepath*.
There are ~1500 of those relations in the area - https://overpass-turbo.eu/s/1oAc - not all so big. Browsing the ids, looks like they have been created two years ago by one or two mappers in a single month.
I do not immediately see, why these relations should be mostly broken. Would someone explain?
A random observation: From the Lane_and_Road_Attributes style in JOSM it can be seen, that widths tagged on the highways span not just the carriageway, but include the sidewalks.
The relation is equivalent to is_sidepath:of:name in the tagging solution. It doesn’t necessarily give us any other information, such as the street’s highway value, because the relation members can have different values for that key (example). The only property the relation members are guaranteed to share is their name.
Of course, neither of the two solutions gives us all the information we want. A perfect solution would give us at least:
The name, highway type, and other relevant attributes of the street the sidepath belongs to (for the reasons the proposal mentions)
Whether the sidepath is left or right of its street (e.g. for routing instructions)
The exact IDs of the adjacent street segment and the corresponding sidepath on the other side (if any).
And of course, the last item would let us easily derive everything else in the list. But for a relation to give us that, it would have to be a hypothetical relation with just the street segment adjacent to the sidepath, or at least only the linear sequence of street segments between junctions. Not all the street segments in a network of branching side streets.
I think this is a source of some awkwardness. The existing but undocumented street:name key is much less awkward in my opinion and could be paired with street:ref is desired. However, it affirmatively states that the way is associated with a street. In my experience, a sidewalk typically is associated with a street, but it becomes awkward in the relatively fewer cases where a sidewalk is associated with a motorway, driveway, or cycleway. These aren’t obviously “streets” to everyone, but then again, neither are they “highways” to everyone either.
If a highway=footway way is tagged with name, OSRM and Valhalla (and probably others) do announce the name when telling the user to turn onto the way, whether or not it has footway=sidewalk. Whether the router does tell the user to turn onto the way, rather than the street, depends on a number of factors. However, the use of name on sidewalks doesn’t seem to be very popular, possibly because it results in clutter in renderers (most of them) that label any footway with a name. Perhaps one solution would be for renderers to avoid labeling footway=sidewalk ways.
As with a lot of generalization problems, inferring the street name has always sounded daunting to me; I’m glad you gave it a try at least. Similar to routing across areas, I do hold out just enough hope in a future algorithmic solution along the lines of Skeletron that I don’t consider the lack of this derivation to be a dealbreaker for separate sidewalk ways.
One workaround I’ve seen commercially is to simply ignore sidewalk ways, biasing against them, and assuming the user will figure out how to follow the car-centric instructions on foot. But this is only a stopgap in my opinion: it doesn’t handle crossings or interruptions in the pedestrian network very gracefully, and it’s highly susceptible to irrelevant access restrictions and turn restrictions.
I suspect it would be more effective to calculate a route that includes sidewalks and map-match it to the road network (again, biasing against sidewalks), setting each maneuver in the original route as a waypoint. Then you could copy the resulting road names back to the original route’s steps. The advantage to this approach is that OSRM, Valhalla, GraphHopper, and others have already built the necessary components. The server can calculate these associations between streets and their sidewalks on demand rather than globally upfront. That said, anything involving map matching requires some tuning to get right.
The proposed sidepath_of scheme highlights a longstanding gap in our data model, which is that a node or way can only express its relationship to another node or way through a relation that has top-down references to its members. Over the years, we’ve made great use of this capability for things like multipolygons and routes, where the most common use cases require a comprehensive view of all the members. However, in reality, relationships can be more “grassroots” and tenuous.
As a case in point, a destinationsign relation (not to be confused with destination_sign, ugh) seeks to incorporate all the signs that merely mention a city as a destination. One can easily imagine how such a relation might get out of hand. If someone were to set up a destination_sign relation for New York City, it would include as members multiple signs leading to each of some 800 link roads, not to mention a few fingerposts on other continents. A mapper with the misfortune of editing in the immediate vicinity of the New York City node would have to load all these referents as part of a standard API call to get all the relevant data within the viewport.
It’s little wonder, then, that keys like name:etymology:wikidata and destination:ref:wikidata exist to outsource these relationships to Wikidata (relying on a matching wikidata tag on the feature being referred to). Thankfully, Wikidata’s notability guidelines are so flexible that any namesake of a building or any destination of an off-ramp is likely to be eligible for inclusion, and obviously some namesakes will never be eligible for inclusion in OSM. But this solution unfortunately doesn’t scale to the even more mundane relationship between a sidewalk and its associated street.
Is the highway value of the street a path follows important information? If you want to find out, which way a footway belongs to (and not only which street) you’d need to query for nearest match in either case.
I don’t think that is enough compared to the advantages of a relation, mainly the better linking to and from external databases.
Giving this, let me ask some more questions, @Richard:
Would you be able to identify the way-segment of the carriageway if the sidewalks/sidepaths had the same name/were using is_sidepath:of, or are in the same relation?
Would you be able to identify whether a sidewalk/sidepath is running left or right of a carriageway with one of the abovementioned types added?
Would you be able to identify the sidewalk/sidepath on the opposite side of the road with this as well, even if there was no connecting way?
Would mapping streets as areas (which would then include the carriageway, plus every other sidewalk/sidepath, etc.) make this work?
I’m trying to figure out, whether this is possible for the simple reason of maybe not having to add the highway-type/ref to the “sidepath”, or the relation actually making things easier/unambiguous. If only one approach allows us to find the matching way-segment(s) of the carriageway, or even the sidewalk/sidepath on the opposite side of the street, then it would clearly be the superior solution. It would also enable us to route directly over a street in countries where jaywalking is not forbidden. If this works with either or neither of the solutions, then it comes down to personal taste.
That was one of the original motivations of footway=sidewalk: telling the renderer not to render the name. But I guess it got lost somewhere, and I cannot even find proof of my claim on the Wiki. Plus, a lot of secondary/primary roads are better addressed by their ref than their name, at least outside of cities. But if current routers do make use of the sidewalk’s name, that is a good sign.
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.
