Pathway=* for ways not used by or intended for cars

Thanks, that’s a useful reply.

Right, so we could use highway=residential and map the multiple legal restriction in subtags. Instead we summarise all this in a main tag, making things easier for mappers, and also for renders who want to render living streets differently. Otherwise they would have to look at a whole set of subtags, and work out which combinations correspond to a a living street.

Is it fair to say that your position is “using the main tag to summarise is OK, provided it is based on something easily observable with not much blurring around the edges”? I can understand that. But a lot of the objections to new tags don’t seem to be primarily motivated by that.

On the restaurants/cafes/bars, your comments are only true in a specific cultural context. I have been doing a lot of surveying of local points of interest recently, and the majority of such places near me have two of those words written somewhere - some have all three. I would certainly find it easier to tell a scramble apart from a regular path than to decide whether some of these places are closest to the OSM wiki definitions of bar, cafe, or restaurant. Yet those distinctions are enshrined in the main tag.

6 Likes

no, you could not infer from a residential street that has the same restrictions as a living street, that it is a living street, (although the effect would likely be the same, if a living street requires a sign, there cannot be a living street in absence of the sign, even if the effective restrictions would be the same).

Precisely this!

2 Likes

We seem to come from two completely opposite schools of thought concerning OSM philosophy (and classification in general).

In Serbia – and I believe a similar approach was applied in other countries – “living street” signs were introduced by law a dozen years ago and started gradually appearing in residential streets that had already been quiet, with local traffic only. Little has changed in those already quiet streets, and the signs only gave the pedestrians legal precedence over cars. Except for the sign, nothing physically changed in the infrastructure. In my opinion, it was an overkill to introduce new highway=living_street just because of the sign, but oh well, data consumers quickly adapted and the world did not collapse.

On the other hand, the official road classification falls well short in recognizing many important streets or regional roads as “tertiary” and assigning them a ref (in OSM terms). As a result, we rely on vague OSM definitions and mappers’ best judgment whether they apply. As recently as last month, I upgraded major streets in central Rovinj (a major tourist destination, not a backwater) from residential to tertiary based just on my own “gut feeling” about street width, lanes, presence of roundabouts and stop signs, and overall traffic level. And I would argue that I improved the map for everyone: Previously, both OsmAnd and Organic Maps guided me through the maze of side streets since they were all tagged the same. And I don’t see which data other than highway classification they could rely on, since all of those are lanes=2, smoothness=good, with only slight difference in width. Yet, “I know a major street when I see it”, you know?

The same benefits could be drawn from a finer top-level classification of paths, whichever approach we take. IMO, at minimum, we should invent a top-level tag for difficult and/or pathless mountain trails, rather than rely on sac_scale. highway=scramble was a good try that, in hindsight, I regret not supporting.

10 Likes

To me it looks like the main issue is how to distinguish two different paths in OSM, not in real life. Whether we use a different main tag, or additional tag, or rely on existing sub-tags.

I think it would be simpler if we take two extremes and discuss how to separate them. Once we find a way that is satisfactory, we can discuss if the same can be applied to other cases.

Why don’t we take the first and the third photo from this post:

and try to devise a way to tell them apart? Hopefully it does not take a lot to explain the benefits of having them as different entities on a map.

Edit: I’ve created a wiki post for this:

3 Likes

Yeah, these faultlines exist within the OSM community. And I do get the arguments on the other side as well. The idea of “I know it when I see it” makes sense in many places. Reality is fuzzy.

That’s a good point too. Might not be the end of the world to accept highway=scramble to the most featureless paths, for example.

1 Like

That is however a concern against redefining highway=path. Not against creating a whole new pathway=* tag that could gradualy replace highway=path without causing large mayhem.

As I understood it, @Langlaeufer raised the point that if we create multiple new highway values meant to replace some of the ways currently tagged as path, that necessarily redefines path, and creates the problems mentioned. The only way to avoid this is either to deprecate the path key entirely, or focus on the descriptive tags. Of course, some may suggest that the chaos of interim time is just a necessary evil and not a huge problem.

One problem with high-level tags is that they promote and encourage Duck Tagging. I, personally, think that e.g. Duck Tagged ways with only a highway=cycleway-key should include at least surface= and smoothness= tags as well.

Whenever I’ve raised this point, people have answered that absolutely no one ever needs those, since Duck Tagging surely suffices for everyone for all eternity! To me this sounds a lot like surely 640K of memory is enough for everyone! It isn’t, and neither are Duck Tagged cycleways. They are better than nothing, and that’s it.

This in in partial answer to @Duja above, too. Reality is fuzzy, and top-level tags do have their places (perhaps also for scrambles?), but not everywhere and every time.

I do not see duck-tagging to be in conflict with additional tags. Duck-tagging is good on its own, it leads to easier mapping and using maps for everybody (mappers, renderers and users) due to its lower cognitive load. However, it is not sufficient - other tags are of course needed and welcome. Just as they are with path as it is now.

4 Likes

I don’t know the traffic rules in Serbia, but in Germany a living street implies you can play on the street and pedestrians have precedence over vehicles. This is quite different to a residential street, where you may not step on the carriageway unless you want to cross it, and where you may not cross when a car is approaching (if it isn’t a pedestrian crossing).

It is also not very new in Germany, first implementations were done in 1977.

2 Likes

This is a relatively new concept in the Balkans, where it is perfectly normal to stop/park a car on a sidewalk and expect pedestrians (including disabled) to go onto the street in order to pass them by.

1 Like

The law is basically the same in Serbia and in Germany. The principal difference is in implementation – if you park your vehicle on a sidewalk or drive ruthlessly in a living street, it’s unlikely that you’ll get fined unless you get spotted by a policeman in a particularly bad mood, which we’re in a short supply. And that’s not something we can tag.

Whatever the practice, I would argue it should have been modeled as highway=residential; designation=living_street or similar, since it does not change the fact that it’s basically just a residential street. But that’s water under the bridge, and off-topic for this thread to boot. I only used it as an argument that a legally-sanctioned sign does not necessarily change the essence of the object in question (“essence” being a philosophical category).

2 Likes

I get your point because that’s basically how I feel how cycle streets were implemented in Germany and are typically simply streets with destination traffic for motor vehicles but more importantly for OSM context, these are implented as cyclestreet=yes or bicycle_roads=yes instead of something like highway=cyclestreet akin to what pedestrians have and there are arguments to treat living streets as an additional feature of highway=residential (maybe residential=living_street, given that such streets will were never intended for regular through trafffic and would never be anything higher than this) if this feature were to be added today (and for completion on the other side, motorroad=yes also is orthagonal to the highway classification).

This reminds me of an instance where a rather minor Landesstraße (L, state highway, roughly equivalent to highway=secondary but not always)[1]
was downgraded to highway=unclassified (relevant portion of a thread) under the sole(!) justification that the road is rather narrow (though this change was problematic for the sudden change in classification in the middle and not downgrading it throughout instead of the downgrade itself per se) and in another example (a more personal one), a highway=secondary was downgraded to highway=tertiary under the lowered speed limit (albeit with speed signs and no traffic zone) and lack of priority (which happened fairly recently around the note’s creation) despite its classification as a Landesstraße (with counter arguments that it breaks the road classification and that it feeds into the B 40).


  1. For completion, Kreisstraßen (K, county highways) generally match highway=tertiary and Bundesstraßen (B, federal highways) usually are highway=primary (and Autobahnen / A i.e. motorways are naturally highway=motorway) ↩︎

1 Like

Well, you are absolutely correct! That is, they needn’t be mutually exclusive, but many seem to treat them as such. I think this is really at the heart of the issue! If what you say is really the majority view, it would behoove for the crowd that suggests new top-level tags as the answer to emphasize what you just said above.

If Duck Tagging is—as you say—insufficient, wouldn’t we just be able to cope with the path tag as is, given enough (and not even that many, three or four) descriptive tags? I do see a reasonable use for a new top-level tag for the very extreme cases (e.g. literally non-visible ‘paths’ that really do require mountaineering skills and tools to traverse), but not really for the majority of paths in existence.

