New siblings of foot/cycle/bridle/way

General talk
, , , , ,
1

There is some momentum in the talking community, that mentioned three modes of transport need additional top-level tags in the highway key space to accommodate for the breadth of human traffic not covered by highway=track|service|unclassified|residential|tertiary|…|motorway

Beware, the list does not include highway=path, because that was not devised a sibling but the mother of the siblings alluded in this topic – rather it was conceived of a sibling to highway=road, so to say. At least that i learned from contributions to related topics.

The movement already brought about:

This topic meant to collect ideas of new so-called top level tags. Please add your own to the list! Please share discomfort in the linked topics.

1 Like
2

Preparing for the near future:
highway=flyway, for official public drone flight paths

3

Just to make a point about introducing new tag VALUES to the highway= key - Nope - Will oppose.

The Vietnam issue is IMHO pretty easy. Its still a residential road. If its just physically to narrow for cars - tag a width - routers today know about it and will not sent car/2 tracked vehicles down there.

If its a legal issue - e.g. a “motorcycleway” with the signage in that thread its a motorcar=no motorcycle=designated - Its still a residential as its purpose is to make a residential area accessible.

But dont invent new road types which are 100% identical to other road types, just imply some access tagging.

1 Like
4

Since Via Ferratas now have a separate tag, I don’t see a reason not to map the climbing routes with an appropriate new tag.

Edit: I think your scrambling proposal would also fall under that.

1 Like
5

Before you start collecting new highway values, you should perhaps first consider what types of non-motorcar ways you want to distinguish from roads and tracks. I know you already did a lot of investigation into highway=path, but I would include footpaths and cycleways and bridleways in the considerations too, because path was the “solution” for all things not fit into this 3 classes.
The second step may be to look how the things are modelled at the moment and at the last step, you could look at what type of tags you can use to achieve this (subclass-tags, new highway values, attributes)

1 Like
6

Given that mappers cannot seem to agree on even one tag or definition (neither in the field nor in this forum), wouldn’t a bunch of new tags and definitions just add more disagreement?

3 Likes
7

I’d expect that with more feature tags (aka top level tags) for paths there would be a similar amount of disagreement, but it would be less consequential.

For classifying motor vehicle roads we have 7 main feature tags—21 feature tags total with special road types and link roads included. (See: Key:highway - OpenStreetMap Wiki) Disagreement over road classification is common, but it’s usually over small adjustments within the classification scale. I.e. one mapper thinks a road should be highway=unclassified and the other thinks highway=tertiary. We’re generally not seeing disagreements where one person is arguing for highway=primary and the other is arguing for highway=service.

I’m very glad we don’t just have one feature tag for all roads from motorways to driveways. This would lead to big disagreements over how data consumers ought to interpret it. Some people would say they should assume nothing and rely entirely on property tags like width, maxspeed, surface, lanes, etc. Others would point out the large number of roads mapped without any of those tags and the data consumers that don’t support them. It would be a mess. The current system at least means that a road mapped with just one highway=* tag and nothing else gets interpreted in a somewhat reasonable way by most data consumers. It’s not perfect and adding property tags is good, but no one is arguing about driveways and motorways looking exactly the same on a bunch of OSM based maps and that’s generally a good thing.

11 Likes
8

Dedicated tags for:

  • scrambles
  • mountain bike trails
6 Likes
9

highway=mup for multi-use paths that can be used equally by pedestrians and cyclists

1 Like
10

Thank you for the suggestion. The suggestions should be workable though. mup is core path competence. At least in central Europe. Meaning, it is impossible to change that. Others just use cycleway+foot=yes or footway+bicycle=yes. Such a transition could be done with no or little harm. But I do not expect this happening.

11

No comment on the merits (or possible lack thereof) of highway=mup, but anything being a core path competence is debatable and inconsistent across the world as the recent discussions have shown.

In any case: Thinking about concrete names/values for tags first is the wrong way around to approach this. Find concrete use cases and well defined criteria for the features that should be defined in human understandable natural language first and then think of a fitting tag value.

1 Like
12

This the other core competence of highway=path. This the one unconditionally accepted all over the world, so it seems to me from following several discussion. Unlike mup, that is.

That was my idea when suggesting to @Tolstoi21 to create presets. Even these have to get a name. And then, they would be limited to the vocabulary of openstreetmap keys and tags. And the vocabulary simply falls short. So your suggestion to use plain language maybe a way further indeed!

Suggestions welcome!

PS: One advantage of mup : no need to tag horse=no, snowmobile=no, etc.

1 Like
13

If you are suggesting that plain highway=path without any other classification is fine for some current uses then those parts will continue to suffer from the existing ambiguity.

New alternative methods to define some use cases more clearly won’t reduce the problem for existing and future highway=paths.

1 Like
14

I hold the principle of on-the-ground verifiability in high esteem. We don’t map airways for that reason, and - unless they are marked on the ground - we shouldn’t map drone paths or anything like that. Neither should “pathless paths” be mapped as ways because that forces them to have a non-verifiable geometry; instead, route relations should be designed such that a gap in the relation can be designated as a pathless traversal.

