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

Honour key oneway:bicycle #5058

Open
hungerburg opened this issue Jan 25, 2025 · 11 comments
Open

Honour key oneway:bicycle #5058

hungerburg opened this issue Jan 25, 2025 · 11 comments
Labels

Comments

@hungerburg
Copy link

1: Key oneway:bicycle gets used to mark up streets that are one-way for cars but are not one-way for bicycles. The app on my mobile phone displays roads marked oneway:bicycle=no with the usual black one-way arrow and an adjacent blue arrow pointing in the opposite direction. In my eyes, this is a very apt cartographic representation of the on the ground subject matter, I wish OSM-Carto could do like that.

2: Sometimes so-called shared use pathways (pedestrian and cyclist) are mapped as highway=footway. I they are marked with tag oneway:bicycle=yes when true to the ground they could also show a blue one-way arrow. In my eyes, adding a blue one-way-arrow there could also clearly convey the on the ground subject matter. (As of now, many such shared use pathways are mostly marked oneway=yes which produces a red one-way-arrow -- I think that is fine and can stay like that because the mapping being inconclusive.)

@imagico imagico added the roads label Jan 26, 2025
@imagico
Copy link
Collaborator

imagico commented Jan 26, 2025

Two very different issues.

The second IMO is not a viable idea without a rendering concept for visualizing dual use paths as such in the first place - see #5025.

The first would depend on a concrete viable design proposal - which refers both to the principal visual aspects as well as how to handle all roads where cars are not the primary mode of transport and how to interpret the various tags that practically indicate if and in what directions a road can be used by bicycles (which includes in particular the more specific cycleway:left=*/cycleway:right=*/cycleway:both=*).

@dch0ph
Copy link
Contributor

dch0ph commented Jan 27, 2025

The first would depend on a concrete viable design proposal - which refers both to the principal visual aspects as well as how to handle all roads where cars are not the primary mode of transport

I'm not sure what is meant here? I think it would be fine to have a symbol that applied solely to vehicle highways, since this is the primary case where there is dedicated infrastructure / signage for "opposite direction cycleways". Or do you mean vehicle roads closed to cars e.g. motor_vehicle=no? [Any oneway arrow is already a bit ambiguous in this case already.]

in what directions a road can be used by bicycles (which includes in particular the more specific cycleway:left=*/cycleway:right=*/cycleway:both=*)

If going with the simple double-headed arrow, this shouldn't be needed - the direction of the "second arrow" should be clear from the combination with oneway?

My only reservation is that the meaning of the double-headed arrow by itself may be unclear. In the CyclOSM carto style, the meaning is reasonably obvious since it is (a) a cycle map and (b) is showing the cycle infrastructure (including left / right etc.):
Image

This makes it clearer that the blue arrow refers to the cycle infrastructure.

@hungerburg
Copy link
Author

hungerburg commented Jan 27, 2025

My bad, obviously other map styles available on the main site use the same signature as the app on my mobile for one-way roads that are not one-way for bicycles too. Still I think this is something that a map style for the general public might want to show too. I also understand, that maybe the two cases I mentioned are two kind of shoes, as we say here. One is more about showing the contraflow arrow, while the other is more about in which colour to show the flow arrow in. Preliminary thoughts on that:

Regarding 2) Recently the community forum discussed how to get rid of ambiguities when mapping/consuming one-ways. The generic oneway:<vehicle>=* was considered superior over plain oneway=* by almost all involved, explicitly on so-called shared-use infrastructure. Though, it is only used marginally. Nevertheless the more specific oneway:bicycle is honoured by all the routers available on the main page, regardless of use is shared or single mode and is used widely.

Regarding 1) I was told in mapping school, that the kind of cycling infrastructure does not actually matter, as the street (the whole of it, a.k.a. highway in OSM terms: carriageway, cycleway, pavement) is concerned by the oneway=* tag. Below aerial overlaid with OSM-Carto for further explanation :

Image

Where I overlaid separate cycle ways (the fictitious noexit are true to the ground, the cycle lane just ends there abruptedly) the street is tagged:

cycleway:left:lane=exclusive
cycleway:left:oneway=-1
cycleway:left=lane
cycleway:right=no
highway=residential
lane_markings=no
lit=yes
maxspeed:type=AT:urban
maxspeed=50
name=Universitätsstraße
oneway:bicycle=no
oneway=yes
sidewalk:both:surface=asphalt
sidewalk=both
surface=asphalt

The gap with no separate cycle ways in the picture still is oneway:bicycle=no - no need to dismount there -- I have observed people doing that, but this is not legally required, the street is still open to contraflow cycling, no matter if there is an extra lane there.

PS: What prompted me to file this issue was use of tag oneway:bicycle=yes on footways. I now looked at taginfo, a quarter of oneway:bicycle has yes as its value, https://taginfo.openstreetmap.org/keys/oneway:bicycle - This does not show the kind of highway, overpass example for Germany, https://overpass-turbo.eu/s/1XS0 - it is indeed a bit trickier than imagined, lots of "path" might be cycleways and show blue arrows already when having plain oneway=yes or show nothing without that. No idea yet, if that is something to care about on a general purpose map, leaning towards yes though.

Image

@dch0ph
Copy link
Contributor

dch0ph commented Jan 28, 2025

PS: What prompted me to file this issue was use of tag oneway:bicycle=yes on footways. I now looked at taginfo, a quarter of oneway:bicycle has yes as its value

Wow! Those numbers are bit surprising.

I don't have any good thoughts on this, as I find bicycle tagging on highway=footway a bit strange.

We could narrow the issue to oneway:bicycle on cycleways and oneway:foot on footways. Perhaps dig into those cases a bit?

The logical thing would be to mirror what we now do with access tags, where the specific mode tag "overrides" the general access tag. So oneway=X + oneway:bicycle=Y would be determined by Y on a cycleway.

This may help to highlight messed up tagging where oneway=no + oneway:bicycle=yes (which could easily be a mistake) will be "interpreted".

On the other hand, I can't help feeling that using oneway:bicycle on cycleways, and we perhaps should be focussing on the simple oneway tag where its usage should be clear.

@mcliquid
Copy link

I don't have any good thoughts on this, as I find bicycle tagging on highway=footway a bit strange.

It should be noted that the figures only provide a snapshot of Germany. In Germany, it is legally possible to open a sidewalk to cyclists by means of this combination of traffic signs: https://trafficsigns.osm-verkehrswende.org/DE?signs=DE:239,1022-10

(Personal opinion: this is usually done when a city wants to create a cycling infrastructure, presumably for political reasons, but then not enough space is cleared for a separate cycle path)

If a sidewalk is open to bicycles, then it is not compulsory for them to use it, unlike on a combined path or separate cycle path. (Keine Benutzungspflicht) When a cyclist is using this sidewalk, they are only allowed to cycle there at walking speed. And pedestrians have the right of way.

Not without exception, but very often these signs are only erected on one side, which means that cyclists have to follow the one-way system.

@hungerburg
Copy link
Author

Wow! Those numbers are bit surprising.

Perhaps the more surprising, in neighbouring country Austria the numbers quite different, but still path ranked top with similar percentage but footway dropped down a lot. Overpass query easily to adapt to country, just swap name in line 2.

Numbers also show, this is a niche tag. 2500 km in all of Germany, this is nothing. I learned of that, when I swapped a oneway=yes tag on a footway to a oneway:bicycle=yes tag and a bit later found that OSM Carto no longer shows a red one-way arrow (that I naively would understand as oneway for pedestrians) but does not show any one-way arrow at all.

Perhaps OSM-Carto rendering was devised before this change in documentation? To repeat the issue raised here: Is it worthwhile to honour mode-specific oneway taggings? Mappers obviously tag them…

@dch0ph
Copy link
Contributor

dch0ph commented Jan 30, 2025

Perhaps OSM-Carto rendering was devised before this change in documentation?

I can't speak for the Carto maintainers, but my understanding is that we try to track actual tag usage (which is why the numbers above are interesting / useful) rather than what happens to be on the Wiki. Carto is generally very conservative about interpreting/rendering new tags to avoid becoming a driver of mapping.

