Talk:Key:class:bicycle

Discussion

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

• Talk:Key:class:bicycle/opinion

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.

http://www.geovelo.fr/ 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: http://svn.origo.ethz.ch/wsvn/openmtbmap/lines (trekking / mtb) or road_cycling/commuting focusssed: http://svn.origo.ethz.ch/wsvn/openmtbmap/bikingmap/lines --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)

I'd also add: That won't work. Especially not for usage by routing software. Besides the subjectivity: It is just not maintainable. The streets change quickly. And even with other concepts you don't get along easily. I just sorted out one relation of the official bicycle network in my town (222578 222578 - only the ways that are officially signposted as part of the cycling network but not a part of the node network or named routes. Therefore an official cycling recommendation.) by cycling all the routes (about 1000 km cycling necessary). The OSM-Data was completely outdated since more than 10 years. I'd rather recommend to officially deprecate the usage of that tag.

It would be a bit different if you could automate that with an app. But for the subjectivity you would get pooled data which would have to be processed before they could be published. An that's not an OSM topic. You could collect a rating of routes and combine them with OSM-Data. But as OSM-Data should be objective this would be another project and not part of OSM. Cycling on terrible ways I by myself thought of an app that would measure the vibration and add the results automatically to the ways (in an internal database, not directly to osm of course). But even that would be quite objective but not clearly reproducible due to different weather situation, riding style, sensitivity of the sensors, the amount of damping in the montage of the smartphone to the bike... --Segubi (talk) 11:41, 7 August 2022 (UTC).

A route is a recommendation by a private or public organisation that takes many streets and ways into a concept. However it may not be ideal for everyone - or sometimes just used to channel cyclists onto the route away from other streets/ways. But it's harder to keep track of routes than individual segements. So I don't see why deprecating class:bicycle does any good. Its use is very different because it is not dependant on any kind of route/network. And subjective tags are the only reason besides in crowded places usually more up to date than other maps (however opposite in remote areas) and it's open license for OSM to be somehow relevant. Keys like tracktype, smoothness, mtb:scale, sac_scale are the only place where OSM is much better than the competition - so we rather need more subjective tags then less. For car routing OSM is lost vs real time data from google by large amounts. Actually without them OSM could be deprecated for many use cases as private companies like Trailforks create their own subjective layers (on top of OSM but in closed license) that showcase that user generated content on usefulness of a way for Sport X is way more important than anything else.--Extremecarver (talk) 13:07, 8 August 2022 (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 (velo.ravage.at). 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)

rename

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)

2015

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

Disputed examples

Track

"class:bicycle=1 highway=unclassifed/tertiary & cycleway=track "

• Why just 1 an not 3?
• It goes against "additional hint for bicycle routes which were not adequately described by "objective" tags" - cycleway=track is enough to mark it as a good route

Mateusz Konieczny (talk) 17:44, 16 January 2021 (UTC)

Moved to examples when it should not be used Mateusz Konieczny (talk) 00:03, 21 January 2021 (UTC)

I don't see any reason why cycleway=track tells you whether or not a street is bicycle friendly. Actually cycleway=track for me if inside a city means stay the f**k away - because cycling on a track instead of a lange or street itself increases your danger to die about factor 4. Car drivers tend to overlook bicycles on cycleway=track. Even on the countryside this is a bit dangerous. The worst case if you have to use that cycleway:right=track against the traffic flow. That increases your danger to die by factor 11 (numbers from Germany - ADFC). There are good cycleway=track - but loads of horrible ones too.--Extremecarver (talk) 12:46, 27 January 2021 (UTC)

Good point that side of track matters, I amended to version with cycleway:side version from cycleway=track. "I don't see any reason why cycleway=track tells you whether or not a street is bicycle friendly" - it depends on interpretation, for some it is desirable, for some no. Tagging presence of track allows you to handle this, while with class:bicycle there are people hating such infrastructure and some people liking it Mateusz Konieczny (talk) 12:58, 27 January 2021 (UTC)

