1. Sub-tags for details are always useful and should always be added if possible, but they are not a usable solution by themselves 2. A tag to broadly categorize the path quality similar to tracktype would also be useful to have in any case, but like 1. it’s more supplemental and not sufficient to solve the problem by itself.
For my opinion on 3. and 4., see:
I also certainly wouldn’t be opposed to having dedicated tags like 4. for things like e.g. shared foot-/cyclepaths, it’s just that a more gradual approach might be easier to sell there.
It’s a fair question and I don’t think there has been a real attempt to answer it.
See the forum threads on rendering (or not) highway=busway in “Carto” for some things that can go wrong with a new tag even when it is approved in a proposal process. Currently there are weird gaps in the rendering of cities where busways are an important part of the transport system. That in turn discourages mappers from using the new tags, and tends to support reverting to whatever was used previously.
You could say that is not really a tagging issue but a reflection of the excessive weight given to one specific rendering. But for many people the standard layer IS OpenStreetMap.
In this example, the proposed changes would likely lead to the path to the summit of Mt Everest disappearing from the standard layer. Some of us would see no harm in that or even see it as a good thing. But somewhere out there is a mapper who will be highly offended that the Map of Everything would omit such a high profile trail, and would revert it to highway=path.
Mote generally, a new value for a top level key does create work for nearly all renderers, routers, and other data consumers. They won’t know for sure if the new value will become popular. There will be a period where people will see that ways with the new key will be missing from their favourite maps or apps, again leading to the temptation to revert.
Another issue is how to make existing mappers aware of new tag values. Why would you look at editor presets or the wiki if you’re mapping something you have done a thousand times before? Some mappers will naturally tag just the way they always have, adding “wrong” uses of the old tagging at the same time we are trying to migrate to the new tagging. In contrast, with a new subtag, these mappers may not help to make progress but they won’t add to any confusion.
(To be clear, I would support one or more new tags to remove the more specialised levels of difficulty from highway=path, but I am trying to give a fair picture of some obstacles).
Fair points, all of these. In contrast to the busway, some of these tags are either not mapped (climbing paths, pathless routes) because the community does not see them as paths, or would disappear as a path (when converted to scramble), which is what people have actually been asking for. So, the end result would be positive, I think.
I would certainly be nagging the authors of the apps I’m using to implement the new tags.
The rest, of course, would go as you explained, unfortunately. It’s a process.
However, once the reference (wiki) is updated, people can be pointed to read why a certain path was modified. Over time, they would adopt the new tag. Especially once the renderers implement them.
But not enough people, judging by the vote on the previous highway=scramble proposal. I’m not sure anything has really changed that would give a different result if it was tried again.
That’s fair, but note that some of the “no new tags please” comments have been in response to more far reaching proposals to split the main bulk of highway=path e.g. between urban shared use paths versus trails. The issues I mentioned would be far more severe in that situation.
Probably. I’m actually referring to the case in Italy (CAI Salo) plus many cases that ended up in the news.
And, specifically for scrambling, I see it simply as a pathway=climbing with UIAA grade I.
Agree. Sooner or later we would hit something with a wider impact.
The only thing we can do is ask the renderers to implement the tags and, when done, convert the more-prominent cases. Certainly nobody wants their ways to simply disappear.
These are growing pains, yes. But the result is clarity of how to map the subcategories of Path that we have identified so far. At least those revert wars have an end.
Not to mention that OSM gets more functional for a specialised group of hikers/climbers and, at the same time, more safe for the rest of the population.
But the difference is just a convention, no? One could very well add pathway=shared_use to a highway=path + foot=designated + bycicle=desginated" just as you could add pathway=scramble to highway=path + sac_scale=difficult_alpine_hiking. And you can at the same time remove highway=path from scramble much earlier than from shared_use in some distant future (if ever). So this would be much less disruptive (but also probably slower) then introducing new highway=* tags.
For people who were not aware of the busway controversy, these are the rabbit holes:
This is indeed important precedent. For me it is another reason why it would make sense to break highway=path into a new namespace (pathway=*). I also think the problem of busway is partly its definition - “A dedicated, separate roadway for buses” seemingly would includ short links meant for buses only (from a bus station to a road, diversion to a bus stop etc.) but further down the road one learns those are not actually busways. Somehow the assumption is busways are long, but that is not mentioned on the wiki until one gets deep down. It certainly makes the case that the differences between individual pathways would need to be thought through. (one advantage is that since cars require complex infrastructure with links overpasses and whatnot, ways that are not for cars are much simpler in their design, possibly making ducktagging easier).
people come and go and the newcomers would presumably learn from wiki more
even old-timers would start noticing new tags and hopefully would read up on them on the wiki I am probably not an oldtimer (I started contributng 2-3 years ago) but I come back to the wiki all the time even now.
I don’t see a big difference between a way and a relation that only contains nodes. It’s the tags and the way you choose to interpret things that make the difference. A way tagged “marking_nodes=paint” would be unambiguous (I’m not suggesting it, just trying to make a point)
The difference is that a way connects each of the nodes that make up a way directly, and the attributes you give apply to the way as a whole, not only to the nodes. And by that, this connection should somehow be verifiable on ground. But in reality, the route you’re walking to get from node to node isn’t enforced or even suggested – it’s completely up to you. These markings are just “checkpoints”, sometimes hundreds of meters apart. You could cross one of these, not knowing they exist, because there was nothing visible on the ground at all.
A relation on the other hand can just be used as an ordered collection of nodes, in this case the markings. It doesn’t try to define what’s between these nodes, just that they are related in a certain kind of way.
An analogy could be power poles without a cable between them. With a cable, they form a way, without a cable, we would preferably map them as a relation of nodes.
This way of interpreting ways makes a lot of sense. But is it a proposal of yours, or semantics that are explicitly defined by OSM? I suspect it’s the former.
I’m not fighting against such semantics, I’m just making a point that short of making that explicit and binding, I see little difference between ways and pure-node relations. The absence of explicit semantics for OSM objects has created many constraints for us to design improvements, let’s not discard the few freedoms it provides us.
From the very start of the “way” wiki page:
“A way normally represents a linear feature on the ground (such as a road, wall, or river).”
As often happens, a lot hinges on the word “normally”. Clearly there are “abnormal” exceptions, like route=ferry across open sea. So it’s a question of whether adding more exceptions is a good idea.
I’d like to see more explicit and better support for points-only route relations in OSM. I see a lot of uses for that beyond things like climbing routes. For example, sometimes local tourist offices map out walking trails defined by visiting a set of landmarks in a specified order, but without specifying every detail of how to walk between the landmarks. Ferry routes as already mentioned seem like candidates. Long distance bus routes as currently mapped are arguably a bit of a fiction, as the bus operator between 2 cities 300km apart doesn’t necessarily commit to a specific route between those cities. Then there is the recurring question of mapping hiking routes that cross open fields, car parks, or beaches where there is no specific path between two waymarks - not necessarily as dangerous as high mountain trails, but still involving notional ways that are not really verifiable.
What I don’t know is: should that support take the form of encouraging the creation of “virtual” ways to populate the relations, or should it involve improving the tooling and interpretation of route relations so that mappers feel they make sense without connecting ways?
It could be argued that a series of markers or cairns is a linear feature on the ground, no less than e.g. a flight of stairs or a himalayan bridge.
Once again, I’m just trying to stress the balance of constraints and degrees of freedoms that the hazy semantics of OSM give us. The way forward might be in accepting to use these degrees of freedoms to design solutions, not just accumulate the constraints until we have only the popcorn left.
On the API/database level, a way is just an ordered collection of nodes with associated tags.
A relation of waypoint nodes is… also an ordered collection of nodes with associated tags.
The nodes that are part of the collection can have their individual tags in both cases.
There is little difference just purely on the data representation level itself. The main difference is how they are usually represented to mappers in editors and end users on a rendered map. That is purely convention based on how they are commonly used and nothing prevents renderers from displaying a ‘pathless’ way that is just a collection of waypoint nodes in the same way they would if it were a relation.
There are some differences between using ways or relations for that purpose though that should be considered:
Ways are much easier and more convenient to edit than relations
Relations can have additional information about each member via their roles
Relations can have other element types as members while ways are only limited to nodes
(However, I think this discussion would be more suitable for a different dedicated thread.)
Depends which discussion. Going further into ways/relations would probably not help in a thread dedicated to the history of proposals and ways forward. Exploring what this example reveals about design constraints and degrees of freedom would seem useful to me. I’m not convinced that we spend enough time and space talking about methods.
Mostly because it’s not about the topic of highway=path being ambiguous and mostly meaningless by itself, but because it’s about a related but actually inverse problem of how to map something that is currently not mapped as highway=path (or rather, not mapped at all).
It definitely should be discussed, but I think the handling that’s required for migrating existing use cases of highway=path is reasonably different compared to introducing completely new mapping methods (not just a difference in tags) for pathless routes that it isn’t that useful to mix the two.
Everything that should, or currently is mapped as highway=path should be discussed here I think. Whether something that doesn’t have a linear feature on the ground should be mapped as a path … well, I honestly never encountered these, but I would personally not map them as ways, as said before. But it clearly is something worth mapping, and if a solution is to be found, be it as a route or a new “pathless” path – so be it
Just trying to get a sense of where everyone stands right now:
What’s the best approach to improve the scope of highway=path?
Add a sub-type, e.g., highway=path + path=*
Introduce a new top-level tag, such as pathway=*, with values based on usage or function, similar to how highway works.
Move use cases to new highway=* tags, reserving highway=path solely for outdoor trails
Reclassify outdoor paths as highway=trail, limit highway=path to multi-use pathways, and relocate other use cases
Create new highway=* tags for all existing use cases, and treat highway=path as a placeholder for unknown/unverified paths (similar to highway=road but for pathways)
Just keep things as they are and add the proper physical tags.
Stick with the current setup but add a proper foot scale or grade.
0voters
Notes:
Other use cases include pathless routes, multi-use paths, scrambling, climbing, and mountaineering routes.
Feel free to select multiple options if you’re unsure between different approaches
