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.
I’ll just leave this here for anyone who hasn’t watched it. Good in depth discussion of the various issues raised.
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:
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:
is_sidepath:of, or are in the same relation?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.
That was definitely the case (and I’ve used it a lot), the relevant discussions are likely buried somewhere on a mailing list / forum. I don’t see any utility in duplicating the semantics in YAT (yet another tag) is_sidepath.
Outside of that I would strongly recommend against trying to implement “relation-like” functionality with tags (see is_sidepath:of=, is_sidepath:of:name=, is_sidepath:of:ref=*). Without special editor support it is going to be even more brittle than using relations to model the same thing (and I’m saying that as a really not big fan of relations).
I think the idea was that there could be two nearby parallel roads with the same name, of different classifications, and the sidewalk should be associated with one and not the other. This scenario frequently occurs with frontage roads, which in some places are typically named after a more major parallel roadway. Some examples:
That said, if the parallel roadways all have the same name, then it doesn’t particularly matter which roadway a router would infer the sidewalk’s name from.
I can only really answer for my use cases, not for some putative router that I don’t write.
Tagging the name (say) on a parallel cycleway means I can use the name in directions. Tagging the type of road it’s adjacent to means that I can adjust routing weight accordingly.
If it’s not explicitly tagged, but it’s in a relation, I can use that to figure out the above. It would require some pre-processing but that’s not a massive deal.
A relation is conceptually the tidiest option but relations are brittle, often hard to edit, and lead to unwarranted growling at newbies by self-described “power users”. I think it’d need pretty comprehensive support in (in particular) iD for a relation-based solution to fly.
Area routing is not widely supported and I don’t think it’s going to be widely supported any time soon. Bear in mind that routing software treats OSM data as a graph and generally has no or limited geometry analysis capabilities. (I do a bit of PostGIS-based preprocessing but it’s not common.)
Well, we have the choice between keeping the status quo (which makes some data consumers lose their heads, see e.g. the conference talk above), i.e. wasting potentials or developing improvements.
Assuming we are interested in improvements, there seem to be three approaches:
The use of relations, that are established, but unfortunately not usable for the purpose we are talking about (for the reasons mentioned above). To change this, it would require an absolute revolution in relation support in at least one, better both major editor(s), so that street relations, for example, become visible, editable and maintainable for most mappers. As already written, I am not aware of any developments that give me hope that something can be expected here in the coming future.
Establishing an area model to group related ways that together represent a “street” in an evaluable manner. This already exists rudimentarily, but has barely gained acceptance. It is an relation-like alternative model, too - and the mapping effort is rather high to represent a simple piece of information (“this way belongs to this street”).
The introduction of a tag-based relational system for “simple” use cases like assigning a way to “its” street. Various approaches are currently developing “wildly” here (e.g. is_sidepath, cycleway=sidepath, side_road, steet:name). To be honest, I cannot see how you come to the conclusion “even more brittle than using relations to model the same thing”, because this approach seems to me to be by far the simplest of those mentioned and therefore, in my opinion, deserves more attention (that’s why I started the discussion).
Yes, is_sidepath is probably not the best pick/term to represent the third approach, but let’s discuss the idea itself. Maybe a term like related/related:name is more appropriate to be applicable beyond streets (e.g. who want’s to map or evaluate a relation to relate an entrance node to the shop node it’s belonging to?).
I see parallels to the sidewalk naming issue, but I don’t think entrance naming is nearly as intractable. In this case, I’d prefer an approach I often see, even among inexperienced mappers: duplicate the name of the shop on the entrance. I even occasionally see inexperienced mappers approximating the interior footprint of the shop as an area, which I can only agree with, with the caveat that the area should be connected to the entrance node. That way the name doesn’t even have to match. Many more such heuristics are possible for refining navigable points without needing a new tagging scheme.
That is not an argument one way or the other. Conferences are full of talks that moan about one aspect or the other of OSM, I was once present at an EU conference at which a Tomtom representative went to great lengths to show that OSM is total rubbish and is unusable. Obviously we should have taken that seriously and disbanded.
For the following note that I’m not proposing a relation based solution and I’m not convinced that we need anything more than we already have, but to clear up any misconceptions:
All modern editors that support geometry operations on ways already support handling of relations when splitting and merging ways. These are by far the most common operations on ways and those that will effect any scheme that wants to link elements of any kind to ways.
…
A scheme that instead of modelling the topological relationship (aka this is a sidewalk that runs along this list of highway segments) does as it is proposed here, needs to take in to account name changes, splits, merges, additional ways with the same names, classification changes and I suspect lots of things that don’t come to mind immediately.
None of this is “simple” to implement. For example to be able to point out that a user changing the name (or highway classification and ref) of a road needs to fix the sidewalks referring to it, you will need to have logic to find such sidewalks potentially downloading further data (something which editors already support for relation members) that wasn’t initial available. If the user splits a road and changes any of the relevant attributes, again you are going to have to split and modify the sidewalk. And so on.
As I said, I’m not arguing for a relation based solution, but it should be noted that none of the operations I just mentioned would require any manual action on the sidewalk or the relation (as said this would already be covered by the default automatic mechanism and wouldn’t require any implementation of specific semantics).
That is only a very small aspect of dealing with relations in this context imho. Others are: How comfortable is it to create relations? What skills do I need if I map a path in order to make it part of a relation? How can I check whether I have done everything correct if I am rather inexperienced with this? How can I check the members for completeness, their roles for plausibility, etc.? What possibilities do I have to systematically check and adjust relations? …
It does, that’s why it comes with the suggestion of “attribute adoption” to refer to unique attributes if needed. For 95% of all cases, this part is probably unnecessary, but in non-standard situations it could be helpful.
Where is the difference to a changing address, e.g. when a street is renamed? For almost all street renamings in my area, I have experienced that the first mapper who mapped it of course did not adjust the addresses. But this is corrected over time. In the case of streets, perhaps even faster, when people wonder about incorrect routing directions.
Note that addresses don’t necessarily change just because the street name changes. That may be the case in many places, but in many other places, old street names can correctly persist in addresses, names of overpasses, names of subway stations, and so on. By contrast, the case your proposal attempts to address is one where the sidewalk’s name necessarily changes as a result of the street’s name changing.
Does it make sense to focus where the accompanying street is? So street:right:name=. This would prevent confusion by indicating where the sidewalk or other companion path in relation to the main way making the exact street name helpful but not required.
While still not sure, how the proposed tags are kind of replicating what relations are for through tags, meanwhile I learned from looking at who created them, those North Boston separate footways/sidewalks and street relations; almost all were mapped by outsourced facebook personnel from India. Anybody aware of how this corporate investment into OSM paid out?
I’ve never heard of Facebook/Meta intentionally incorporating street relations into their mapping process before. Sometimes individual corporate-affiliated mappers discover an obscure wiki page and run with it, thinking it’s a best practice in OSM when it isn’t really. Maybe that’s what happened here.
Maybe try and talk to some of the editors involved about it? Picking an example at random, the FB contributors to https://www.openstreetmap.org/relation/11568380/history aren’t currently active, bit it still might be worth a changeset disussion comment or three asking for more details - it’s quite possible you’ll get an answer from FB directly.