Interpretation of access tags on highway = path

[dch0ph]

Expected behavior

To be discussed.

Actual behavior

Permissive (and yes) access is ignored when considering whether highway=path should be rendered as a cycleway or bridleway.

So highway=path, bicycle=designated is "promoted" to, and rendered as, a cycleway.
But highway=path, bicycle=yes or bicycle=permissive is rendered as a path/footway (which is counterintuitive).

A straightforward development of #4952 would be to consider bicycle=yes as equivalent to bicycle=designated.

Handling of permissive access is less obvious. I can see three models for combining access tags:

permissive=yes: "promote" if bicycle is yes, designated or permissive
Hence bicycle=permissive, horse=designated would be rendered as a cycleway, since it "passes" the cycleway test (which is considered before the bridleway test).

permissive as weaker: consider yes|designated before permissive.
In this model, bicycle=permissive, horse=designated would be rendered as a bridleway, because it is designated as a bridleway, with bicycle allowed. The "promotion" would be considered in two steps.

ignore permissive: only consider yes|designated. This would be the conservative option, but would be inconsistent with our current approach to access tagging where permissive is considered.

Arguably this is a discussion about tagging and belongs on the community discussion forums. But given the endless debates about highway=path on the forums, it may be easier to make progress here.

[dch0ph]

Just to add some figures. If I've used Overpass correctly, there are various potentially ambiguous access combinations on highway=path:

foot=yes, bicycle=permissive: 4.3k
foot=designated, bicycle=permissive: 1.3k

These would be rendered as cycleways under permissive=yes but not other options. Not obvious how to interpret, but intention likely to be footway on which cycling is tolerated.

horse=yes with bicycle=permissive: 251
horse=designated with bicycle=permissive: 38

These also would be rendered as cycleways under permissive=yes (due to cycle access being considered first) but not other options. Rare case, but tagging suggests these best rendered as bridleways.

The combination of foot=yes|designated with horse=permissive is messy since it will depend on the bicycle tag.

Overall permissive as weaker seems most likely to capture the intent of tagging. More paths will be "promoted" than would be the case than if permissive were ignored (as is currently the case), but this may be helpfully highlighting incorrect tagging.

[imagico]

We need an overall concept for the tag interpretation here that reliably ensures a consistent rendering.

There are some cornerstones that provide fundamental constraints on that:

1. plain highway=path should probably remain being shown as footway.
2. highway=path that effectively disallows foot and horse but allows bicycle should be shown as cycleway.
3. highway=path that effectively disallows foot and bicycle but allows horse should be shown as bridleway.
4. border cases at the symmetry line between cycleway and bridleway (i.e. when bicycle and horse have equal access) are to be shown as cycleway.

The main open question is then where to switch over from the default footway to cycleway/bridleway in access tag parameter space.

What annoys me most about the current logic is that

• highway=path is shown as footway while
• highway=path + foot=designated + bicycle=designated is shown as cycleway

That would call for extending the first constraint to:

• border cases at the symmetry line between footway and cycleway (or bridleway) (i.e. when foot and bicycle (or horse) have equal access) are shown as footway.

but i am open to different interpretations. And yes, creating a hierarchy between the different access values (designated > yes > permissive) is likely a good idea.

Another point to consider is if to take into account access for motorized vehicles. highway=path is currently de facto used for paths that are routinely (or even primarily) used with motorcycles and it might be advisable for us to take that into account. That is a separate issue of course - still something to keep in mind here.

[michaelblyons]

I think of designated > yes > permissive (> dismount). This would make bicycle=designated foot=yes look like a cycleway.

I am reasonably comfortable with imagico's rules thereafter, what I interpret as "if the highest preference in hierarchy is tied, pick foot > bicycle > horse."

Edit: As an aside, one would hope that day a specialty horse-focused renderer would only pay attention to horse tagging and happily tag a foot/bike/horse path as bridleway. But for OSM Carto, I think I've talked myself into the approach above.

[dch0ph]

What annoys me most about the current logic is that

• highway=path is shown as footway while
• highway=path + foot=designated + bicycle=designated is shown as cycleway

That would call for extending the first constraint to:

• border cases at the symmetry line between footway and cycleway (or bridleway) (i.e. when foot and bicycle (or horse) have equal access) are shown as footway.

I don't think we'll ever get agreement on how access tagging should work on highway=path - I don't have the courage to keep track of the multiple discussions on the community forums.