So, you see just one additional tag among these samples?

1 Like

I think you were missing the self-contradicting value if sac_scale=difficult_alpine_hiking vs. asphalt and smooth surface, or you misunderstood my intention.

You are saying that a map not intended for hiking would not display this path due to the sac_scale. But why should it, if it’s an asphalted, smooth path? Does a non-hiking map have to know and care about hiking tags, only to not display these paths? Each map will have to come up with an internal ranking of the importance of each of the tags. What is more important: sac_scale, surface, smoothness, incline, trail_visibility? It really depends, and as long as neither value is in the extremes, it’s hard to say. And that’s where – for me – subtags come in, because they have a clear rank of importance, directly under the main tag.

On the other hand, a map displaying highway=path should display all of them, just in different ways, because anything mapped as a path could be a path, even if the renderer or router doesn’t know the meaning of all of the tags. This, for me, means that everything that’s vastly different from a path, should not be a path in OSM, so it’s not being mistaken for a path. One could even argue that highway=path + sac_scale=difficult_alpine_hiking is troll tagging. There is always going to be some overlap between paths and the hopefully created new values for highway. But as long as these edge-cases are well-defined, and I’m sure we will be able to do that, OSM will provide better data for routers, maps, and users in general.

5 Likes

Maybe highway=residential and residential=living_street would have been globally the better way. But as you mentioned in that time nobody came up with that idea. But it would have worked out in theory.

The difference I see to “path” is that there are no such clear rules how to split them up. There is a highway=viaferrata for “ways” where you need equipment in order to use it. That, again there is a clear separation. Everything else I believe is covered by all the existing sub-tags.

If you guys think there is another value for highway necessary which can be clearly separated from path, suggest something specific. All I’m saying, I don’t think it’s helpful to introduce something new, but actually we have a tag for that already. If that is the case, we either need to talk about, why the existing tag is not understandable, how to describe it better or how editors can be improved.

If that’s the case, we rather should think about, how we can ease the use of sac_scale. If that’s what your aim is. If path=* should describe the level of difficulty and sac_scale is too difficult to understand for ordinary mapper/user then changing this might be a good thing to do.

But path might be not a good key, as a path is not only used by pedestrians and the difficult level might depend on the usage. Like a path where you safely can hike on, might be dangerous to cycle on.

That depends on how the data-user reads the data. A conservative user would rather trow away potential faulty data. So the filter could be, if sac_scale is over a certain threshold, ignore that way. At least that would be my approach creating a map for none-hikers. Being on the safe side. Someone might feel, there is something missing, raise the issue to OSM and a mapper could solve the issue.

Same the other way around, If I’m creating a map for hikers, my threshold of sac_scale would be higher and that way will show up on the map as a “cycleway in the middle of the mountains”. Same story, a user might feel strange, report the issue to OSM and a mapper might solve it.

If your intention is to render as much as possible and you don’t care about the safety of your users, you might do it differently. You might ignore sac_scale you might ignore a potential path as well and would render highway=mountain_path with the same red-dotted line as you do with an ordinary footway.

Does a map need to care at all about any specific highway=*? It’s totally fine to create a map where highway=* are all displayed in the same way. All this is up to the user of our data and will never be influenced by us mappers. To answer your question: Yes, I think a map designed for normal pedestrians should care about sac_scale in a same way a map for cyclist might want to care about maxspeed, even though a normal cyclist might not reach 30kph. Simply because it’s not fun to cycle on a road with a maxspeed of 100kph. Similar story for pedestrians, I believe.

You make some very good points.Some general observations.I pass through thousands of trails a year in Greece with my enduro motorcycles and try and mark/improve the map.most times i have no exact info whether the route is public/ private/path/destroyed road that is still a road but most likely never repaired)If you ask(!) you will often get an opinion as an answer.In Greece there is an entire topographical survey of the entire country going on.This will probably take 20 years to decide who owns what as many lands are handed down through generations.I have seen dirt roads tagged as paths (IMHO) because certain individuals thought it was only for them and wanted to "keep it quiet"Maybe in Germany this exact tagging might work but not so well in other countries.Im against the idea,