From OpenStreetMap Wiki
(Redirected from Talk:Class:bicycle)
Jump to: navigation, search


Your not feeling confident enough that your changes/ideas are accepted by everyone, put them down here so they can be discussed before they are added to the main page. Feel free to make the main page better also...

See also

Is the good route the shortest or the most secure ?

Usualy car routing engines offer the choise between shortest and fastest. There is not good route for cars. Even for bicycles what is the good route ? The shortest ? The most secure ? A subjective tag is unusfull : I will take a way on week day for going alone to work, the shortest is the best... I will take an other way for runing with my little familly on sunday afternoon, the most secure is the best... The subjective feeling of a way is not the same for the 20 years old student and the mummy. Who is right, who is wrong ?

OSM and routing engines have not to tell : what is good for you, but what is available according to criteria. has taken the good way offering the choice between security and length. It's realy cleverer thant a subjective tag. Other engines can offer the choice between other criteria.

It has already been a proposal for such a tag for the pleasure of driving. It has been rejected.

--FrViPofm 12:36, 3 May 2010 (UTC)

Well then lets make it clear that subjective security should not be part of the key. Because security can be very well described by looking at objective tags like what kind of highway, cyclelane (in reality very secure, for Sunday afternoon cyclist subjectively unsafe) versus cycletracks (subjectively safe for Sunday afternoon cyclists, in reality 4 times higher probability of lethal accidents than on a cyclelane, 12 times higher if cycleway=opposite_track). What this does not tell however are for example parked cars, house exits, .... which are really dangeround on cycleway=track. For me and many other enthusiastic cyclists, however important information such as how fast can I ride, can I ride besides my buddy or do we need to go behind each other, how is the scenery, and many other things that we simply cannot express objectively are missing, and that is what class:bicycle should be about.
Geovelo Implementation is shit, sorry. Security while riding 15km/h or 35-40km/h??. Their implementation does not seem to know about many tags at all. They don't seem to use tags like source:maxspeed, lanes, traffic_lights POI, and many others. Just calling it secure or fast is what everyone can do. Actually meating the demand is what is really difficult. class:bicycle should be about to promote/degrade a way if all popular relevant objective tags are already used, but any routing engine will still fail because it cannot know how is the scenery, how fast can we go, .....
We should set up profiles of different types for cyclists, and based upon them define their needs, and assess what can and what cannot be defined objectively (in reality, because noone will tag 50 objective atributes to a single street, neither can anyone interprete it). Also note due to the Anarchy of how things in OSM happen, as soon as enough software/map_producers announce to use it and it shows beneficious for the users, it will be used. That's why I don't do any shitty voting. This page is about getting it as well as possibly structured, and document it. Then we can see whether it catches on or not. I'm sure it does. There are enough subjective tags already in OSM like tracktype, smoothness, the type of highway which is subjectivity alone, and so on. In the end in OSM its the subjective tags that are used the most. People don't want to map surface=fine_gravel, width=3.5m, smoothness=factor, access_rights, ......., they prefer subjective things like saying this is a "trackt"--Extremecarver 13:20, 3 May 2010 (UTC)
I'm very sorry that you are surrounded by shit, Geovelo, votting... But I cannot do anything for you. Perhaps you could change glasses to see in an other way. Perhaps you could at least change your vocabulaty...
I'm very sorry that you don't understand the difference between subjective and descriptive.
--FrViPofm 17:50, 3 May 2010 (UTC)

What about using the network concept

For everyday commuting (not sports) it might be simpler to use the network concept on the city level as is already used for national, regional and local routes (see e.g. Cycle_routes).

I.e. there is only one tag/value pair (or relation) that tells if a way belongs to the cycle city network or not. The set of ways marked this way should yield a reasonably connected graph. Thus the cycle traffic concept for a city can be seen as a whole and not way-by-way. IMO its easier as one just needs to decide which is the best way in the surrounding. Its still subjective which roads to use for the network.

For the router it should be easy - find a way from destination to the network and then follow the network.

--Grungelborz 19:56, 3 May 2010 (UTC)

Did you read through my autorouting approach. I don't think so. I have about 300 lines only dedicated to decide how the routes shall influence the gereral autorouting. Routes give you quite good results for touring in Germany or Holland, where there is a dense cycleroute nethwork. They do not work well inside cities, and leave too much information out. I have also listed routes here in the requirements that should be fullfilled before an autorouting program even qualifies to use class:bicycle

