Add "None, but a sign allows cycling on sidewalk" as an option for cycleway overlay/quest

[wielandb]

This PR adds the possibility to tag that cycling is allowed on the sidewalk by a sign in the cycleway quest and overlay, and that a sign allows cycling on a footway in the separate cycleway overlay.

• Cycleway quest and overlay
  • The StreetSideSelect Form now offers an option to tag "None, but a sign allows cycling on sidewalk" which will tag sidewalk:[side]:bicycle=yes
  • The colour in the overlay for SIDEWALK_EXPLICIT has been changed to be a continious cyan line, so that SIDEWALK_OK can have the dashed cyan line
• Seperate Cycleway Form
  • It's now possible to tag a seperate way as explicitly allowed for bicycles by a sign

[westnordost]

Linking to #4913

[wielandb]

Linking #5596 (comment), which talks about a change on how highway=path + foot=no should be parsed.

[westnordost]

Hey Wieland, are you still working on the next iteration of your streetcompleteness thing? If yes, could you make it a heatmap of quest densities? That would be so cool! 😁

[wielandb]

I'm not sure I'm "ready", but would apprechiate some feedback on the current state.

The features work as intended as far as I can see. I'm new to doing unit tests, I implemented some, but I'm unsure if they are enough/correct.

I am also still a bit unsure about tagging, especially in which cases bicycle= should be removed. Should choosing PATH remove bicycle=? Should choosing one of the options that indicate a cycleway remove bicycle:signed=, or maybe even add it?

[wielandb]

Hey Wieland, are you still working on the next iteration of your streetcompleteness thing? If yes, could you make it a heatmap of quest densities? That would be so cool! 😁

That would certainly be quite a challenge, but I'll see what I can do!

[westnordost]

I just had a quick look first, this is not a complete review.

I am also still a bit unsure about tagging, especially in which cases bicycle= should be removed. Should choosing PATH remove bicycle=? Should choosing one of the options that indicate a cycleway remove bicycle:signed=, or maybe even add it?

I think such things should be changed if keeping the current value would contradict the newly selected option. If it was e.g. bicycle:signed=no before but user selects "exclusive cycleway" now, then bicycle:signed=no should be removed.

[westnordost]

Alright, first full review:

---

Wouldn't it make sense, for completeness sake to have in the end three options?

• Footway, no signs about bicycles
• Footway, but a sign allows bicycles
• A sign prohibits bicycles

This would also allow all options that can be parsed to be displayed in the overlay.

Currently, e.g. highway=footway+ bicycle=no + bicycle:signed=yes results in it being displayed as "Not designated for cyclists (cycling may still be allowed)".

The NOT_ALLOWED option would necessarily continue to not imply a footway, to cover taggings like highway=path + bicycle=no + bicycle:signed=yes

---

One thing we can also consider then is to remove the PATH option to reduce complexity and number of choices - i.e. merge PATH and NON_DESIGNATED option. One one hand, this simplifies the selection options mentioned above, because no need to imply a footway, on the other hand, ways signed as footways () have implicit restrictions on bicycles in e.g. Germany as far as I know, so whether it is foot=designated or just foot=yes probably should make a difference for cyclists when evaluating the data. In other words, to be able to make this distinction in SC might be useful for data consumers. (Although, highway=footway / foot=designated doesn't necessarily mean that there is a sign. E.g. the typical footways within a housing estate will likely be tagged that way, but there will be no signs.)

[wielandb]

Alright, first full review:

Wouldn't it make sense, for completeness sake to have in the end three options?

• Footway, no signs about bicycles
• Footway, but a sign allows bicycles
• A sign prohibits bicycles

This would also allow all options that can be parsed to be displayed in the overlay.

Currently, e.g. highway=footway+ bicycle=no + bicycle:signed=yes results in it being displayed as "Not designated for cyclists (cycling may still be allowed)".

The NOT_ALLOWED option would necessarily continue to not imply a footway, to cover taggings like highway=path + bicycle=no + bicycle:signed=yes

For now, I have implemented and enabled all three options in the overlay.

[mnalis]

Sure, the blue circular sign means that it is designated for that traffic participant, i.e. foot=designated + foot:signed=yes is correct, but from *=designated alone it cannot be derived that a way is prohibited for all other traffic participants. However, that blue circular sign explicitly disallows other modes of transportation.

traffic other than pedestrians may not use the sidewalk.
and I suppose it will be similar in other countries, because the blue circular sign always has the same meaning.

(doing some research)

Well, I wouldn't be so sure... In nearby Croatia, for example, such sign indeed means it is forbidden for any vehicle ("vozilo/a").

However ZOSPNC 2.1.28. defines "vehicle" somewhat differently, i.e. makes exception for "children's means of transport, personal or motorized means of transport for persons with disabilities or the elderly, if they do not move at a speed higher than the speed of human walking"

So, kid on kids bicycle, as well as wheelchair user (provided they move slow enough) are not considered vehicles by law and are allowed on all such footways. Contrast that to OSM, where wheelchair=yes (regardless of its speed), as well as bicycle=yes (regardless of bicycle:type=child) are still considered vehicle=yes.

How the low defines in some further away country (e.g. in Asia or Africa), I wouldn't dream to claim to comprehend.

So, while tagging it as foot=designated + foot:signed=yes are correct in Croatia (and I'd guess elsewhere), bicycle=no is actually incorrect for some bicycle users (slow small kids) here, so it is more like bicycle=yes + bicycle:conditional=none @ (speed>walk); none @ (bicycle:type != child) + wheelchair=no + wheelchair:conditional = yes @ (speed<=walk) or some similar country-dependent horror.

(i.e. the issue seems somewhat akin to maxspeed issue with complex solution like https://westnordost.github.io/osm-legal-default-speeds)

---

TL;DR: I would rather prefer that SC would add only fully factually correct and verifiable data, but if it had to simplify with such partly-incorrect information like bicycle=no on , I would really like add some tag to indicate that source.

You're absolutely right about bicycle:signed probably being wrong tag, though! How about source:bicycle=implied_by_pedestrian_sign (or something similar)?
That one is freeform text already, and source:bicycle=* is even documented on the wiki, has dozen thousands of uses, and we already do freeform things like surface:note=* in SC.

---

[wielandb]

So, while tagging it as foot=designated + foot:signed=yes are correct in Croatia (and I'd guess elsewhere), bicycle=no is actually incorrect for some bicycle users (slow small kids) here,

Just for completeness sake, it's the same way in germany. But since this is universal for everywhere in germany, we don't tag it onto every sidewalk. (It's not recorded in https://www.openstreetmap.org/relation/8131479 (yet), but if at all, it should be recorded there.)

[westnordost]

@wielandb Right, right, I am absolutely for not opening cans of worms...

I thought your comment regarding horse:signed=yes, motor_vehicle:signed=yes etc. referred to discussions in the community. Yeah, for implementation of StreetComplete bicycle overlay, it is not an issue, but for people that would check every box in JOSM access presets (and/or people complaining about those people), it might. In the end, it would be a problem for StreetComplete, because what goes around comes around.

Maybe your initial suggestion is the best one, after all. And adapt the wording accondingly:

Wording	Tags
Generic path or trail (Not designated for anyone in particular)	highway=path / foot=yes + bicycle=yes
Not designated for cyclists (cycling may still be allowed) Footway, no explicit sign about cycling (whether it is allowed depends on legislation)	highway=footway / foot=designated
A sign explicitly prohibits cycling	bicycle=no + bicycle:signed=yes
Footway, but a sign allows cycling	bicycle=yes + bicycle:signed=yes
Designated shared-use path	foot=designated + bicycle=designated
...	...

(I marked the modifictions with insert and delete)

[westnordost]

Great, let's put this into the release I am going to do today!

[westnordost]

strings uploaded to POEditor now, will release v58 this evening.

[westnordost]

I see you've been editing German translation the same time as I did. I am done now, feel free to review and see if you find better translations.

🎉

[frankie2784]

Can I clarify the difference between:

"Footway, but a sign allows cycling " and "Designated shared-use path"?

In Australia there is no distinction, legal or otherwise.

[westnordost]

• first is highway=footway / foot=designated + bicycle=yes + bicycle:signed=yes
• second is foot=designated + bicycle=designated.

I.e. the first would be designated as a footway, but there is some additional sign that allows also bicycles (the latter obviously just being "guests").

The second would be designated as a foot+bike path. The picture you see on the second last page in this document would be a shared-use path.

Depending on country and legislation, the difference between the two can indeed be marginal or not really exist.

[frankie2784]

That's fine. I just think having both options might end up being confusing for your audience in countries where there is no meaningful distinction between the two. Perhaps having the "footway, cycling permitted" option available only in relevant countries similar to, e.g. advisory bike lane, would be a good idea? That way, users can request to opt in for their jurisdiction if "designated shared use path" is deemed not sufficient.

…

On Sun, 2 June 2024, 00:22 Tobias Zwick, ***@***.***> wrote: first is highway=footway / foot=designated, second is foot=designated + bicycle=designated. I.e. the first would be designated as a footway, but there is some additional sign that *allows* also bicycles (the latter obviously just being "guests"). The second would be designated as a foot+bike path. The picture you see on the second last page in this document <https://hdp-au-prod-app-tam-yourvoice-files.s3.ap-southeast-2.amazonaws.com/7416/1887/6734/DRAFT_Active_Transport_Strategy_document.pdf> would be a shared-use path. Depending on country and legislation, the difference between the two can indeed be marginal. — Reply to this email directly, view it on GitHub <#5575 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETVUIWAJOH2FEIKBFF7XDDZFHKKNAVCNFSM6AAAAABISTP4D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTGQ3DMMJVHA> . You are receiving this because you commented.Message ID: ***@***.***>

[westnordost]

It would be more problematic (and complex) to not display this option in certain countries, because unlike bike lanes, these are not subtags that could then just be ignored. I.e. a situation where in a country were (officially) one of these options does not exist would need to be handled gracefully, without potentially removing valid data.

So, for one thing, we would need to be extra careful which countries would be added to a presumed bicycleOnFootwayIsOkSignDoesntExist.yml list. But we also need some rules, agreed on by the community, how to handle cases where despite apparently an official sign missing, such tagging is still found in the wild in said country. And these rules should of course be globally valid because these tags should not mean different things in different countries.

[frankie2784]

I'm still not entirely clear on what the legal or practical difference is between the two categories. Is it that pedestrians have right of way in the first case but not in the second? Do bikes as "guests" have to ride slower or differently than if "designated"? And how will this be communicated to users of the app (through an icon or other means) as to how to identify the right category if this distinction doesn't exist in their location? I ask because there is a risk that people may get confused and start changing sections from bicycle "designated" to "yes", or vice versa, when the two have different connotations in some routing apps (for example, bicycle "yes" on a footpath in Victoria where I live is typically used to identify where there is NO signage, but cyclists informally use it anyway - so not legally, but do in practice).

…

On Sun, 2 June 2024, 02:05 Tobias Zwick, ***@***.***> wrote: It would be more problematic (and complex) to not display this option in certain countries, because unlike bike lanes, these are not subtags that could then just be ignored. I.e. a situation where in a country were (officially) one of these options does not exist would need to be handled gracefully, without potentially removing valid data. So, for one thing, we would need to be extra careful which countries would be added to a presumed bicycleOnFootwayIsOkSignDoesntExist.yml list. But we also need some rules, agreed on by the community, how to handle cases where despite apparently an official sign missing, such tagging is still found in the wild in said country. And these rules should of course be globally valid because these tags should not mean different things in different countries. — Reply to this email directly, view it on GitHub <#5575 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETVUISR33WUOKWKL4INHBLZFHWMRAVCNFSM6AAAAABISTP4D2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTGQ4TQNJYG4> . You are receiving this because you commented.Message ID: ***@***.***>

[westnordost]

What legal difference it makes depends on the legislation. In Germany, it does make a difference.

Your example sounds like an instance of, well..., creative tagging usage. If it is not legal, then bicycle=yes is wrong.

But anyway, there is also the option "Footway, no explicit sign about cycling", and in fact, this is the option you are going to see in StreetComplete for highway=footway + bicycle=yes because the "Footway, but a sign allows cycling" option is only selected if bicycle:signed=yes. The same for if bicycle=no. I feel proud of our solution right now, because rit looks like we managed to dodge the clash of different mindsets in different local communities on what =yes and =designated means by specifically requiring a sign for the "signed" options.

As for icons, well, I just released it, so you can see for yourself. For the first option, a pedestrian is shown and on the lower corner you see "🚲 OK" in what looks like a sign or annotation. For the second, a pedestrian and a bicycle is shown together.

[mnalis]

That's fine. I just think having both options might end up being confusing
for your audience in countries where there is no meaningful distinction
between the two.

Yes, I was quite confused by that German distinction too...
Perhaps we could add some small clarification in that recently-available "info button" ℹ️ ?

strings uploaded to POEditor now, will release v58 this evening.

I understand (and support!) the need for "release early, release often", but with my translator hat on, I'd really appreciate if translators were given more than few hours notice to do their work, especially on weekends (when people are sometimes even known to be offline!)... say, at least 2-3 days between publishing strings and doing a release?

[frankie2784]

Is it only a thing in Deutschland?

[mnalis]

Is it only a thing in Deutschland?

Probably not only there (though I have not done research where else it might be the case); but it is definitely not a thing in Croatia (which is why it confused me).

[FloEdelmann]

Since this was merged, a few tests in SeparateCyclewayCreatorKtTest.kt are failing (see https://github.com/streetcomplete/StreetComplete/actions/runs/9330540814/job/25684214512). @wielandb, could you take a look at that please?

[westnordost]

Oh, shit, I should have checked that... I hope it is just a mistake in the tests!

[wielandb]

Oh no! At least on my machine, all tests passed when making the final commit. Will check this ASAP.

[westnordost]

I skimmed through the failing tests. Fortunately it just looks like some tests were not adapted to the new behavior, so need for a hotfix or anything.

Many tests are named like they test whether a certain tag is added/removed on certain combinations.
For this, a check like this could be used instead of assertEqual to make the test more focussed on what is actually tested. E.g.:

    @Test fun `apply allowed on footway adds the bicycle signed tag`() {
        assertTrue(
            ALLOWED_ON_FOOTWAY.appliedTo(mapOf(
                "highway" to "footway",
            )).contains( // or containsAll if it is several that should be checked.
                StringMapEntryAdd("bicycle:signed", "yes")
            )
        )
    }

(compare with current version)

[westnordost]

Anyway, frankie2784, I only explained why it is more effort and complex to implement that. Something like this is certainly a valid and meaningful feature request but to make this a reality, first research is needed in which countries a distinction between those two options is made, either in legislation or by the local community. A good place to start might be the forum.

[wielandb]

A good place to start might be the forum.

I created this post:
https://community.openstreetmap.org/t/does-your-country-have-the-legal-concept-of-designated-for-pedestrians-but-cyclists-allowed/114096

[wielandb]

Should apply allowed does not re-tag bicycle=permissive etc still succeed?
In other words, if we apply "A sign allows cycling", should a bicycle=permissive be turned into a bicycle=yes + bicycle:signed=yes or should it stay a bicycle=permissive? I guess that it should not become bicycle=permissive + bicycle:signed=yes because that would mean the permissiveness is signed.

[westnordost]

Yeah, I would say you are right. If there is a sign, permissive sounds wrong. After all, the surveyor can't and should not need know whether the signed access restriction was put there by the owner or by the municipality. The former could at any time revoke it, but if you think about it, the municipality can at any time revoke it, too.

On the other hand, if there is something like a hand-written sign like "hey bikers, feel free to use this shortcut through my property here!" or whatever, maybe indeed permissive would be a better fit but I doubt that this kind of thing is the usual situation one expects to encounter for "footway, but a sign allows bicycles"

[wielandb]

Since this was merged, a few tests in SeparateCyclewayCreatorKtTest.kt are failing (see https://github.com/streetcomplete/StreetComplete/actions/runs/9330540814/job/25684214512). @wielandb, could you take a look at that please?

Created #5672 to fix this