4 Likes
15

First off, dedicated ways for motorcycles are not found in residential ways, and again there is no proposal yet. Second, you categorically reject new tags but never respond to the flaws in your reasoning:

16

Thank you for the cue, and also thank you for all the threads you have started. They have spawned important and interesting discussions!

I’ll try to be as brief and succinct as I can here.

So, an idea would be to create named presets in the coding tools (rather than new highway values because of what @Langlaeufer eloquently said here ). In my idea, these would have highway=path and different additional descriptive tags that the user would have to fill in. Also, I hail from Finland where Freedom to Roam laws grant near universal right to walk and bicycle everywhere. So here =path implies foot=yes and bicycle=yes, but this is probably not universally true.

One preset might be “Hiking path/Multi-use path”. This would require surface to be either in the paved superset (but coded with the more accurate asphalt/paving_stones/etc.) or a firm fine_gravel/compacted, etc. It would have to have width of at least 2 m and at least smoothness=intermediate.

The second preset might be called “Informal path”. surface could be not only in the unpaved superset as above, but possibly in the ground superset (e.g. grass or dirt). width may vary, but has to be striclty and well below 2 m. smoothness can be bad or worse, and informal=yes when needed & applicable.

Lastly a preset for the “Pathless” case, which would have surface only in the ground superset (but with a specific value). If width cannot be reliably estimated, trail_visibility=intermediate or worse has to be put in. informal=yes is implied?

smoothness is of course always a personal estimate, and its meaning depends on the value of the surface tag as well. This isn’t a huge problem, as e.g. values of bad or horrible do convey a usable, if fuzzy, meaning nevertheless. Width doesn’t have to be micrometer-accurate. Most people can eyeball that value to about within half a meter (two feet). The path wouldn’t have to be exactly that wide throughout, but it shouldn’t be substantially narrower for substantially long stretches either.

These are obviously just tentative suggestions, but perhaps a start. Criticism and further suggestions are welcome! Also, this may be fundamentally a very bad idea. If you think that, here is a good place to document why to prosperity!

Also, there is probably enough overlap that further classes would be warranted between or beyond the ones suggested. I any case, these classes would answer the question, whether one can stroll in the path in leather-soled oxfords, or if hiking boots are needed/if a normal bicycle is usable or if you need a mountain bike or if biking is physically out of the question.

There’s one criticism that I’ll cover pre-epmtively: that descriptive tags don’t fit the bill because no one will ever fill them. I take this to imply that the persons suggesting this think that we are simply unable to ever overcome the problems with paths. The paths are exceptionally variegated in their physical properties. Therefore they would have to be classified according to these physical properties, completely irrespective of whether we conjure up further highway values or sub-classifications on the path key. Why not just add the physical characteristics with tags that describe them directly? This enterprise will of course take time, since the tags (descriptive, sub-classifications, or new highway values) will have to added or changed case-by-case. It’ll take years, probably over a decade until most paths have been corrected.

Oh, and BTW I think that we should add surface and smoothness tags to cycleways and footways that lack them.

2 Likes
17

There is one significant aspect of this suggestion that am struggling to visualise. How would this would work after a path is created, or for editing paths already in the database?

I believe you are saying that a mapper creating a new path would say “I want to map a hiking trail”, for example. The editor presents them with a suitable set of tags which the mapper populates and saves, along with the main highway=path tag, but the information that they used the hiking trail preset is thrown away.

What does the editing software do with that way from that point on? Does it try to analyse the tags and “reverse engineer” the original preset so that anyone modifying the way is presented with the same choices? Or does it revert to a generic path present with a relatively free choice of tags for subsequent edits?

OR, is your idea that the editor would save an extra tag, say “path=trail”, to retain the information that was the broad path type originally chosen?

(As a point of detail, it seems odd to me to have a category with “hiking” in the name and say it has to have paved or firm surfaces and be at least 2m wide. Most hiking trails I know would not qualify. But naming the categories could be worked on if it seems the overall approach would word).

3 Likes
18

Highway=scramble could solve some of the problems. And for the rest it would be important to add more secondary info.

Some of these problems also arrive because it is hard to classify roads based on access tags. But not every type of road should have its own top level highway tag. An argument could be made that highway busway is just a road for busses. A cycleway is a road for bicyclists. Etc.

Let’s say hypothetically that all highways would be highway=street/road/path and access tags. It would almost be impossible to extrapolate the current classifications from that.

Some intermediate tag that sits in between highway= and access could solve this problem.

For example, if you were to create a tag like mode= that has the designated mode of transport in it. If you make sure that it is a single value than it would be parsable in a way that access tags are not, but still allow for new expansions of current classifications.

So, a highway=pedestrian+motor_vehicle=destination could be highway=street+mode=pedestrian+motor_vehicle=destination.

2 Likes
19

Good point! For me, using a preset would mean to include a named bunch of tags to best fit the pah, then adjusting some values to match the actual situation, probably splitting up the way at points where e.g. surface or width change significantly.

1 Like
20

Great. How is this different to a new top-level tag? And, moreover, what exactly is the problem with introducing new tags? Is there a shortage of them?