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.