Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render sidewalk= similar to cycleway=track #409

Closed
brainwad opened this issue Jul 15, 2020 · 4 comments · Fixed by #464
Closed

Render sidewalk= similar to cycleway=track #409

brainwad opened this issue Jul 15, 2020 · 4 comments · Fixed by #464

Comments

@brainwad
Copy link
Contributor

brainwad commented Jul 15, 2020

In addition to cycleway=, which are used for tagging cycle facilities without creating separate ways, there is a similar tag sidewalk=. In particular it is the recommended way to tag a sidewalk attached to a road where bicycles are allowed but not designated according to the German wiki. Unlike cycleway=, where the value specifies the type and side is specified as a suffix to the key (e.g. cycleway:right=track), sidewalk= specifies the side (e.g. sidewalk=left).

This could be rendered using borders that match the rendering of highway=footway today: a green line if sidewalk:(<side>:)bicycle=yes, otherwise brown. These can also be oneway, either for vehicles in general (using sidewalk:(<side>:)oneway= or for bicycles specifically using sidewalk:(<side>:)oneway:bicycle=, so ideally they would get direction arrows if anything is specified.

There are also cases where one side of a road has both a marked cycle lane (on the road) and a sidewalk where cycling is also permitted (they can also be in opposite directions). Ideally in this case both borders would be rendered, with the bike lane on the inside and the sidewalk on the outside.

@Phyks
Copy link
Member

Phyks commented Nov 25, 2020

Would you have some typical OSM examples (best tagging for what is on ground examples) of this? This would be helpful to investigate rendering. Thanks!

@brainwad
Copy link
Contributor Author

brainwad commented Nov 26, 2020

The tagging per wiki is sidewalk:[left|right|both]:bicycle=*. Most usages are yes (e.g. https://www.openstreetmap.org/way/5030161, https://www.openstreetmap.org/way/540071931, https://www.openstreetmap.org/way/540071931, https://www.openstreetmap.org/way/46748836)
; designated should be uncommon but is sometimes used instead of cycleway=track, when the "track" is shared with pedestrians (this pattern occurs a lot in Germany, so maybe the German tagging guidelines lead people to this? e.g. https://www.openstreetmap.org/way/76062084, https://www.openstreetmap.org/way/865354107, https://www.openstreetmap.org/way/38177009). The only other common value isdismount, which is the reasonable default and so can just be ignored, IMO.

I would suggest rendering like a cycleway=track but with the cyan colour of a highway=path bicycle=designated if if the sidewalk is tagged as designated, and with the green path colour when tagged as yes.

I actually experimented with implementing this before, and I found that, at least around me, there is a huge problem with duplicate sidewalks. Some users love to draw in new sidewalks with separate ways (i.e. highway=footway footway=sidewalk) but don't check for existing sidewalk tags on the neighbouring roads. So when I rendered the sidewalks, they were duplicated everywhere. As you know it's almost impossible to do the deduplication within the limitations of CartoCSS... I would therefore suggest not rendering sidewalk tags without :bicycle tagging.

@brainwad
Copy link
Contributor Author

I hacked up what I suggested above, here are some screenshots:

image
image

@Phyks
Copy link
Member

Phyks commented Nov 27, 2020

Ok, I get it. Render proposal looks ok to me at first sight. Could you open a PR so we can work on this more in depth? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants