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

[SimonPoole]

@Supaplex030

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.

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:

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.

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.

…

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

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