The thing is - in many cases it will be good for everyone (very few side roads - no house exits) - in other cases not good for everyone (e.g. width not enough/too many pedestrians using it too, whatever). There are so many factors that you simply cannot describe with tags, or which are often left out.--Extremecarver (talk) 05:07, 30 January 2021 (UTC)

Lovely scenery

"Make it stick out from the rest of ways. Lovely scenery. " - there would tourism=viewpoint mapped there that can be shown/considered by mapping software, right? It seems far better than "class:bicycle:mtb=2" review rating not specifying at all why this way is nice Mateusz Konieczny (talk) 00:34, 21 January 2021 (UTC)

Moved to examples when it should not be used Mateusz Konieczny (talk) 08:36, 22 January 2021 (UTC)

because you would need to tag the tourism=viewpoint onto the street itself, or connect it via a relation - that is not done however. Also just because the scenery is beautiful - it doesn't mean someone built a viewpoint! There could be viewpoints with really bad scenery too. Too many factors come into play here...--Extremecarver (talk) 12:49, 27 January 2021 (UTC)

It is not necessary to connect it with relation to process it, if there is a great viewpoint then tourism=viewpoint can be marked - that does not require construction. "viewpoints with really bad scenery" - how that even works? Mateusz Konieczny (talk) 12:59, 27 January 2021 (UTC)

Yes it would need a relation. How else do you know it's relevant then? You draw a radius around the viewpoint and all viewpoints in that radius increase the status of the road? That won't work - what about a road in the valley vs one on top. What about a viewpoint in a high tower besides the road. If it's not connected then it has to be irrelevant for routing. That's a clear consensus because OSM is 2D only. And we don't know which radius to draw. Mapping the viewpoint onto the road itself - however would be wrong. So then you could add a way to the viewpoint - not so nice either cause usually it's an area and it's a bit of redundant info for a human (not for a machine). --Extremecarver (talk) 05:10, 30 January 2021 (UTC)

Unexplained class:bicycle:mtb:technical=1

"In such an altitude many ways vary in difficulty a lot, and finding ways for mtbiking is not easy. Assumption most of the trail is ridable." is not explaining why mtb:technical=1 is to be set. What is not covered by mtb:scale=3  ? Mateusz Konieczny (talk) 08:35, 22 January 2021 (UTC)

Well - we could maybe specify this better. class:bicycle=mtb refers to Cross Country to All Mountain type of mtbiking. mtb:technical to Enduro/Freeride/Downhill or gravity related mtbiking. The difference is a bit floating - as All Mountain kinda could be both - but the difference from Cross Country to Downhill is huge. And some Downhill tracks are not that difficult - but just beaten up. So it does make sense to keep this differentiated.--Extremecarver (talk) 12:52, 27 January 2021 (UTC)

Is this tag used?

Key:class:bicycle#Comments contain multiple requests from people developing bicycle-related software using OSM data. All of them describe this tag as a horrific mistake.

Is anyone actually using this data? Mateusz Konieczny (talk) 00:07, 21 January 2021 (UTC)

I use it for my maps. And it does help. It would be nice if more mappers were using it though. --Extremecarver (talk) 12:52, 27 January 2021 (UTC)

"I use it for my maps" - is it some private use or is something made available to a public? Mateusz Konieczny (talk) 13:00, 27 January 2021 (UTC)

Public - https://openmtbmap.org and www.velomap.org (overall about 150.000 users downloading maps every month)--Extremecarver (talk) 05:11, 30 January 2021 (UTC)

Why avoid 0?

Currently, the values section says: “"0" = as well as other ways around. Try to avoid using 0 but decide on -1 or +1.”

I assume the definition is supposed to mean “as good as other ways around”. If that is so, what's wrong with tagging a path with 0?

Or, asked independently of the wording of the definition here – just from a statistical point of view: For most such distributions in the real world, it is reasonable to assume that they have a maximum in the middle - like the Gaussian distribution. Why should we try to artificially impose a different distribution? SebastianHelm (talk) 02:21, 26 October 2021 (UTC)

0 is avoided because of the key's intent to minimize data - and only be used when other keys are not sufficient to properly describe the way in regards to cycling. Most ways will be 0 - so this is assumed to be the default and does not need to be tagged. --Extremecarver (talk) 10:13, 6 November 2021 (UTC)

