when changing bicycle=yes to designated considerer also foot

[Langlaeufer]

in this changeset https://osmcha.org/changesets/153843293
a path with bicycle=yes but without foot tag was changed to

changed: bicycle = yes -> designated
added: segregated = no

This changes the meaning of the multipurpose-path to an exclusive cycleway (path with bicycle=designated have the same meaning als highway=cycleway (see proposal of highway=path)

please add also foot=designated, if someone answers that a way is a shared foot- and cycleway.

[matkoniecz]

edit link without login wall: https://www.openstreetmap.org/changeset/153843293

[matkoniecz]

it seems to be about https://www.openstreetmap.org/way/23983352/history

[westnordost]

This path is tagged as highway=path, not as highway=cycleway. highway=path implies foot=yes unless explicitly tagged otherwise.

[Langlaeufer]

Even then, ... if someone answers bike and footpath, then you shouldn't just set bicycle=designated

[westnordost]

Hm, that's true. I'll look into the code as to why this is

[Langlaeufer]

"unless explicitly tagged otherwise."

This is not the way how foot and cycle "paths" are tagged in Germany. Otherwise we have to tag horse=no or access=no on each signed combined and shared foot and cycleway.

We only tag foot=designated and bicycle=designated and hope, that the data-user understand it as an German Rad- und Fußweg and that there were no other traffic allowed.

[westnordost]

It is reasonable to hope for that. I doubt though that software can be trusted to interpret a bicycle=designated on a highway=path without foot explicitly tagged as that pedestrians are not allowed.

[westnordost]

Regarding why the app does not retag foot to foot=designated, this is due to

StreetComplete/app/src/main/java/de/westnordost/streetcomplete/osm/cycleway_separate/SeparateCyclewayCreator.kt

Lines 57 to 60 in 406bc57

	// do not retag highway=cycleway + foot=yes
	if ((isCycleway || tags.containsKey("foot")) && tags["foot"] !in yesButNotDesignated) {
	tags["foot"] = "designated"
	}

I.e. foot=designated is only tagged if foot was set before or the path is tagged as highway=cycleway and foot is not already a truthy value (like permissive, yes, customers, destination, ...).

So, it is definitely not a bug but deliberate. I don't remember why this is done, exactly.

The latter part about treating truthy values was added in this commit: af1ad7e

Maybe the discussion in the original pull request can provide information about why this was done. I can't find it right now.

[westnordost]

Okay, I think I remember.

TL;DR: The tagging highway=path + bicycle=designated is in-use for shared-use paths and as long there is no global community consensus that this should be deprecated due to ambiguity, it would be problematic to change the current behavior.

---

The issue is that the topic of bicycle and path tagging and especially shared-use path tagging is a contentious one. Everyone seems to have his own preferences here, nurtured by a long and continuing policy of tag-what-you-like and (slightly) conflicting documentation in different languages of the wiki.

This manifests for example in

• JOSM the preset for a shared-use path uses the German-community-inspired **highway=path** + foot=designated + bicycle=designated + segregated=no, while in
• iD the preset for the same thing is **highway=cycleway** + foot=designated + bicycle=designated + segregated=no.

The resulting blur in tagging practices requires data consumers to be somewhat lenient in parsing shared-use paths, i.e. take the smallest common denominator. Now, indeed, shared-use paths that are tagged with highway=path + bicycle=designated (+sometimes foot=yes or anything else truthy) do exist, and not in negligible numbers. See http://overpass-turbo.eu/s/1Oc8

StreetComplete needs to take on a role of a lenient data consumer here and understand these taggings also still as shared-use paths, because this tagging is not deprecated and hence should not be shown as invalid in the app.

When then tagging the users' selection, StreetComplete tries not to be opinionated and preserve the way it was tagged before as much as possible to avoid intruding into this contentious topic.
The reason is simple: As long as there is no global community consensus that a certain tagging for foot- and cycleways should be deprecated, I don't want to get the blame for StreetComplete peeing in someones figurative front yard (i.e. StreetComplete changing all the tagging from one way to tag it to another in a zone where consistently, a slightly different way of tagging it was used).

[Langlaeufer]

yes, this is the problem of using highway=path

"preserve the way it was tagged before as much as possible to avoid intruding into this contentious topic."
is a good approach

But with changing bicycle=yes to bicycle=designated you change the meaning of the way. If it is a shared foot and bike path, than both foot and bicycle has to be set to designated or if you don't want to touch it, nothing of them and you only have to set segregated tag to yes or no

[westnordost]

So, how about this:

On selection of "shared foot- and cycle path", tag foot=designated always, except if either:

• foot is already tagged and truthy ("yes", "permissive", "private", "destination", "customers", "permit")
• it is a highway=footway and no foot is already tagged

[Langlaeufer]

same for bicycle=designated - foot and bicycle should be handled the same way!

but i'm not sure if you should tag foot or bicycle =designated if the other value is not equal to designated.
I would normally expect both to be the same value except both values were explicite different before the SC edit.

highway=footway implies foot=designated if nothing different is set explicite
highway=cycleway implies bicycle=designated if nothing different is set explicite

[westnordost]

That's not possible.

highway=path + foot=yes + bicycle=yes is interpreted as just a path because there is no designation for anyone, not as a shared-use path.

[Langlaeufer]

Then you have both to change to designated

[westnordost]

Well, see #5742 (comment)

[Langlaeufer]

combinations and there interpretation in Germany

• bicycle=desigated + foot=designated (shared or segregated cycle/foot path)
• foot=designated + bicycle=yes. (Footway with bicycle allowed) (but also used for non-signed shared or segregated cycle/foot path - Lübecker Methode)
• bicycle=desigated + foot=yes. (Cycleway with pedestrians allowed) should not exist in Germany Exception: here (Mapillary) does not need to be supported by SC in Germany (but it also should not be created by adding a foot or bicycle tag). Existing combinations should not be destroyed.
• bicycle=yes + foot=yes. (multi-purpose path)

[Langlaeufer]

highway=path + foot=yes + bicycle=yes is interpreted as just a path because there is no designation for anyone, not as a shared-use path.

you are willing to create strange combinations of bicycle=* and foot=* but a segregated=* at a foot=yes + bicycle=yes is impossible to tag?
Sorry, I don't understand the priorities here between wrong and even more wrong, and what needs to be preserved and what needs to be corrected.

[westnordost]

Uh, what...

Maybe there is a misunderstanding.

bicycle=desigated + foot=yes. (Cycleway with pedestrians allowed) should not exist in Germany Exception: here (Mapillary) does not need to be supported by SC in Germany (but it also should not be created by adding a foot or bicycle tag). Existing combinations should not be destroyed.

Yet, it does. That is what #5742 (comment) was all about. See the overpass turbo link.

same for bicycle=designated - foot and bicycle should be handled the same way!

It appears I misunderstood what you meant with this, then. I understood that you meant that when the user selects "shared-use path" (gemeinsamer Fuß und Radweg) that bicycle=designated should NOT be tagged if there is already a bicycle=yes tagged. Because, that would be what would need to be implemented if the rules outlined in #5742 (comment) were to be implemented in the same way for bicycle, too.

you are willing to create strange combinations of bicycle=* and foot=* but a segregated=* at a foot=yes + bicycle=yes is impossible to tag?

I am willing to preserve this strange combination in order to not end up in the crossfire of bicycle-tagging-fanatics with strong opinions that in their very specific part of the globe, like Lübeck (or Germany, for that matter), things must be tagged in a very specific way.

[mnalis]

same for bicycle=designated - foot and bicycle should be handled the same way!

@westnordost Perhaps I missed the point, but I think this @Langlaeufer comment agreed with your #5742 (comment) (the 👍 seems to imply so), but was meant to also extend your suggestion of:

On selection of "shared foot- and cycle path", tag foot=designated always, except if either:

• foot is already tagged and truthy ("yes", "permissive", "private", "destination", "customers", "permit")
• it is a highway=footway and no foot is already tagged

with additional:

Also, on selection of "shared foot- and cycle path", tag bicycle=designated always, except if either:

• bicycle is already tagged and truthy ("yes", "permissive", "private", "destination", "customers", "permit")
• it is a highway=cycleway and no bicycle is already tagged

---

I think that should preserve any "strange" already-preexisting bicycle (as well as foot) value (thus preventing "SC ending up in the crossfire of bicycle-tagging-fanatics with strong opinions that in their very specific part of the globe"), but would still add bicycle=designated (as well as foot=designated) in "normal" cases (i.e. when bicycle/foot tags are missing).

[westnordost]

Yeah, but #5742 (comment)

[mnalis]

Yeah, but #5742 (comment)

Is that correct comment linked? I do not see how it would apply, as "highway=path + foot=yes + bicycle=yes" situation that you mentioned there should not trigger overriding with foot=designated / bicycle=designated tags, due to "foot(/bicycle) is already tagged and truthy" suggested rules.

Or am I missing something here?

[westnordost]

You are missing something.

Imagine that a path has been mapped as highway=path + foot=yes + bicycle=yes.
In the app, it will be displayed as "Generic path or trail (Not designated for anyone in particular)"
When the user selects instead "Designated shared-use path", the app would then not re-tag anything, as both foot and bicycle are already truthy. Hence, it would be impossible for the user to change the path from a generic path to a designated shared-use path.

Though, after seeing @Langlaeufer's example from Mapillary I am starting to think that when the user selects anything that amounts to that *=designated is tagged, it should also overwrite any other truthy value (such as customers).

[mnalis]

TL;DR: overwrite only generic yes values, not all truthy-values.

---

I am starting to think that when the user selects anything that amounts to that *=designated is tagged, it should also overwrite any other truthy value (such as customers).

I'm not so sure about this one. I'd then prefer if only generic yes values were overwritten, otherwise that "SC ending up in the crossfire" fear might very well be realized.

Underlying issue, is of course, problem of overloaded syntax of access tags.

e.g. if there exist "designated shared-use cycleway+footway, allowed only for customers", there is no real way to tag that fully in OSM. One would either have to go with foot=designated + bicycle=designated (losing "customers"-only restriction!), or go with foot=customers + bicycle=customers (losing the "designated" characteristics). Both are lossy.

But I would say that "customers" part is significantly more important than "designated" part.

(e.g. imagine a customer-only cycleway/footway shortcut going through camp site, or national park, or whatever -- as an e.g. cyclist, it is way more important for you that you cannot use it at all since you're not a customer, rather then whether it is "specifically designated cycleway" or only "footway also usable by bicycle")

[westnordost]

Sounds reasonable, but note that it does not solve the issue I described when foot and bicycle is both =customers for example. El 18 de julio de 2024 10:57:01 CEST, Matija Nalis ***@***.***> escribió:

…

**TL;DR:** overwrite only generic `yes` values, not _all_ truthy-values. ---- > I am starting to think that when the user selects anything that amounts to that *=designated is tagged, it should also overwrite any other truthy value (such as customers). I'm not so sure about this one. I'd then prefer if **only** generic `yes` values were overwritten, otherwise that _"SC ending up in the crossfire of bicycle-tagging-fanatics with strong opinions that in their very specific part of the globe"_ fear might very well be realized. Underlying issue, is of course, problem of overloaded syntax of access tags. e.g. if there exist _"designated shared-use cycleway+footway, allowed only for customers"_, there is no real way to tag that fully in OSM. One would either have to go with `foot=designated` + `bicycle=designated` (losing "customers"-only restriction!), or go with `foot=customers` + `bicycle=customers` (losing the "designated" characteristics). Both are lossy. But I would say that ***"customers"*** part is **significantly more important** than *"designated"* part. (e.g. imagine a customer-only cycleway/footway shortcut going through camp site, or national park, or whatever -- as an e.g. cyclist, it is **way more important** for you that you cannot use it at all since you're not a customer, rather then whether it is "specifically designated cycleway" or only "footway also usable by bicycle") -- Reply to this email directly or view it on GitHub: #5742 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[westnordost]

I decided to indeed treat foot and bicycle the same here and tag foot=designated unless it is already implicit by highway=footway when the user selects "designated shared-use path" in the bike path overlay.

The previous behavior was that if foot was already a "truthy" value (yes, permissive, ...), it would not change it. Now, the consensus on this thread is that if it is yes it should be re-tagged to designated. Regarding other truthy values, mnalis has been arguing for not overwriting it while for Langläufer, consistency with bicycle tagging was most important. I decided to go for consistency with bicycle tagging, because

• it is consistent with what is tagged for bicycle when the user selects "designated shared-use path", "bike-only path", "separated bike and foot path": always bicycle=designated is tagged, also overwriting any previous truthy value

• the situation that a footpath is both signed as "private" or "customers only" and at the same time bears "shared-use path"-signage is very unlikely. So the inability to tag both at the same time in OSM is less of an issue that it appears here, IMO. (In any case, this is really rather an OSM issue that we could only try to mitigate, any mitigation will add complexity and may not produce the results one may wish for in edge cases, see this ticket)