In practice, the JOSM presets for shared and segregated cycleways are highway=path, bicycle=designated and foot=designated with segregated=no|yes. So I don't think we have much option except to promote path with bicycle=designated to a cycleway independently of the value of foot, and I'd be reluctant to handle differently based on a secondary, non-access tag like segregated.

And yes, creating a hierarchy between the different access values (designated > yes > permissive) is likely a good idea.

OK. I was thinking that designated = yes > permissive would keep the logic clearer and reduce the number of permutations, but a 3-step process of promoting on designated if present, then yes, then permissive, has its own logic. So bicycle=designated, foot=yes would be a cycleway, but foot=designated, bicycle=yes would be a footway.

"if the highest preference in hierarchy is tied, pick foot > bicycle > horse."

This is probably where we disagree. The current logic is "bicycle > horse > foot" if tied. I would argue for keeping this if only on the basis that a lot of cycleways will be tagged in this way.

Another point to consider is if to take into account access for motorized vehicles. highway=path is currently de facto used for paths that are routinely (or even primarily) used with motorcycles and it might be advisable for us to take that into account. That is a separate issue of course - still something to keep in mind here.

Yes, a good interpretation scheme should be able to accommodate this. The nice thing about using functions is that we don't have the risk of combinatorial explosion if trying to implement in MSS.

[michaelblyons]

"if the highest preference in hierarchy is tied, pick foot > bicycle > horse."

This is probably where we disagree. The current logic is "bicycle > horse > foot" if tied. I would argue for keeping this if only on the basis that a lot of cycleways will be tagged in this way.

I think that's only true for designated values right now, no? If you have just highway=path with no access markings, it's marked like a footway, even though all of them are implied yes.

I'm not adamant about one top-of-hierarchy preference, but I recommend consistency however it is decided.

[imagico]

In practice, the JOSM presets for shared and segregated cycleways are highway=path, bicycle=designated and foot=designated with segregated=no|yes. So I don't think we have much option except to promote path with bicycle=designated to a cycleway independently of the value of foot, [...]

Why?

We render plain highway=path without any access tags as footway. Why should it not be possible for us to also render highway=path + bicycle=designated + foot=designated as footway? Both can be used by cyclists as well as pedestrians. Neither tagging in any way indicates this is a cycleway rather than a footway - or the other way round.

[dch0ph]

We render plain highway=path without any access tags as footway. Why should it not be possible for us to also render highway=path + bicycle=designated + foot=designated as footway? Both can be used by cyclists as well as pedestrians. Neither tagging in any way indicates this is a cycleway rather than a footway - or the other way round.

We certainly could. Ultimately the combination of bicycle=designated and foot=designated is ambiguous, and is why highway=path is a problem for data consumers - it would be much easier if the "primary mode" of the way were obvious from the primary key.

As I understand it, a principle of styling in OSMCarto is that it should reflect usage rather that how we think tagging should work. As a large number of cycleways will have been created as highway=path + bicycle=designated + foot=designated in JOSM (including by me, before I appreciated the problems of highway=path), I think it would be quite a bold move to switch to render these as footways.

I think that's only true for designated values right now, no? If you have just highway=path with no access markings, it's marked like a footway, even though all of them are implied yes.

Yes, that's correct. The basic problem of highway=path is that we are trying to second guess what mappers intend by a combination of access tags. We're agreed that plain highway=path should be a footway, but this a special default case which we assume is equivalent to foot=yes and no other access tags.

(I've edited the title since we're discussing interpretation of the access tags on highway=path more generally.)

[imagico]

Ultimately the combination of bicycle=designated and foot=designated is ambiguous

I don't think it is.