See here again, I am already using ALL of these keys, but this is not enough for my perfectionist mind...:

   * highway
   * Tracktype
   * Smoothness
   * Sac_scale
   * mtb:scale
   * mtb:scale:uphill
   * Surface -- only for values documented on the wiki and the 20 most popular as on tagwatch
   * Usability
   * sport=via_ferrata -- no cycling is possible here (routing for extreme mtbikers an exception) 
   * Access -- if a router does not honour access rights, this is not a reason to degrade routing priority
   * Oneway & lanes=2 (for higwhay=primary,secondary and tertiary) -- High Traffic must be assumed here.
   * incline -- ways should not be taken out because they are steep, but the autorouter shall evaluate steepness based on inline key)
   * source:maxspeed=local/urban (for higwhay=primary,secondary,tertiary,unclassified,residential) (to find out whether a way is inside or outside of a city). In General except when "commuting" cyclists like to cycle outside of urbanized places. 

bridge/tunnel (because crossing something might be difficult, any autorouter shall consider bridges and tunnels and put higher priority on them automatically -

   * relation:route -- The router should favour ways that are part of a bicycle route. It can be assumed that routes follow suitable ways. If however there is nearby much better route, and the route has to be considered unintelligent, then one could degrade the way. --Extremecarver 20:03, 3 May 2010 (UTC)

Ups sorry, I missed to include that information. Read through here (and try to understand it) and then please accuse me of having forgotten something: (trekking / mtb) or road_cycling/commuting focusssed: --Extremecarver 20:06, 3 May 2010 (UTC)

A couple comments

I don't see this working. There's certainly subjectivity in assigning highway classes in North America: User:NE2/classification FAQ. But (except for trunk) the classes are de facto reasonably defined, taking into account primarily connectivity and secondarily the connections most suitable to traffic. They're not intended for people taking a Sunday drive, which is akin to all the suggestions on this page except "commuting". If I'm taking a Sunday drive, I don't expect a map to show which roads are more relaxing (which, for cars, would probably mean that few bicyclists use them if narrow). Similarly, if I'm going to ride my bike for exercise, I shouldn't expect the map to show which roads are most peaceful. And if I'm going to ride it for "commuting", I want the shortest route. If that means I'm going to slow down cars, so be it; I should have knowledge of vehicular cycling practices if I regularly ride.

The one thing that should probably be shown prominently is a hazard: is the bike lane in the door zone, or otherwise dangerous (to the right of right turn lanes, or not kept clear of debris)? Is there police (not motorist) harrassment if one rides outside said bike lane? Are there streetcar tracks? Is the multi-use trail full of walkers? When cycling, I'd treat these as "avoid if at all possible". --NE2 05:51, 4 May 2010 (UTC)

Please start a page where you put down all those things. My fear is that the list becomes so long, it won't be usable. So just prove me wrong by showing that semi-objective danger/harassment list is easier to use. I have heard this opinion a myriad of times, but so far everyone failed to come up with a list that could replace class:biycle. So from a practical standpoint, until such a list exists and is no longer than say 10-15 keys, I consider this as impossible to do.--Extremecarver 21:19, 9 May 2010 (UTC)
If that's too hard to do, how would class:bicycle be remotely possible? --NE2 23:48, 9 May 2010 (UTC)

More concrete details

Since the page looks very much like the cycleworth proposal, it'll likely attract no constructive comments; now there's a list of questions "track or lane? Is there separation from pedestrians?" which as such help to define nothing, nor will they as such attract readers to voice their opinions. Would anyone comment on every subheading "Personally, when I'm cycling, I like my ways to be ..."? Likely not, and even if they did, summarizing the results would be hard. You might have a clear idea of what the demographic groups of cyclists "want", but finding the solution should IMO start with defining the users' needs. Start with a user survey, here, on some suitable internet poll site or in your local neighbourhood to get statistical values in the form of "80% prefer residential roads over a cycleway with recurring curbstones". If you have concrete proposals as to what (even not-totally-objective) qualities make any single way really bad or exceptionally likeable, then people can (dis)agree on and discuss about those conditions.

Having followed the opinions on this, several have noted things that can easily be tagged and accounted for in the styles, that you don't mention: non-free-form hazards (gather, classify, assess, tag), curbs (individual or a statistical estimate), exceptional traffic density for the way type, prevailing wind direction (a sort-of-a canyon effect); there will likely exist more properties that could use a systematic tagging approach. For the perfect cost function it might then make sense to preprocess the ways (.osm file) with a new program (constructing a cumulative/multiplicative score), rather than to keep adding any more lines to mkgmap styles, or the like. A common cyclist, as in a person who just owns a bike, won't likely consider anything with a mtb:scale anyway. Alv 11:40, 4 May 2010 (UTC)

Scoring a route for A to B

The score for any given way might change depending where A and B are. That means having two values for the same key which would render this tagging method unworkable for such a way or ways. Being subjective you might also find different taggers would rate the same way differently. As someone mentions above, if the existing objective tags don't allow you to route as you wish, then there must be more objective tags that can be defined upon which you base your personal subjective decision.

This wasn't supposed to be a comment about objective vs subjective, but about how having multiple possible values for a single key make the proposal unworkable.

-- EdLoach 12:24, 4 May 2010 (UTC)

The final score depends on the A and B, but the score modifier for any single way would always be the same for the prototype of a person-who-owns-a-bike-going-to-work (or of any other group). Just as much as there is 85th percentile speed, there's a statistical median person and mappers could be guided to reasonably accurately estimate that point of view; although I think very, very few bits of road would be significantly different from the objective properties that need to be considered first. The proposer could offer some example pictures... Alv 14:37, 4 May 2010 (UTC)

Simplify adding routing info by the mappers

Assigning class:bicycle to every way requires too much efforts from the mapper. It will require years before the first city is properly tagged. IMO we need a system that makes it as simple as possible for the mapper to add routing information.

What a mapper familiar with an area usually knows is which are the best paths from A to B - if A+B are locations he usually visits and for which he tried multiple paths - e.g. the path from home to work. He does not really care if a section of this way is good or bad for cycling.

Thus the mapper should be enabled just to tell the OSM DB just which is the best path from location A to location B - without classifying the individual sections. If we have a large enough list of such paths the system one can compute from them the best location from any point to any other point - even if no direct path was entered into the system. It requires some calculations from the router but it relieves the mappers from some efforts.

For the mappers such a system would be more rewarding - if no-one else mapped routing data in his area he can exactly control how the router will route between certain points. If he wants to achieve the same with way classification it requires a lot more effort - and I think mappers will try to achieve this if they care about routing.

A simple implementation would be just to add all these paths to the OSM DB as relations. These paths would then form a network - this is what I meant with 'network concept' above.

A alternative implementation would be to allow the mappers to upload such paths to the gps tracks database and tag them with routing specific tags. e.g. 'recommended_bicycle' if a path is recommended for bicycle. The router needs to collect the tracks and add the recommended routes to the database. This way he could consider the suggestions of multiple mappers. For mappers this would be pretty trivial to use.

--Grungelborz 20:53, 9 May 2010 (UTC)

The problem is, it is not possible to map gps tracks to streets/ways. The accuracy simply isn't high enough. Hence routes as gps tracks won't help any computer/GPS decide how to find the best way. I believe that class:bicycle is still the simplest thing to do. Adding relations (and maintaining them) is much harder. GPS tracks would be like traffic patterns, and are a very good, but currently not usable solution. I am sure that in say 4-5 years this will be possible (the problem is that we need higher accuracy here than for cars - cars can only use a road, on a bicycle we can also use a sidewalk or a path - thus we need much better accuracy to determine where the track belongs too - and then should start to replace/takeover class:bicycle. Until it is technically possible, I would like to have something that is already possible. Class:bicycle should help mappers that are unsatisfied with certain stretches of a calculated route by their GPS/software to add a key that can be evaluated, but also allow to "print" maps with ways friendly for the kind of cyclist.--Extremecarver 21:14, 9 May 2010 (UTC)

Tagging cyclability now

I had about the same idea as Class:bicycle, Proposed features/Cycleworth, Cheltenham_Standard and Key:rtc_rate mentioned on the Map_Features page. My goal was to create a map where not the legal cycle network is shown but the one used by cyclists everyday. So I thought about collecting optimized tracks from cyclists that travel a lot and have therefore found the most ideal route e.g. between home and work.

It took me quite a while to find above-mentioned pages - at first I thought that this information is too subjective. But when I thought more about it I came up with about the same as proposed in Class:bicycle or Proposed features/Cycleworth. The other two lack a very important feature: differentiation between a fast route (commuters) and a safe route (children, inexperienced riders).

So what's the best way to tag a city right now?

Class:bicycle has the best description but is totally unofficial, Proposed features/Cycleworth is not an official feature but at least proposed. I am eager to tag Vienna!

--Evod 17:40, 27 September 2010 (BST)

I just counted in my database (as of mid August 2010):

  • rtc_rate: 5070
  • class:bicycle : 2629
  • cycleworth: 80
  • bicycle:suitability: 0
  • class:bicycle:*: mtb: 104, commute: 34, touring: 80, roadcycling: 77, trailer: 0, non_experienced: 7
  • cycleworth_*: transit: 0, rr: 0, mtb: 75, touring: 7

As you can see, cycleworth is rather dead. It's now between class:bicycle and rtc_rate. There are no objects which use both systems. -- Skunk 21:45, 27 September 2010 (BST)

rtc_rate is not even explained, so I would not use it. It is inside map_features, yes, but was neither proposed nor voted on, so I would advise against using it. Cyleworth was my first go at it, but class:bicycle ist much better explained and designed. The important bit is, that any subjective tag should be based on objective tags, and only if it is too difficult to use objective tags to properly describe the situation, then a subjective tag is useful and needed. I did not propose class:bicycle to map_features, because too many mappers don't understand the principles for autorouting. Once this gets into peoples mind then it should be proposed....Usage is not yet as widespread as it should be, but I'm sure it will come. Take mtb:scale which I designed/proposed and pushed through, it is now used quite broadly (more than 40.000 times), as other mapmakers than me will implement class:bicycle, usage will spread. If a tag is not used for maps, it's dead. Before I implemented mtb:scale in my maps, it was basically not used at all, even though voted on some month before...--Extremecarver 23:31, 27 September 2010 (BST)
Extremecarver, do you think that class:bicycle is suited for tagging an inofficial but "everyday" bicycle network? Right now I am collecting fast routes through Vienna ( In Vienna the official routes have many holes and form no complete map, therefore I try to fill these holes with the "best" streets I can find. This means that in order to get a complete bicycle network one has to use some roads one would normally like to avoid by e.g. tagging them with class:bicycle=-1. If I only enter my network into OSM I get a complete overview of relevant bicycle routes by visualizing class:bicycle. So do you think it is a good idea to use class:bicycle for this purpose? I think it could work if people don't start tagging each and every street but just connected routes that form a net. Maybe one could emphasize this in the description? --Evod 18:04, 11 October 2010 (BST)
Well class:bicycle refers to good usage. Ways that are well suitable to get from A to B of course do have an advantage. But it should not be purposely used for creating networks. I think route:unofficial=bicycle or a similar key would be better. Mind many people objecting route:unofficial even more than class:XXX--Extremecarver 11:27, 12 October 2010 (BST)
If people are objecting route:unofficial and you think class:bicycle should not be used for this purpose than it's more or less impossible to do what I want. Also route:unofficial does not contain any qualitative information (the two most important categories for me being a) fast and b) secure). In Vienna some people used lcn=yes for tagging cyclefriendly streets, that's also not optimal as a) the routes I want to tag are not official and b) one can't specify speed/secure/... Damn. --Evod 17:47, 12 October 2010 (BST)

Confusable with North American standards

The “class” terminology could be easily confused and conflict with the common North American classification of bicycle facilities as class I (bike path, or separate facility), class II (bike lane), III (bike route), and sometimes class IV (bike friendly). This is codified in California design standards and laws,[1] and commonly used throughout the United States and Canada. Michael Z. 2013-09-19 15:42 z

A better key name might have some meaning, giving a cartographer or map reader a clue as to what the number indicates. For example, suitability, difficulty, ease, preference, or comfort. Michael Z. 2013-09-19 15:54 z
I have added a note to the page to help prevent confusion. Michael Z. 2014-12-10 19:06 z
Good idea, I think the name of this key is not very good chosen:(RicoZ (talk) 21:16, 10 December 2014 (UTC)

class:mtb vs class:mtb:technical

I have tried to consolidate the description but have no idea what the difference here is. RicoZ (talk) 22:21, 22 November 2014 (UTC)


It seems the name of the key is rather counter intuitive, against the principle of least surprise, with an acronym that is hardly intelligible even if you know what it should mean - and pretends a "class:" namespace where there is not any.

So plenty of good reasons to rename it I would think. Maybe the concept should be generalized to other activities - I could think hikers and other outdoor sports could use a "subjective rating" system for paths etc.

So the idea with an own namespace is not a bad one, just needs a better name prefix and some thoughts to make it easily usable for other activities. RicoZ (talk) 12:29, 23 December 2014 (UTC)

How about bicycle:suitability or bicycle:ease (bicycle:difficulty is very clear, but the +3 to -3 scale is the reverse). Michael Z. 2015-01-21 21:10 z
That would be a generalization of mtb:scale=* for other types of bicycle which would be useful in itself, but would not cover cases where a route is desirable or should be avoided for reasons other than difficulty (plenty of families with children and dogs), cycling around a smelly landfill or a local drug meeting point - or on the other hand a very pretty route. RicoZ (talk) 13:13, 22 January 2015 (UTC)

"Unsuitable" = -3 or not on scale at all?

Does this scale allow entirely "unsuitable" or no? I'd have thought =-3 represents that but then definition for =3 makes hardly sense as you'd be allowed to take many "unsuitable" ones to get there. Ij (talk) 17:50, 6 September 2015 (UTC)


As of now the tags:

  • about 17000 class:bicycle:* tags
  • 661 rtc_rate
  • 200 cycleworth

So clearly that debate is over. However it is quite interesting how people apply this tag. For example go and see which are the greatest cycleways in the world? Look for class:bicycle=3. Or the same about mtb. There is even a "4" class route! Must be causing immediate orgasm or something. ;-) I'm not quite sure the tag is interpretable on any scale.

Do not take me wrong: I believe it is useful, it gives "some" informations, basically preference or dispreference in the statistical sense. It's just interesting to check the usage from time to time and maybe ask people why did they tag "extremely desirable" a route while there are infinitely prettier ones just around the corner. :-)--grin 09:07, 27 September 2015 (UTC)

I was wondering if +/-3 is a sufficient range;) I would have designed it with +/-5 as I assume most people would find it psychologically easier to rate things in that scale. Otoh I think changing the definition at this point is not an option as it would invalidate all previously tagged cases so instead data consumers should be advised to discard any values other than +/-3. The OsmAnd team is quite willing to integrate this key to their routing which involves tweaking 2 xml files and I assume when a few more routers will support it people will discover where ratings need to be fixed. Like with other tags it is quite possible they are also abused intentionally in some places to reroute traffic from someones area. RicoZ (talk) 10:00, 27 September 2015 (UTC)