Mhh, so the value 0 serves two functions: (a) as indication that the way is average, and (b) as indication that nobody has assessed the quality yet. Is that correct? How can one, then, distinguish the two?

On second thought, I realize that that's the point of not using 0. That works as a workaround if one can't have something like NULL. But is there really no NULL in the underlying database? For other data, such as the number of floors above ground of a building, we need to be clear about that distinction; why is that different here? SebastianHelm (talk) 19:18, 6 November 2021 (UTC)

Yes in that regard it is true - it makes sense. If you want to clarify that is has been assessed 0 makes sense. As it's 0 and it won't be used however (note a way that by itself is average, but way better than any alternatives around could be marked +1 as it's supposed to be relative to offer around it).--Extremecarver (talk) 09:35, 10 November 2021 (UTC)

2022 - and pulling chat from the main page

"I am asking after realised that there is no way I could tell that a highway=unclassified is a bikers heaven or a suicide mission between rallye racers and trucks" - can you list tag that you tried so far? Can you give examples of roads that fully tagged in OSM are still not distinguishable from each other, but have strong difference in cycling quality? (Google Maps links are fine) @Grin: Mateusz Konieczny (talk) 20:35, 2 September 2022 (UTC)

@Mateusz Konieczny: I am not sure what you want. The example is dead simple: highway=unclassified. Both are about same width (3.8 m), same surface, smoothness, etc. One is actually connecting two cycleway=* and rarely have any traffic, and it is a "cycleway" without being legally one; the other is a normal unclassified road with significant car traffic. This is true for about 200 km of recently built "bicycle infrastructure" in Hungary where the roads do not possess a cycleway sign, no access limitations or alike, but they were "advertised" as bike roads. Versus all the thousands of kilometers of unclassified motorcar roads. I have tagged some (partially incorrectly) as bicycle=yes to be able to at least distinguish from the noise but it is an extremely noisy tag, quite unreliable and its meaning is hazy. For my test you can see my debug vectormap where the light-blue lines are bicycle=yes, the green and dark blue are mostly cycleway=*s of various kinds and pink is all kinds of cycleway=shared_lanes. You can also see dotted bicycle routes, and observe that their ways are often uncolored. --grin ✎ 22:07, 2 September 2022 (UTC)

"I am not sure what you want" -Google Maps Street View (or photos) + links to OSM objects Mateusz Konieczny (talk) 22:45, 2 September 2022 (UTC)

@Mateusz Konieczny: What don't you see from the above paragraph? Also if you neglect to ping me then I will not get notified. Here are some unclassified highways which are cycleways in practice (class:bicycle:touring=3). Here's one with signficant traffic (class:bicycle:touring=-2). --grin ✎ 12:36, 3 September 2022 (UTC)

@Grin: note that in this case class:bicycle will not really help either: for various cyclists their opinion about traffic will differ massively. For some it is not a problem (especially one training on racing bikes, but also some touring people), for some minor traffic is 100% fine, for some both roads would be disqualified and would expect pure cycleways or at least lane/shoulder/sidewalk. And everything inbetween Mateusz Konieczny (talk) 13:39, 3 September 2022 (UTC)

@Mateusz Konieczny: Your opinion doesn't match practice. It may be the reason you're against the proposal: you're extrapolating the wrong base. That is fine, my question wasn't about opinions; I was asking what tagging combinations those people voicing their weights in believe to give equivalent, or at least close results. I even have shown you the map it's for. (Mind you, your opinion is class:bicycle:roadcycling=* based, while mine's class:bicycle:touring=*. Also obviously class:bicycle:commute=* purpose requires completely different attributes. It seems that this tagging scheme could actually even work, despite my original doubts.) --grin ✎ 16:03, 3 September 2022 (UTC)

Suggestion: making this tag applicable to points

New user here. Currently the `class:bicycle` tag is only applicable to ways and relations, but not to points. This seems like a missed opportunity, since intersections are a central aspect of cycling safety and comfort. Flagging an intersection as unsuitable for cycling can help people and navigation apps make better route choices. Thoughts?