It is a borderline case in our three class system for display. But outside of this the tagging is completely clear - in some cases even represented by a standardized sign (like https://wiki.openstreetmap.org/wiki/File:Trakt_pieszorowerowy_wzd%C5%82u%C5%BC_Warty_w_Poznaniu_przy_ulicy_Ewangelickiej_-_kwiecie%C5%84_2018.jpg)

As I understand it, a principle of styling in OSMCarto is that it should reflect usage rather that how we think tagging should work.

That is an important question of course. As is this issue discussed the narrow question how to cast the tagging of highway=path into our three class display system. As far as our styling goals go this is of course a too narrow question. We would need to also consider if the three class is suitable for our goals. But that is of course beyond the scope of this issue and a fairly big can of worms as well. Back in the days when we introduced the current system (abolishing the separate black dashed line signature for highway=path) this was quite heavily contested. People got used to it meanwhile. But that does not mean this is necessarily ideal as it is. Mapping practice has changed meanwhile - as has this style. So a new, open assessment of the design situation of paths in this style, exploring different design option we have, would not be a bad idea.

Coming back to the quoted statement - we can only ever try to display the reality as far as it is documented in mapping and tagging. If tagging in some form reflects that a certain path is primarily used for cycling we should display it as a cycleway. But the tagging highway=path + bicycle=designated + foot=designated does not do so IMO.

The reason why i suggest that borderline cases in tagging between foot and either bicycle or horse should probably default to footway rendering is that - while the majority of routes of navigation on the planet too narrow for two track vehicles are allowed to be used with a bicycle - the globally most widely used mode of transport for those is going to be foot (and probably by a huge margin). And that probably applies in designated and non-designated cases alike.

[HolgerJeromin]

The reason why i suggest that borderline cases in tagging between foot and either bicycle or horse should probably default to footway rendering is that [...] the globally most widely used mode of transport for those is going to be foot (and probably by a huge margin). And that probably applies in designated and non-designated cases alike....

Or we could say that a bicycle is a more "advanced" transport mode (faster at least).

We show residential roads with the knowledge that a bike and foot is most probably also allowed (in a way it is motorcar=yes, bicycle=yes, foot=yes). No hint for bicycle=x or foot=x in the rendering.

The same could be perhaps done here.
If bike and foot is both equally allowed, we could render "the faster one" (so bicycle) like the motorcar in the residential road.

[imagico]

If bike and foot is both equally allowed, we could render "the faster one" (so bicycle) like the motorcar in the residential road.

Yes, that would be a possible approach. I don't think the analogy with residential roads is correct though. A residential road that does not allow motorcar but allows pedestrians is simply not a residential road but a pedestrian road.

In any case - that would mean to render highway=path without any access tags and highway=path + foot=yes + bicycle=yes as cycleway as well, wouldn't it?

[HolgerJeromin]

I don't think the analogy with residential roads is correct though. A residential road that does not allow motorcar but allows pedestrians is simply not a residential road but a pedestrian road.

Yes, but I dont get what you want to say with this example.
My analogy was a "way" with mixed access (car, bike, foot).

In any case - that would mean to render highway=path without any access tags
and highway=path + foot=yes + bicycle=yes as cycleway as well, wouldn't it?

Yes.

[imagico]

That is an intriguing idea. Essentially this would mean completely re-framing the meaning of our cycleway signature from a path predominantly for bicycles to a path were cycling is allowed (even in cases where it is extremely rare practically). What is speaking for that idea is that even most explicitly tagged highway=cycleway are not usually disallowing pedestrians and are practically frequently used more by pedestrians than by cyclists. And - as @dch0ph pointed out - there is currently not really an established tagging to indicate a path is predominantly used or designed for cycling or walking unless that is mirrored exactly in the permissions.

The problem is that this would not work well with our current visual design paradigm - which features very strong contrasts between footway, cycleway and bridleway. If semantically this classification is turned into a classification of permissions of use it would IMO be necessary to substantially tone down the visual differences - which essentially means getting rid of the blue for cycleways.

If we'd introduce that idea without changing the visual design we'd end up with many parts of the planet suddenly being covered by networks of blue lines - being both prone to confusion with waterways and being confusing due to their stark contrast with the footway red despite a really minor difference in both tagging and practical meaning.

The main problem i see with this idea (apart from the difficulty of eliminating the blue cycleways) is that it would not provide a distinction between a path that allows both pedestrians and cycling and a path that allows only cycling. Both would be shown equally as cycleway. Bottom line: It would make the map more useful for cycling but less useful for walking.

[HolgerJeromin]

Bottom line: It would make the map more useful for cycling but less useful for walking.

You are right.
Only the (few?) foot=designated, bicycle=yes (or foot=yes alone) would be "red" (as in foot only).

[michaelblyons]

If I may, I'd like to summarize some pros and cons of different approaches suggested or implied above. If you have additions or disputes, I will try to edit them in as I have opportunity.

bicycle > horse > foot

Pros

• Possible implication of smoothness: Probably no one is going to have bicycle=designated on a path where no sane person could conceivably ride a bicycle.
• Possible implication of speed: May indicate the fastest fellow travelers you will encounter on the path.
• Consistent application of a simple rule
• Tied top-level tags are status-quo for designated

Cons

• Probably lots more "blue" on the map
• May encourage tagging-for-the-renderer

foot > bicycle > horse

Pros

• No special equipment required for the primary rendered usage type
• Consistent application of a simple rule
• Tied top-level tags are status-quo for no access tagging or yes

Cons

• Places where people have tagged for the renderer in the past to get bicycle lines on the map will be thwarted. (Maybe that's actually a Pro?)
• Will encourage new tagging-for-the-renderer yet again

Try to preserve some existing rendering

Pros

• Fewer people inclined to retag for the renderer (again)
• Less surprise when the change is released

Cons

• Not a simple rule at all. Either you maintain a big mental truth table of inputs -> outputs, or a big flow chart of rules

[dch0ph]

• Possible implication of smoothness: Probably no one is going to have bicycle=designated on a path where no sane person could conceivably ride a bicycle.

Yes, I think this is behind the existing logic of bicycle > horse > foot. The combination of highway=path + bicycle=designated implies that you have a way suitable for road bikes, while highway=path provides no guarantees at all.

• Probably lots more "blue" on the map

I'm not sure this will be the case. It will be useful to look. We would only get more blue compared with the status quo for combinations with say bicycle=yes + foot=yes (but not bicycle=yes + foot=designated which remains a footway due to designated > yes > permissive).

From a previous quick look, there were a small number of cases, several of which highlighted incorrect tagging (e.g. bicycle=yes on footpaths).

it would not provide a distinction between a path that allows both pedestrians and cycling and a path that allows only cycling. Both would be shown equally as cycleway. Bottom line: It would make the map more useful for cycling but less useful for walking.

I'm not convinced that a map that "surfaces" more cycleways is less useful for walking. It is useful to be able to avoid routes where you may be mown down by a cyclist, so it's useful to highlight where cycling is explicitly allowed! [I don't like the idea that of showing plain highway=path as a cycleway.]

[imagico]

Please keep in mind we are producing a map for a global audience. And that the vast majority of highway=path does not have any access tags. Hence, if we change the way re interpret plain highway=path, that has a much larger effect than any other change we might consider.

What we ultimately need here is an overall concepts consisting of three components:

1. how to interpret the different access values relative to each other - that was what this issue was originally about.
2. how to delineate the different modes of transport in cases where multiple modes are allowed.
3. the classifications derived from this that are ultimately used in rendering and how they are displayed.

I mentioned some constraints for these i find sensible - but nothing is set in stone here, including the visual classifications. If there is a suggestion that visually distinguishes between single mode paths (i.e. pure footway/cycleway/bridleway) and multi-mode paths (like foot+bicycle) that is intuitive to understand i would be open to that.

The three components mentioned are of course connected. Looking at them individually first - like @michaelblyons did above for the second - is a useful approach. But we ultimately need a combined concept.

[dch0ph]

There are potentially multiple issues / outcomes. We might be able to reach consensus on the first issue, which was intended to be a "simple" (ha ha) extension in the spirit of #4952 to consider more access tags (values of yes and permissive on access modes of path).

To put some more numbers on things:
highway=path + bicycle=designated (status quo of "upgrade" to cycleway): 4.4% (650k) of highway=path

highway=path + bicycle=yes (maximum number of paths turning blue if upgrading using "designated > yes"): 3.1% (453k)
A fraction of these will have foot=designated ("cycles tolerated"), but this would be 40% more blue.

From a non-rigorous survey of the local area these seems to be a whole mix of things:

Likely cycleways where bicycle=yes + foot=yes has been used rather than designated.
Likely mistakes (cycle access seems unlikely)
Formal / informal MTB routes where bicycle=yes has been added to indicate e.g. a steep MTB route. A lot of these have surface tagging, so they would/could be visually distinguished from conventional cycleways with sealed surfaces.

Personally I would be in favour of extending interpreted tags to "designated > yes > permissive" on the basis that it would be more logical than ignoring anything but bicycle=designated, and that it would "surface" quite a lot of dubious tagging, which currently renders as a normal path/footway, but which a router would assume was suitable for cycling. This interpretation of additional tags could proceed independently of a more sophisticated rendering option.