But I don't see that the change highlighted makes much difference. It seems to be arguing that oneway as an isolated tag is only properly defined by vehicle highways, whereas Carto has always(?) rendered oneway applied to path and footway (with a red arrow corresponding to foot traffic). Since bicycles are vehicles, this suggests to me the oneway:bicycle is redundant on a cycleway?

I learned of that, when I swapped a oneway=yes tag on a footway to a oneway:bicycle=yes tag and a bit later found that OSM Carto no longer shows a red one-way arrow (that I naively would understand as oneway for pedestrians) but does not show any one-way arrow at all.

This would seems to be correct / intuitive behaviour for the case above (the footway is not oneway for pedestrians)?

To render oneway:bicycle on highway=footway, I think you would first need a visual indication that the footway could be used by both modes (as being discussed in #5025). I feel a higher priority would be first improving the overall rendering of footways (#1793).

@hungerburg
Copy link
Author

If I may elaborate some more? Below two screenshots:

A footway with oneway:bicycle=yes set. From looking at OSM Carto I neither learn, that cycling is allowed there, nor do I learn, that cycling is allowed only in one direction. Latter holds of the cycleway over the bridge just the same by the way, it is also tagged oneway:bicycle=yes only and OSM Carto does not render a one-way arrow there. A blue one-way arrow could kill two birds with one stone (machine translation), could it?

Image

A footway with oneway=yes. Perfectly fine with me if that was the sole one-way tag there. (Not so the wiki: There oneway only ever applies to vehicles and not pedestrians.) Not long ago it was only tagged oneway:foot=yes (the wiki suggests that) and did not show a one-way arrow then. I think it should have. The red arrow is the only way to learn from the map (and oneway* in the data of the way) in which direction the turn-stile can be passed.

Image

From my naive perhaps understanding: Mode specific one-way mappings not that much depending on the higher priority tasks but low hanging fruit instead? They are mode specific after all, no heuristics needed. Therefore I also do not see how showing them will hinder progress on the higher priority tasks. I might be wrong though and certainly not in a position to sort priorities of the people behind this in so many regards well developed map style.

@mcliquid
Copy link

A footway with oneway:bicycle=yes set.

Just a tiny note from my modest experience: As far as I know, the highway value should always be based on the “largest” means of transport. In this case, it would probably be a highway=cycleway or the alternative with highway=path. cycleway=sidewalk and path=sidewalk are tags that are used.

@imagico
Copy link
Collaborator

imagico commented Jan 30, 2025

A reminder to everyone: This is not the place to discuss how things ought to be tagged. It can be of value to discuss how things are tagged as far as this is relevant for the issue at hand - but this should be looked at on a global scale of course and not only for specific regions/countries.

Questions that are useful to ask in cases like this are:

  • what exactly is the information that is suggested to be shown?
  • what is the established mapping practice to record that information?
  • what are viable ways to display that information?
  • what changes in terms of design context are necessary/advisable for that?

@dch0ph
Copy link
Contributor

dch0ph commented Feb 1, 2025

Taking @hungerburg 's two examples:

Image

Here the information to be shown is really that the footway can be used by bicycles (as stated above, I think this information has to come first, and then any oneway arrow). It would be very interesting to visually indicate "footways that can be used by bicycles" and "cycleways that can be used by pedestrians". This could neatly tie up the discussion in #5025 about how foot/bicycle should be interpreted on highway=path. This probably needs to be a new issue together with a suggested design proposal. I think this would be hard to combine with continuing with a 3-state indication of the surface (paved / unpaved / unknown), but it should be easier than the related issue around highway=track (#4321).

Image

Here the issue is how to determine whether a footway is shown as oneway (the design already exists). I would argue that the established mapping practice is to use oneway=yes (whatever the Wiki now says). "Expansive" map designers do choose to handle alternative ways of tagging the same say thing (e.g. effectively using COALESCE(oneway:foot, oneway)) but again I feel Carto needs to be conservative. So yes, it would be easy, but that doesn't make it a good thing to do.

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

No branches or pull requests

4 participants