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.

[westnordost]

Alright, went through the code one more time and also had a closer look at the tests.

Two more general things:

• a few tests in SeparateCyclewayParserKtTest should be failing
• Tests for CyclewayParser are missing. I.e. what tagging leads to SIDEWALK_OK

Also, as noted in that prior discussion, it is up to you whether you want to implement understanding sidewalk:<side>:bicycle=designated as an alias for cycleway:<side>=track + cycleway:<side>:segregated=no in this PR or not. If you do...

...then it would need to be treated in both the parser (i.e. return SIDEWALK_EXPLICIT in that case) and also in the creator (i.e. remove such tagging when another option is selected). + Tests.