Feature Proposal - RFC - "is_sidepath" as a sidepath concept

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).

1 Like

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.

1 Like

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).

2 Likes

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.

1 Like

I think your knowledge is limited and I haven’t heard it before.

Could you be a bit more precise?

3 Likes

If you would be so kind as expand on your sentence @Kale_Hoffman, that would be appreciated. This comment is vague.