Left/right separation for class:bicycle key to improve routing

General talk
1

Hey guys,
I really like the key class:bicycle to improve routing suggestions for bikers.

I wish this key had a left/right distinction. Since I am new to OSM I’d like to ask where I can make such a suggestion?

I have three real world examples:

  1. When cycling on high traffic roads with a race bike I prefer to avoid them. Especially if the road goes upwards, this is a real problem. But if the road just goes down, I it takes less time to travel there, so it is okay.

  2. Sometimes a road has more space for bikes in the one direction, but not on the other.

  3. I have a very specific scenario here in the town where it makes sense to drive over the bridge, to join the road on the right side and not joining in on the left, where you need to cross it. However the left side is super important if you want to cycle the other way, where it makes totally sense. So you can think of it like two one way roads, just that it is a suggestion and not effectively a rule. If that scenario is still unclear I can show you a picture.

Now what do you think, and how can we get class:bicycle:left to OSM?

2

Did you read this about cycleways?
https://wiki.openstreetmap.org/wiki/Key:cycleway

3

I dont really understand what you want to tell me. Sure you can add different information for left/right, but not a direction dependent recommendation (via class:bicycle).

4

class:bicycle= shouldn’t be used at all, as described. As or contrary to https://wiki.openstreetmap.org/wiki/Key:class:bicycle#Proposal , not only is the existence of any proposal or discussion non-apparent (quite the opposite there’s https://wiki.openstreetmap.org/wiki/Proposed_features/deprecate_class:bicycle_tag_family made up to discourage it), but it also risks confusion with the “Class” of bikeway infrastructure.

  1. “high traffic” is not considered something that can be easily added. Gradient can be factored by applications using a DEM (you would already see contour lines and hillshades), or directly added by incline=
  2. Standard tags of cycleway=, lanes=, width=, etc. There are new ideas and trials, eg https://wiki.openstreetmap.org/wiki/Proposed_features/cycleway:separation .
  3. This is a router issue, if anything, to prefer non-conflicting movements.
5

Alright, but there is also no alternative to that? So the only option is to keep that data in the router application?

6

As Kovoschiz says, it’s best to record the objective information, not a subjective judgement that might not be shared by other cyclists.

You could in theory record traffic information in OSM - there’s no reason why not, other than counting cars is boring! You’d use something like traffic:aadt=13000, source:traffic:aadt=estimate (where AADT = Annual Average Daily Traffic, the standard way of measuring traffic). Better to get your local highway authority to release their traffic counts as open data so that bike routers can use it. But I note that you’re in Germany where most authorities do release their data, so a smart router will already take that into account.

7

That is a good point. Is there also a way to map if a fast road (Bundesstraße) has a side lane (Seitenstreifen)? So routers could take into account if there is a high traffic road without a side lane which is dangerous.

8

https://wiki.openstreetmap.org/wiki/Key:shoulder if bikes are signposted to use it add cycleway=shoulder

9

I decided not to mention https://wiki.openstreetmap.org/wiki/Key:traffic:hourly for a few problems, one thing beingtraffic:*= used separately in an inactive https://wiki.openstreetmap.org/wiki/Mappa_Mercia/UTC for Urban Traffic Control (my country uses both SCOOT and SCATS for regional adaptive signal coordination). Not to mention traffic counting can be technical and challenging, especially manual collection.

Some basic issues in traffic data:

  1. Vehicle vs PCU (necessitating a unit, and conversion factor; also heavy vehicles proportion or truck T-factor, and definition)
  2. Year, needs to specify if estimated by growth factor
  3. Sampling methodology (that page has attempted at a tag format)
  4. AADT needs to be obtained by multiplying the ADT by an adjustment factor for day, month, and season.
  5. Variables: Observing peak vs off-peak volume (time variation), flow directional split, etc

Entering a number seen on a man_made=monitoring_station + display:*=yes + monitoring:traffic=/monitoring:bicycle= (though don’t know why *:bicycle= is separate from the *:traffic= suffix) would be more direct and reliable.

10

Yep, you’re absolutely right that there are issues to be considered. But OSM has always iterated towards completeness - it doesn’t have to be perfect from the off. In particular, there’s potentially a lot of value in crowdsourcing low-traffic roads where it would never be economic to install monitoring hardware.