2016 - helps to improve cycle routes a lot

Please keep the "bicycle" class. If people are using navigation programs for cycling, the "bicycle" class can help a lot! It adds some possibilities that cannot be achieved with the other data in OSM.

Let me explain: Very often, I have tried finding the perfect route for cycling in Berlin, using offline navigation with the Osmand app. You can re-program Osmand to prefer residential roads and bike paths, etc. Not bad... But what you cannot do: Tell the app to prefer scenic routes (for example through forests or along waterways). Osmand does not "recognise" what is next to the route. So, for example, if there is a bike track next to a big noisy motorway, and another one along a calm river, Osmand will NOT prefer the quiet and scenic track. That means: If the noisy and ugly track is just one meter shorter, Osmand will take that one.

But for many cyclist, "green" routes (along waterways, through parks or forests) are highly preferable: No cars, no traffic lights, no noise, and a beautiful landscape. The "bicycle" class can help a lot here. For example: The bike path next to the motorway can be tagged as class:bicycle:touring=-2. (negative value). This means: It is not recommended for touring (= recreational cycling), but it might still be good for commuting (= people who just want to go fast and safe, but do not care about the rest).

So I think it is good that there is a distinction between class:bicycle:commute AND class:bicycle:touring. "Commute" means: "Getting quick from A to B on reasonaby safe roads." And "Touring" means: "Cycletouring and Trekking. Avoiding ugly and dull landscapes, avoiding cars." So this is less subjective than some people think: Users can fine-tune their navigation app according to their preferences: "fast" or "a bit slower, but along waterways or through forests."

Let me finish with two additional arguments: 1.) Better cycle navigation will make a big difference! Very often, there is a MUCH better alternative than the one suggested by apps like Osmand. I have tested navigation apps in Berlin, Hamburg and Munich. Very often, you are told to take a bike track along main roads, even if there is an alternative through parks and forests that is even faster (it is a bit longer, but is has no traffic lights).

2.) Theoretically, a navigation app could recognise forests or parks that are next to a bike track. It is not implented in apps like Osmand because it needs too much processing power. But if mappers just add a "class:bicycle" value to the bike track itself, Osmand can already use these data!

I would like to start adding some "bicycle:touring" values for bike routes in Berlin. But if this class might be abolished some day, it might be a useless task... So I welcome any comments or hints: Will this class stay? I would recommend it.

Best wishes from Berlin