Proposal talk:Mtb:scale

From OpenStreetMap Wiki
Jump to navigation Jump to search

What scale(s) to use?

I would suggest making two mtb scale keys: imba_scale=* and sts_scale=*. This way a trail can be classified according to both systems without conflict and without leaving one out. Alternatively, OSM should pick one and stick with it, even if it upsets a small subset of users. I'd suggest the imba_scale for that. In fact, if OSM decides to go with one or the other, it should still be referenced by name, i.e. with the imba_scale or sts_scale; similar to what is done with sac_scale=*. Creating a new hybrid scale is the worst possible option.--Hawke 18:20, 20 November 2008 (UTC)

Can you start writing the proposal somewhere and move those comments over here, while still keeping a link from this page, so we are not too much mixing things ? Sletuffe 18:22, 20 November 2008 (UTC)

Well ooops, maybe something is not clear in my mind, what is a singletrail ? and does it oppose to multipletrails ? what are you talking about ? Sletuffe 18:31, 20 November 2008 (UTC)
A singletrail is by definition of mtbikers any way where only one mtbike fits in. So you can't ride side by side. Maximum width smaller than 2m. There is no fixed width, it's rather subjective.
Well if we use two scales, then we have to define the overlap, and similarities. I think a hybrid scale is not so bad. The IMBA scale is pretty general, while the singletrail scale is restricted to singletrails. What about mtb_scale= with values easy-to-extreme (or similar - I would rather stick to numbers in any case, it's easier to remember in my opinion) and mtb_scale=S0-S5. If users want to give both value systems than they could write for example mtb_scale=S1;3 or mtb_scale=S1;intermediate. Having scales named IMBA_scale=* or sts_scale=* is even worse, because it will be harder to remember for people previously not knowing the scales. --Extremecarver 18:36, 20 November 2008 (UTC)
We don't have to define the overlap; the overlap is defined in how the scales themselves are defined.
As I see it, here are the options, in order of my preference:
  • Use only one of the two scales and call it mtb_scale. This has the advantage of being well-defined, but would bother people who are greatly attached to the other system.
  • Use both of the scales, on separate keys. This has the advantages of being well-defined, but would require extra tags, and extra understanding in programs wishing to use the data.
  • Use a hybrid/otherwise new system. This is IMO the worst option, because it's effectively creating a whole new scale, which no one at all will know.
We don't need to worry about people who don't previously know any scale, because they're learning a new scale in any case: either the STS scale, the IMBA scale, or the OSM scale.
--Hawke 19:12, 20 November 2008 (UTC)
I'll try to work something out. We need different specifications for up and downhill anyhow! Ot the same specification of the definition but different consideration wheter it's up or downhill, as in general going downhill is easier than going uphill.--Extremecarver 19:46, 20 November 2008 (UTC)

I still think it's best to leave the defining of a difficulty scale to the (relative) experts who defined the IMBA or STS scales. We don't need to create our own system just for its own sake. And either of those other scales are likely to get wider acceptance than one created at OSM. Especially if that system is "STS, but with values for 'off the scale' in either direction". Better just to simply use STS. --Hawke 16:01, 21 November 2008 (UTC)

I agree with Hawke, above. Best to use existing scales, and to state which scale is used. Climbing guidebooks have similar issues: different locations and different climbing styles use different grading systems and it is only possible to do approximate conversions. Guidebook editors will use a mix of systems to ensure that they are using the grade assigned by the expert who graded it, they also make it clear which system is being used. The guidebook author will never invent a new system. When a reader wants to climb in another country it is up to them to understand what the different grades mean. Also, even if you invent a new scale or choose one official scale, it is still useful for people to have a means to record other scales on the mapping database because they might be necessary for some mapping applications. Bruce mcadam 18:00, 25 November 2008 (UTC)

mtb_scale VS mtb_difficulty

Since I have unilateraly changed difficulty to scale, I'm re-proposing it to stick with one or the other Sletuffe 18:41, 20 November 2008 (UTC)

I'm indifferent to this. Both have Pros and Cons. —Preceding unsigned comment added by Extremecarver (talk • contribs) 19:44, 20 November 2008
"difficulty" is correct but hard to write, "scale" is unclear but easier. I think "scale" is ok if "imba" or "sts" is part of the key-name, only mtb:scale or scale:mtb would be mistakable. --Phobie 07:33, 2 December 2008 (UTC)

downhill / uphill

Only one tag for both

I'm willing to merge the mtb_scale with other scales for downhill and uphill by using a name space systeme such as :

  • mtb_scale:downhill=easy
  • mtb_scale:uphill=more_difficult

what do you think ?

Another solution might be to simplify greatly by supposing that, if it's easy to go downhill, then it is more_difficult to go uphill. Things would be more simple, but I'm not sure that we can take this shortcut Sletuffe 18:45, 20 November 2008 (UTC)

I don't think we can take that shortcut. Some ways are easy to go down, but nearly impossible to cycle up. Others are hard going up and down... Also we have to cater for mtbiking in fat regions, or for flat :sections, that might be equally challenging. While merging downhill and flat makes some sense to me, I can'think of merging uphill with flat or downhill. Regarding mtb_scale vs mtb_difficulty I'm indifferent.
We would off course define, and that might be best:
  • mtb_scale=easy (flat) (for a way that is flat),
  • mtb_scale:uphill=easy (uphill easy) + mtb_scale:downhill(moderate) (for a way that is not flat).
The difference between flat and not flat should be used from that moment where it makes significant difference.--Extremecarver 19:42, 20 November 2008 (UTC)
I start to like this one very much, I'll modify the proposal so people can say what they think Sletuffe 23:39, 20 November 2008 (UTC)

IMO, it's a very bad idea. The considerations by which we measure trail difficulty must be the same whether going up- or down-hill. e.g. "obstacles up to 10cm in diameter, loose soil, 500% grade". Those will not change based on the direction you're going, unless the trail takes a different route up vs. down. And if that's the case, you must simply tag the separate routes anyway. --Hawke 15:58, 21 November 2008 (UTC)

No the way itself won't change of course, but the importance of the objects regarding to the difficulty does. The German Singletrail-Skala which I used for mtb:scale:downhill and mtb:scale is not considering any uphill parts - they said that they see no need for it, as uphill will be largely influenced by your fitness. I stuck to the STS as well as possible, but felt the need to put in one category more for the beginning (which is thereby also closer to the mtb:scale:uphill or IMBA), and put one category on top which is "carry your bike" because we have no other way to express it.
As for the mtb:scale:uphill I tried to copy the IMBA as far as it makes sense. The problem with that IMBA scale is however in my eyes, that it is not very well thought at all. They completely leave out any difficult downhill trails from their rating. And no, why should the rating be the same for uphill and downhill, or the way categories. Any downhill rated mtb:scale:downhill grade4 or higher is in my eyes impossible for cycling up the hill. loose soil downhill doesn't matter very much, you just have to be a bit slower. Loose soil uphill at 20% is the end, because you're rear tire whill spin and you have to step of your bike. Anything steeper than 30-35% is simply not bikeable uphill, but downhill 70-100% is with some experience not so difficult. Or if there is a 2m high step going downhill a good biker will simply take it, going uphill it's unclear wheter it's possible to pass at all or not? We could try to get the values of downhill and uphill a bit closer together however.--Extremecarver 16:27, 21 November 2008 (UTC)
Hrm...It seems to me that there are different goals here: On the one hand, there's "how hard is it to use" which seems to be what you're going for, and on the other there's "what's the trail like" which is IMO more important. The latter is also why I feel that it's better to use an existing scale that some people will be familiar with, rather than creating our own. Taking your example of loose soil: If I know that, say, an STS scale of "S2" means that there's probably loose soil, I know how difficult it will be: downwards, I just need to go a bit slower, uphill it will be much more difficult. Even worse, there's the fact that there's no good way to portray "uphill" and "downhill" in OSM, unless you suggest that we should have the way always pointing uphill or downhill (bad) and have to split the way every time it changes from up to down, and vice versa (very bad). All in all, it greatly complicates the tagging for very little benefit. --Hawke 16:46, 21 November 2008 (UTC)
Well I don't think you need to define what's uphill or downhill. You should just put an overlay of SRTM lines over it, and you can easily see whether it's up or downhill. The advantage of one tag for both is that we would simply need to put mtb:scale=gradeX but we then would not know how easy or difficult it is to go up or down. mtb_scale should IMHO be a difficulty rating, where the difficulty is based on the respective surface. I first tried to put in one value to have them all. But when I used the STS scale there was simply no equivalent in the IMBA scale for going uphill, and vice versa. Try to create an alternative system based on the STS and include difficulty ratings for going uphill. I can't see this to work. There's simply too much difference. Let me give some pictured examples.
I don't see how any system based on "what's the trail like" can classify those ways in such a way that I know how it will be like mtbiking there. Personally for me with the current grading scale system I would would understand it however. For going uphill I wouldn't see any difference from 2.-4. however. On each of these ways I have to carry my bike. Did you understand te concept that for any way that declines one should give BOTH values i.e. mtb:scale:uphill=grade4 AND mtb:scale:downhill=grade2.? Or take a more extreme example. A graveled forest rode with a slope of 30%. That's a S0 or S1. However cycling that very easy way uphill is impossible. Now take a way that's just flat. It might be STS 2-3 but you may still be going in both directions, the steeper it becomes the harder it's to go up, while going level or going down you would not increase the difficulty rating.--Extremecarver 17:34, 21 November 2008 (UTC)
I'd mark them as: S3 or S4 for the first two, and S2 for the second two. IMBA scale "double-black" for the first two, and "blue square" for the latter two. The classification is not affected by whether it's up-or down-hill. You have phrases like "Stairs and flat stages are to be expected" and and "unavoidable obstacles 8 inches tall or less". This means that it will be somewhat easy going down, and quite hard going up. So you do know what it would be like mtbiking there. (IMBA scale is not as helpful in that regard though, because the stairs are unavoidable obstacles that only apply in one direction)
Hrm, thinking about this further, it strikes me that the STS and IMBA scales are kind of for totally different purposes. IMBA seems to be more geared towards mountain-bike obstacle course things (note how "TTFs" are rather a big feature of their scale, and see [1].) STS is more geared towards more natural trails. This suggests even more that it would be good to use sts_scale=* as well as imba_scale=*, because either system is poor for rating the other kind of trail. --Hawke 18:33, 21 November 2008 (UTC)
Your IMBA assessement is exactly why I'm thinking it's not really good to have one tag for both directions. From my viewpoint when looking at the map I want to know wheter I can go uphill or not, or wheter I can go down or not, and wheter this will be difficult for me (I would like that) or easy (this might become boring). I don't actually mind what the trail is made up from exactly. Seing IMBA blue square definition only I would think, yeah maybe I can still go up here. I don't think we need TTFs really. One should better make a own bikepark difficulty scale for them. I mean a TTF won't matter me in my decision wheter I can go that trail over a mountain or not, it will only exist in purposebuilt tracks, and those usually are well documented either on a webpage of the bikeparkorganiser, or even distributed on paper map to bikepark users, documented on blackboards..... TTFs are more a thing needed in a guide, not in a map. Also TTFs might be taken down in winter, changing place rather often,.... That's why I only partly copied things from IMBA for mtb:scale:uphill.
IMBA vs. STS has nothing to do with up/downhill. They're just different from each other, for rating different things. IMBA scale is for something closer to trials bike than mountain bike. Personally, I would find the IMBA scale to be nearly useless, since anything over "easy" is too difficult for me (8-inch unavoidable obstacles!?) and "TTFs" are not something I've ever used, nor do I have any interest in them. You can determine whether you can go uphill or not purely by using the STS scale -- though of course it depends on skill. S0 and S1 are probably navigable by a not-particularly-skilled mountain biker, up or down hill. S2 should be doable by a skilled rider uphill, and by a moderately-skilled rider downhill. But my point is this: You don't need a different rating on the up- and down-hill. You always know that it will be more difficult to go up than down. --Hawke 19:37, 21 November 2008 (UTC)

The sts_scale defines the difficulty of a path in flat or downhill direction (see discription on the sts website). The MTB Rider itself can decide if he can ride a S2 uphill or not by his experience with S2 ways down or by the scale itself. That would work for most. But the MTB rider must be able to find out somehow if a path goes up or downhill in the direction he wants to use. How is that do be defined (only needed if we add a uphill scale) ? The conclusion is that the sts scale or the discussion about it is somewhat independend from to be discussed uphill scale - if needed. There doesn'T seem to be one existing except the IMBA scale. About splitting up STS0 I think that doesn'T make sense. because STS0 is also a track of tracktype grade 2. http://www.singletrail-skala.de/images/s-grade/s0_3.jpg ) the picture of the different tracktype speak for themself. So something below mtb scale grade 2 would be a tracktype grade 1 (paved or cobblestone). So useless. If it is somehow possible to start the mtb scale (i would suggest: mtb_stscale instead also ) with 0 like S0 it is easier to adopt the numbers without causing confusionb etween the grade x and stsx number. --mightym 12:45, 22 November 2008 (UTC)

I suppose that every one who wants to setup a mtb map will also add contour lines, so direction of the slope might be guessed by this mean.
Your sentence "because S0 is also a track of tracktype grade 2" might be wrong, because track implies a minimum width (well it's not writen, but it is to me, since it is a track) while the sts scale seams to cover "single trails". And also because a grade2/3/4/5 tracktype is also a "kind of STS0". There are no bijection here.
we are proposing mtb:scale=value, but that's true that "scale" might not be self explanatory maybe mtb:sts_scale=value would be much consistent to sac_scale. I don't mind very much. But if we end with only one scale for mtb, I'll be happy to save 4 characters by having scale instead of sts_scale, but well, I can go over that and get more precise by adding just 4 characters Sletuffe 12:18, 22 November 2008 (UTC)
STS is not exklusive for single trails. But only STS0 could be used for highway=tracks of tracktype grade 2-5. But tracktype 2-5 automatically implies STS0 (see the linked picture). So if someone doesn't add the mtb scale, or however it is gonna be called, to any highway=track tracktype grade 2-5. It won'T care for MTB Riders cause they know it is STS0. I would also be happy if we save 4 characters. the wiki explaning the grades will be self explaining. If someone adds another scale sometime in the future he will have to use x addtional characters. ;) So conclusion: No grade below STS0 and no additional direction information --mightym 14:00, 22 November 2008 (UTC)

From a "to be simple" point of view

Looks like you've come to a level I can't help anymore since I'm a "sunday mountain biker" and will probably never tag anything after grade2. While hiking, I won't tag it either (for now) because I don't have the level to make a classification while not being on a bike. So I'll be tagging rather flat tracks or slightly steep path with mtb:scale= Then, having 2 scales for up/down will probably make me lazy and I will probably just tag : mtb:scale=grade1 since I don't see the point in tagging mtb:scale:downhill=grade1 + mtb:scale:uhill=grade1 which would be the case for 95% track/path I'll be biking on. So my point is, that if we also want to attract "sunday mountain bikers" like me, we'd better find a uniq scale for both up/down even if that leave a few information appart. And why not, create a second proposal for downhill being more specific.

So to say, something like :

  • highway=track
  • mtb:scale=grade1

AND optionnaly, if you want to be more specific add :

  • mtb:downhill:scale=grade1 (but part of another separated proposal that we could link to from this page )

Sletuffe 10:53, 22 November 2008 (UTC)

While re-reading me, I fear that my needs are not covered by this tag, but still, my point stands ! I am just remembering the flat track I recently mapped, even if not usable by a racing bike, it is obviously usable by a mtb, and that is an information I have allready put in the smoothness=bad tag, or worst, that is allready implied in a track, so I probably won't tag mtb:scale=grade1 since it is obviously the case allready. So I come to the point : maybe we are constructing a extrem scale for mtb but not a scale for my current use. (And all this is not only a question of "Me" because we have to suppose many others are in my case ) Sletuffe 11:01, 22 November 2008 (UTC)

using a full name space system

I have transformed all pages related to mtb into a "name space system" with ":" separators to group all in a mtb:XX:YY=value.

This is just an idea, don't flame me, I just thought it would be more consistent to the Ski proposal, and since I find their work very great, we could do the same. However feel free to explain me why you wouldn't like it Sletuffe 00:46, 21 November 2008 (UTC)

Choice of values

I have no good explanations about best values to use, but I'm a bit worried with gradeX (Am I too much against tracktype and it makes me think too much about it ? ) but I'm not in favor of : numbers.

  • If, for any reasons someone comes later with an in-between grade5 and grade6 we cannot do much about it (grade5.5 ?)
  • harder to remember, if editors deals with it, no problems, but since we are mostly doing it on a human way it is just a little better to remember IMHO that easy is.... well, easy ! than grade3 is easy.

But I don't have much better counter examples Sletuffe 14:01, 21 November 2008 (UTC)

I prefer gradeX because it seems to work quite well for tracktype (well in the sense that many people use it). I also though about using numbers only instead of gradeX just X. As the key is mtb:scale(:uphill/:downhil)=* it is quite understandable with a number alone I think. With tracktype=* it wasn't, because why not put tracktype=footpath etc... A scale is a scale. I would agree that if you only have easy, intermediate, advanced, expert than that makes more sense, but putting 8 different levels of difficulty into words would mean we are running out of words, and I don't like qualifiers like very. For inbetween we could eiter use grade5.5 or grade5:+ grade5:- or grade5+ grade+- (with grade5:+ or grade5:5 being much better identifiable for the renderers). With the current system of mtb_scale I think it's safe to drop mtb=yes and mtb_uphill=*. I think with numbers giving inbetween values is much easier than with words. Because what would you want to put inbetween easiest and easy? very easy? --Extremecarver 14:24, 21 November 2008 (UTC)
I knew you would say that, and that you would point me smoothness=* to talk about very_* . Just a fast word of history: I have proposed the very_ but I wasn't in favor of it. I asked english speakers for words, but english is poor as if I had used french, I would have provided the words. But we came across the same problem you are facing now in germany with mtb=yes : people have used the scale BEFORE it was approved, and for sake of simplicity we kept the original tagging in wich we included the very_* stuff. Now that I have the chance to start over, I will refuse very_* or more_* or extremly_*. Now about words or numbers, I just have repeated stupidly what has been in used in many place (smoothness, sac_scale, trail_visibility ) but I have to go over that, and think for myself. In the real world of scales things, at least in france, we use numbers for climbing, paragliding, hiking but we also use words for skiing, via-ferrata, hiking. In every case, the numbering schemas are used for high accuracy and precision, and words for simpified scales for unused people to it. In osm data base we should stick to one. And the answer comes to my mind by what I have said in smoothness=* and by what others have told me :
We can convert a high accuracy scale to a lower accuracy scale, but not the opposite
This definetly gives my answer, you are right, let's use numbers Sletuffe 14:55, 21 November 2008 (UTC)
I would choose the numbers. It is more 'universal'. If the STS scale (www.singletrail-skala.de) is adopted in principle, where should numbers start to count with in OSM? I think it makes sense to start with S0 = grade 0 (or only "0" it the word grade is not used). so that numbers of the STS are identical to the OSM numbers. --mightym 14:30, 22 November 2008 (UTC)
I'm in favor of dropping the "grade" just 0 to 7 might be enough and ok to start from 0 (and because humans are lazy) Sletuffe 00:40, 25 November 2008 (UTC)

impossibility value?

Should we include mtb:scale:uphill=8 or mtb:scale:uphill:no/unclassified to have a proposed value for a way that can't be passed with a mountainbike at all, like a place where you have to climb and use both hands and have no possibility to carry your mtb?

Mapping to sac_scale

Ouch, looks to me you are a bit extrem !! what sort of biker are you ? You wrote : "grade7" "Pushing the bike is largely impossible, the mtb has to be carried" = sac_scale="demanding_mountain_hiking" T3 and upwards. But demanding_mountain_hiking said : "exposed sites may be secured with ropes or chains, possible need to use hands for balance"

Can you still carry your bike when you need your hands for balance and you need your hand to grab ropes or chains ?

I am possibly missusing the sac_scale then, but I am tagging path with "demanding_mountain_hiking" where you definitly need both your hands to grab a chain, or stairs, or rope.

Here is a foot path I have tagged with "demanding_mountain_hiking" [2] Sletuffe 14:12, 21 November 2008 (UTC)

I myself have carried my bike up things like on that picture. If it's only for 10-20m I feel quite allright in doing so. I have once even seen someone with the mtb attached to the backpack in parts climbing up a climging grade 5 for about 300m vertical. I think the two highest grading should be: 1. impossible to bike but you still may carry your bike. 2. Carrying is impossible. I wasn't that happy about the comparison with T3, but T2 was too easy. So like T2+.
Then, you are an extrem biker, carrying a bike is not biking to my mind, and if the guys you are talking about did climb with a bike in his back, why souldn't we say grade7 is "like" "difficult_alpine_hiking" (T6) or climbing after all ? If I'm climbing with my son on my back, I wouldn't consider that this climbing wall is level 0 for babies, so no, I don't agree with you comparison to T3. Back to your very important statement about smoothness : nothing is ever impassable (for bikes), but we need to define a "stop" and that stop, is, to me whether or not you can be on your bike to pass this way or part of this way.
As of T2, I have mapped trails with it that I think no one will pass with a bike uphill, and would seriously take risks by using it downhill, but I'm not an extrem biker Sletuffe
I'm neither. But I like alpine mtbiking. Most summers I spent in the Valais, where I often go to about 3000m with my bike. I can't bike down more than mtb:downhill:grade4 myself, but I know there are people who can so I don't want to discrinimate against them. Examples for the higher up downhill categories like in the pictures [3]. Off course most mountainbiking takes place in the easier grades. Of course I said before that no way is impassable, but that was more ment for the ways regarding the smoothness discussion. I think it does make sense to say here you can still bike, here you have to carry your bike, and here you can't pass anymore because you need both hands for holding onto rock etc....
In Austria you will find most maps classifying trails as , Wirtschaftswege (highway=track), easy Wanderwege/hiking trails (highway=path , foot=designated), difficult Wanderwege/hiking trails (highway=path , foot=designated) - still no hands needed but unafraid of heights, Klettersteige (graded A-F in guides though not in maps) (fixed rope tour / via Feratta) hands are needed - but I've passed some grade A and A-B with my bike which was rather difficult, and finally Kletterrouten / climbing routes (only for very few maps climbing routes are shown) - usually you would need to fix your bike to your backpack if at all you want to have a chance to get up (graded with many different systems), howevever some climbing routes of grade I-II UIAA - [4] are so easy that you could still go downhill on a bike (or go uphill carrying your bike if your surefooted). --Extremecarver 16:27, 21 November 2008 (UTC)


I don't think we need to map to sac_scale. The SAC scale does not take into account the added difficulty of carrying your bike. Though I think the original point was just that "anything lower than SAC scale T3 can simply be bicycled by a sufficiently skilled mountain biker". No need to worry about general mapping between scales. --Hawke 15:44, 21 November 2008 (UTC)
I just put this in as comparison.

Split STS grade S0?

I see no need to split the STS grade S0 in two. If the only difference is whether it can be used by cars, then there's no need to split it here -- highway=path and highway=track should do that. --Hawke 19:51, 21 November 2008 (UTC)

Describe scale levels with words instead of numbers?

I'd prefer to describe the trail or the skill required to ride it rather than using numbers, as it is easier to memorize and remember while editing. Avoid the same problem that came with tracktype=*. -- vibrog 11:59, 26 November 2008 (UTC)

take important keywords out of the description, a scheme (flat/dh) could be:

  • 0: mtb:scale=hardpack
  • 1 =small_obstacles
  • 2 =rocky,loose
  • 3 =boulders,hairpinturns
  • 4 =steep,steps
  • 5 =very_steep,landslide
  • 6 =extreme

It is important to note that splitting of ways are discourged. This means that the relative frequency of difficult turns, obstacles and/or needed dabs are relevant in the description of these levels as well.

That would be part of the discription on the wiki. MTB riders know what an S0 or S3 is. Because most do have problems with S2 already. So those won't ride S5. Using names is difficult. SAC scale also uses numbers and words in OSM which i find confusing because i use the numbers when talking to someone.
--Mightym 14:46, 26 November 2008 (UTC)
I start agreeing with you, but the description says it quite well. But still, since we still tag values manually sometimes, I regret that we didn't used numbers Sletuffe 19:35, 26 November 2008 (UTC)
Did you read the section here already. Your concern was already spoken about: http://wiki.openstreetmap.org/index.php?title=Talk:Proposed_features/mtb:scale&curid=25773&diff=184069&oldid=183648#Choice_of_values
The main problem with words is that people make spelling mistakes. expecially noone will remember the "," etc. If you use names furthermore we will arrive with a myriad of values. Also names like loose give an impression. A scale can refer to many things, you see how difficult it already is to define the grades of the scale. If we would use names instead of numbers it would get even more complicated. Also a value like mtb:scale:5:+ wouldn't be possible. mtb:scale:5:+ is very practical however. Those who wish to only use full numbers can use full numbers only, while those who are interested in more can extract more out of it.
--Extremecarver 17:07, 26 November 2008 (UTC)
sorry, missed that. numbers are okay. now i have difficulty understanding why two extra levels are added to STS. --vibrog 18:18, 26 November 2008 (UTC)
Well as I think that I'm pretty alone in proposing two extra levels, we might as well drop them --Extremecarver 19:24, 26 November 2008 (UTC)
I find the 7 levels scale quite good. But since the STS uses 6, we could also drop one in order to perfectly fit with it Sletuffe 19:42, 26 November 2008 (UTC)
I've dropped one to better fit with the mtb:scale on which we have dropped one too. Maybe needs some more averaging to spread the levels more even? --Extremecarver 22:11, 26 November 2008 (UTC)

Merge flat scale with downhill scale ?

The actual proposal looks strange in it's downhill part, it says :

  • mtb:scale=6 if flat or
  • mtb:downhill:scale=6

and the description is obviously not flat : "Very exposed terrain with high fall hazard" and "sac_scale=alpine_hiking"

Since it looks to me every one is heading more for the downhill part, could we keep just two scales for sake of simplicity :

  • mtb:uphill:scale=X (for uphill difficulty)

and

  • mtb:scale=Y (for downhill) 0 being "flat (<15%)" and 1 being either flat but very bumpy or slope <40% and less bumpy

I agree that we will loose just a bit of information (contour line while help) but in the end does that really matters ? Then the most used scale will be easily tagged "mtb:scale=0->6" and will cover most needs, while mtb:uphill:scale=X will stay for a different uphill special information Sletuffe 18:58, 26 November 2008 (UTC)

That's also my take on it. That's why I put them besides each other in the first place. Dave, the author of the STS has written me a long mail about his view on the topic. I'll try to incorporate that as well. I'm just a bit short on time for the moment. We should define a gradient like <10% (less/more?) from which one is to use mtb:scale:uphil AND mtb:scale instead of mtb:scale only then. Is <10% acceptable for that?--Extremecarver 19:17, 26 November 2008 (UTC)


mtb:scale:uphill Considerations

I am just trying to rework the uphill scale. The problem of course is that for going uphill not only does your technique matter, but also you fitness level. Why I don't want to merge this with mtb:downhill scale is the reason that if you have an easy highway=path going at 40% up the mountain. This would be for downhill STS1 or mtb:scale:downhill=1 / mtb:scale=1. So you can't tell by the downhill scale wheter you can go up or not. The German Alpenverein has made a different classification for up and downhill by simply using the downhill classification and using different steepness/gradient values for each direction (up vs down). While this is very nice for describing, it's more difficult for putting into a map. Of course we could do that too (copy the objectives from mtb:scale and simply add a different gradient for uphill without changing any other criteria of the way. So if a way is very steep and easy, the steepness would overule the difficulty concerning the difficulty of the way. See their system here (German only, Sorry): [http://www.dav-oy.de/mtb/DAV_Oy_MTB_leistungsstufen.htm

What is the steepest gradient on can possibly cycle up on a mtb on a grippy (but unpaved) road/path? I assumed about 30% and therefore put it in at mtb:scale:uphill=5. Should we even go for 35%? I do want to have a mtb:scale:uphill that describes that it's impossible to go uphill for the largest part of the way, so that you can plan in more time for that section on tours. that's whiy I put mtb:scale:uphill=5 as impossible. Should we move that to mtb:uphill:scale=6 and spread the levels below? (I think it's best to have the same number of levels for downhill and uphill). For downhill we consider too that STS5 is largely unrideable. so mtb:scale:uphill=5 should be the equivalent to mtb:downhill:scale=6/mtb:scale=6. ]--Extremecarver 20:05, 26 November 2008 (UTC)

MTB Tours

We could use their Fitness level approach for mtb:tours. I'm not really sure how to best implement tours into the map however. Maybe it would be best to just have something like mtb:tour=N° and then having a tour portal on the wiki where people put links to their tours. The tour portal on the wiki should then just list very basic information besides the tour N°. (N° so you can easily find the tour. Alternative would be by dividing tour information on wiki by region). If you feel like having a go at this start it. I just wanted to mention it here because of giving the link to the Alpenverein Homepage under == mtb:scale:uphill Considerations == --Extremecarver 20:05, 26 November 2008 (UTC)

Using STS as mtb:scale and IMBA as mtb:scale:IMBA

The IMBA scale considers mostly artificially setup mtb trails in bikeparks, mainly for trial/north shore use, while the STS classifies ways for mtbiking mainly based on ways and trails like we can find them in mountaineous regions of Europe. Some people (especially David Werner) have told me / written me that in North America there are much fewer difficult trails for mtbiking compared to Europe, that's why artificial obstacles are more important/more widespread there. Technical alpine mountainbiking as we know it in Europe (also commonly referred to as "Transalp") is not very common in North America on the other hand. I never went Mountainbiking in North America so I can't comment on that. As The largest part of trails on the earth are not artificially "enhanced with obstacles" for mtbikers, I think it is good to use mtb:scale whithout specifing mtb:scale:STS: as default to make it simpler to use. We should nevertheless not drop IMBA scale, but just advice anyone who want to use it to tag mtb:scale:IMBA=1-5.

I have been in contact with David Werner, one of the three main authors of the Singletrailskala about this topic as well. He too proposed keeping both scales (and also not inventing anything to fit them together). His arguments are that both scales have their purpose, and that everyone should decide on which one to use depending on his needs. I think this is the best way to do too.--Extremecarver 20:22, 26 November 2008 (UTC)

I agree, this is taking a good direction now, although more clarification regarding uphill/downhill is needed i think.--vibrog 22:17, 26 November 2008 (UTC)
Excellent idea. I mostly like the proposal as it stands now, though I still see little purpose in the separation of uphill. I don't have any strong objection to it though -- I'll just not tag the uphill anywhere I tag mountain bike trails. —Preceding unsigned comment added by Hawke (talk • contribs) 22:35, 26 November 2008
Since we have two scales we need to separate them clearly! With a simple mtb:scale some users will write imba-values in there. Better use mtb:scale:sts or scale:mtb:sts instead! --Phobie 07:58, 2 December 2008 (UTC)
I don't think people will confuse the scales. The majority of trails will be graded with STS scale anyhow. Only for bikeparks with artificially setup objects, the IMBA scale applies. This is really a minority of ways.--Extremecarver 10:19, 2 December 2008 (UTC)

Announce on Mailing List ?

Sletuffe have you already announced this for RFC on the mailing list or not yet, I think we should also put a date for voting up? If not could you do it, I think this has advanced far enough for doing so. I have fear that if we don't put up a timescale movement may get lost on improving here. The questions that come up are more or less the same since some time. Otherwise we will just change and rechange everything which is not necessairily good for improving the quality.--Extremecarver 22:16, 26 November 2008 (UTC)

I have send the mail for RFC something like 5 days ago. If you think there is nothing else to add, Then I can move the whole thing to vote period, just ask me Sletuffe 23:16, 26 November 2008 (UTC)
My only last objection is the left part of the mtb:scale I have a made a remark for just before (do we need to remove the downhill word ?) (my objection is not related to going or not going to voting period, but I fear this last unclarity risks to get opposition ) Sletuffe 23:16, 26 November 2008 (UTC)
okay maybe lets discuss for 3-4 days more. And then if it looks allright announce a voting date. There are many approved features with much less discussions having taken place (though this shall not be taken as good practice example). I mean before vote takes place many things may still be adapted/changed anyhow. I think the stage is now so far, that even if people have small objections, overall they will accept it. Most objections are anyhow of the kind: For me mtb:scale:uphill is of no use (but it won't do any bad to me either) so I will only tag mtb:scale=*. I think we could keep downhill/uphill/plain scale but it needs better documentation and then it would be fine. or we kick out :downhill. From a renderer point of view this doesn't matter. From a user point of view it's noot needed but gives a bit more information (if you have no contourlines as overlay it's great for you. If you have contourlines on the map than it really shouldn't matter).--Extremecarver 23:32, 26 November 2008 (UTC)
Please see how I would feel the system to be just a bit better (see the main page for mtb:scale), I might be wrong, so please reverse my edit if you prefer, I won't mind. If that's okay for you, and for people reading it, I will move to voting period tomorrow morning. (Voting doesn't mean nothing can change, it just mean we have the hope to get some new ideas ) Sletuffe 23:53, 26 November 2008 (UTC)
That's fine I ammended the explication for a bit. I feel its good now. If noone does, by I'll try to get the translation of the STS even a bit better and work on the explication to the values of mtb:scale:uphill a bit (finetuning). By next week I'll too try to update the mtb_map and put a complete guideline on how one could adjust the rendering in here - so everyone can see an application of the tags (this topic has become quite big, so seeing how it works will make it clearer to newcomers and also motivate people on using the mtb:scale for tagging). --Extremecarver 00:46, 27 November 2008 (UTC)
I have the feeling it looks like very good now. I didn't say perfect, but hope people will help, I'm moving this page to vote Sletuffe 13:11, 27 November 2008 (UTC)

Merge Completed Template ?

I think we should put a Merge completed on some of those "Merge Discussed" pages. There have been no objections on any of the merges so we should exchange the template. I can't find any template for that however--Extremecarver 23:01, 26 November 2008 (UTC)

I will just remove the "merge" templates, and set Proposed features/IMBA Trail Difficulty Rating to abandonned and give a link to here Sletuffe 23:18, 26 November 2008 (UTC)

Voting objections 1

I oppose this proposal. : I like the idea, but think it needs modification. Sorry not to have come across this page before the voting stage, but I am not happy with the gradients or the weighting towards the extreme. It seems like a rating for DH courses, not general riding. The gradients in the IMBA are far more sensible. Shouldn't S0 have a max gradient, and isn't 39% a rather steep for S1? For the English that's 1/2.5. Maybe I'm a wuss, but for XC I'd call that uncomfortably steep where there is loose ground, and certainly not "basic driving (riding?) skills." Perhaps the sceme is ok for alpine riding, but for places like the UK the scale seems too extreme to be useful. I don't think it has enough granularity at the easy end. Beginners are those who will find ratings most useful I think. After all, if most riders can't ride S5, how much of it is actually going to get mapped and tagged? At least if the scale is weighted towards the easier, higher numbers can be used for more extreme, but it seems stupid to go below zero for easier ratings. I would like to be able to plan rides with relatively inexperienced friends using the lower grades of this system. Unless we want to put off newcomers to the sport, I don't think that the gradings are right. Daveemtb 08:50, 28 November 2008 (UTC)

The gradients (inclination) in IMBA are primarily for bikeparks. It's clear that a path going up 40% will be really difficult, if not impossible to anyone to mtb up. Therefore we have the additional mtb:scale:uphill. Granularity at the easy end is given by other tags like highway=track, highway=path, smoothness=, tracktype=.... Maybe we should propose to use mtb:scale:0:- or 0:0-9 for further seperation. The singletrail scale is the most used trail classification system in Europe, if not worldwide (by the number of trails described with it). Also please read through to comments here on the talk: section. Your objection came up already. I had originally splitted mtb:scale=0 into two levels, but there were several people against it so I took it out again. The reason is, that other tags should be sufficiently good for that case. Essentially I think there is noone that has any problem to mtb on mtb:scale=0. This is terrain that you can ride with a trekking bike too - but using a mtb is more appropriate and comforable. Also the surface key will help you here. The mtb:scale should cover that cases that simply cannot sufficiently described by other keys. Extremecarver 10:35, 28 November 2008 (UTC)
Spelling mistakes are open for correction 24/7. Native speakers are very welcome. ;) About the scale. Not all things have to be fullfilled for a certain 'grade'. For example a S2 trail could be <40% (normally S1 or even S0), but it has easy hairpins, so it is rated as S2. >Different things can make a trail difficult. Not all of them combined are needed. In the discussion above we discussed about splitting up S0 as extremcarver stated above, but this will lead to confusion caused by different numbers. So this was dropped. In between steps could identified with a "+" or "-" for example S1+ or S3-. This is also used by the STS scale. I believe we simply 'forgot' this in the large discussion above. It will be option for those like you who want to have inbetween steps. but the general scale will be kept easy to understand by the clear steps of 6 grades. Every beginner (those new to the scale) can rate a path by easy identifierng a grade. More experienced 'Riders' can rate in between if really needed. --Mightym 11:23, 28 November 2008 (UTC)
You may also use key:incline if you think that the inclines given here do not correspond to what you can mtb down/up. I have added it to Mountainbike --Extremecarver 14:24, 28 November 2008 (UTC)
I understand the nead for easy grade, but as I have mentionned earlier, smoothness=* can handle them I think. And that's what I am tagging. The big advantage, is that if some one doesn't care about mtb and tag a track with smoothness=bad I, as a "easy rider" will know I can use that track without problems. mtb:scale look good to me as being extrem. mtb:scale if for mountain bike only, when a treking bike can use it or a car can use it, it should go somewhere else Sletuffe 17:02, 28 November 2008 (UTC)

Voting objections 2

I object the name mtb:scale=*. At least it should be scale:mtb=* but "severity" would be even better.
Example: severity:mtb:sts=2 severity:mtb:sts:up=3 severity:mtb:imba=2 severity:motorcycle=3
With severity=mtb:* you could put all sub-keys into one key and the severity-key could also be used for other vehicles. Probably this would make parsing the OSM-database easier.
Example: severity=mtb:sts:2;mtb:sts:up:3;mtb:imba:2;motorcycle:3 --Phobie

An that would cause one heck of a mess for the renderers. Are you working on any renderers? We're not mapping for the renderers, but when creating such things we should at least try to keep it simple to implement. I have implemented the proposal as it is already for mkgmap. I'll upload it to mkgmap trunk by tomorrow. I still need to do some little testing, but in principle it works allright. Given your severity=blablub thing this would mess up everything. that's why multiple key usage will be stopped AFAIK. So things like highway=footway;bicycleway will not be possbible in future anymore. —Preceding unsigned comment added by Extremecarver (talk • contribs) 22:40, 30 November 2008
I agree with your comments. Even if solutions to "cut" values or key values are possible, they are quite hard to deal with at a programmer side, we should keep them as low as possible or else it would require an harder work and limit possible use of osm data to the "happy few" that have strong developpement power Sletuffe
What do you mean with "that"? I made two different suggestions. I am working with ElementTree and regex not with renderers. If parsing of my second suggestion makes problems, my first one still stands. Writing "blablub" in this context is offensive. AFAIK they remove the multiple usage of the same key i.e. highway=footway AND highway=bicycleway in one way. Merkaartor supports this feature JOSM and Potlach not. What about severity being a better name than scale? --Phobie 09:38, 1 December 2008 (UTC)
AFAIK highway=footway plus highway=bicycleway for the same way is the same as highway=footway;bicycleway. Both is pretty hard for renderers to do (would need multiple parsing or complex arguments). Sorry for Blablub. I simply think that behind the "=" there should only be one value, and not several. As for severity against scale, I do prefer scale. I could do with difficulty but that is longer than scale, so if the grading is based on a scale (which it is), I prefer to tag mtb:scale instead of mtb:difficulty . Under sever I associate bad weather, bad conditions, something temporary, but not something permanent. Also we have sac_scale and not sac_severity.--Extremecarver 10:32, 1 December 2008 (UTC)
It means the same, but it is not the same in the database. The first will be disallowed with api 0.6 the second will be still possible. For parsers in the renderers, I don't know them but from what you say they seem to be very limited. I do not like scale because a scale can stand for anything. Difficulty and severity are more specific. I'm not a native speaker and the translators said severity fits perfectly. Since the key without sts or imba is a estimated sts-value, we could also mention that:
with
or
Does the order name:mtb vs. mtb:name matter for you? If yes, why? --Phobie 11:33, 1 December 2008 (UTC)
To "*estimated":
As we know it's an approximation, why should we be forced to write down one more section (:estimated). Tags should be kept simple and short, otherwise they won't be accepted, and the chance for spelling errors increases many times. Same for difficulty versus severity vs scale. Scale is simply the easiest to write down and already used for sac_scale. Talk:Proposed_features/mtb:scale#Using_STS_as_mtb:scale_and_IMBA_as_mtb:scale:IMBA. I prefer scale over difficulty because scales are mostly expressed by number (i.e. 0 to 5) while difficulty is rather subjective not based on a measure for me. Some people might simply tag mtb:difficulty=extremely_difficult because for them it is. There is no definition what extremely_difficult is however. Knowing we use a scale with numbers, we do have reduced that subjectivity a fair bit. --Extremecarver 12:07, 1 December 2008 (UTC)
Didn't know that there are no sts or imba maps jet. So remove source and estimated. --Phobie 07:19, 2 December 2008 (UTC)
There are some gps-track portals where people are asked to describte their uploaded mtb routes (not single ways) using the STS scale. Also in forums and on other trail description guides or material for mtb guides of the German Mountainering Club (DAV), the STS scale is used. It is allways an estimation however. So it's well possible that there are differing views on what scale a way is exactly. This proposal however for the first time incorporates the STS into a map on a way level description instead of a description for a mtb-tour you publish somewhere and say majority of trails is STS1, after the mountain hut XY on the trail XYZ there are 500m of the STS=3 however......Nevertheless including source or estimated as noted makes no sense.--Extremecarver 10:27, 2 December 2008 (UTC)
To "Does order matter?":
Yes it does. If you look on mountainbike you will see that there are several proposals concerning mountainbikers. I as a mtbiker can remember much more easily that everything which starts with "mtb:" concerns me. So maybe all of the 4 tags I want to implement start with mtb:, so easier to remember. I don't think anyone goes out and tries to put in 4 different methods to define difficulty, most people map what they are intested in, they don't tag everything that is possible for a way just for the sake of having the way show every possible attribute. Therefore it's IMHO easier to work with. I know every tag starts with mtb: and I only have to remember scale;description;type; --Extremecarver 12:07, 1 December 2008 (UTC)
I do not want things hard to be remember or to be inconsistent. I think all orders should be changed: difficulty:mtb=* info:mtb=* tracktype:mtb=*. From the view of a mountain-biker it might be good to start with mtb but from the view of database managing all those access=*-keys should never come first. --Phobie 07:11, 2 December 2008 (UTC)
I don't think there are difficulty scales for most vehicles. I think mountain bike is a rare case. Ski also uses a difficulty scale, but that's already documented elsewhere -- and wouldn't really work at severity:ski IMO. --Hawke 19:14, 30 November 2008 (UTC)
Every vehicle/way combination has a severity! Think about rollerblades, racing-bikes and cars on muddy roads. See Key:smoothness --Phobie 09:43, 1 December 2008 (UTC)
We don't need the 'estimated' thing. Everyone using the mtb:scale automatically estimates himself. There is no "STS scale commitee" who has to approve each mappers estimation. I prefer scale. It is as simple as possible. Andother reason is that wording is compareable to sac_scale. Everything related to mtb only can be found under "mtb". I have never seen any offical rolerblade or bike scales. I both caes i think the normal paved and other already used keys fit. --Mightym 14:28, 1 December 2008 (UTC)
Which other keys do you mean? surface=* is definitely not enough! --Phobie 08:53, 2 December 2008 (UTC)
Most modes of transport do not have difficulty/severity/etc. scales that are already in common usage. Hiking, mountain biking, and skiing do (SAC and STS for the first two; not sure the name of the third). --Hawke 15:35, 1 December 2008 (UTC)
Users created smoothness=* because a scale is needed for several vehicles. For routing-software it would be very useful to have a difficulty scale for all of them. --Phobie 08:05, 2 December 2008 (UTC)
So the motto is "universal peace".... ;) I would say, lets start with the suggested mtb scales in the proposal (i know sac_Scale is already prsent). One scale for all does not work, we came to that conclusion in a long discussion you can follow also. Only a very rough scale like smoothness. And that was what i meant. this 'scale', or things line incline, surface is already enough for normal motorbike tours and the other sports you mentioned. If a sport has its own scale that scale can be used addtionally. And that what we are discussion about here not "universal peace". --Mightym 10:46, 3 December 2008 (UTC)
To "Does order matter?":
Very Slightly. If all gradings are stuck as Scale/Difficulty:(means of travel):(source) then it's easy to manage in editors. All scales would be in a row. If everything that has 'mtb' concerns you, search for mtb... Ben 13:40, 10 December 2008 (UTC)
I'd like to add that if you watch at the Proposed features/Piste Maps proposal, it was piste:difficulty, I think those guys have allready deeply thought of the case, and maybe we should stay consistent to it and construct the mtb: just like they did with piste: (I don't say this is a proof of this being better than that, but since it isn't such a big deal, I would prefere to stay consistent )Sletuffe 09:50, 16 December 2008 (UTC)
So the voting process is now open for quite a while and input slowed down. I could agree to mtb:scale:sts also to make it 'equal' to mtb:scale:imba and mtb:scale:uphill. As suggestest by Phobie in the voting list. Would be fine to make the tags final now/soon and rework the wiki pages ready for usage for everyone including the german translation. So would be fine if we can "start". everyday 'wasted' is a day someone tags without using the scales (?).

Voting objections 3

It is proposed to use uphill and perhaps downhill as subkeys. But there is a need to tell the parsing-software which direction is up und which down! How to solve this? --Phobie 07:37, 2 December 2008 (UTC)

As long as there are no objections against it, one could propose that all ways should be drawn downwards. As for mountainbiking SRTM contourlines are neccessary on a map anyhow, it should never be a question what direction is up and what direction is down. (SRTM heighlines are not exact enough to really tell how steep the way is, but enough to know whether a way goes up or down.--Extremecarver 09:26, 2 December 2008 (UTC)
If a way goes up and down there is no sense in tagging uphill separately, because a person driving through needs to go uphill and therefore the uphill-scale should be used for the whole way! In the thinking of vectors on the OSM-database we should better use something like scale:mtb:sts:opposite_direction=*. --Phobie 08:13, 6 December 2008 (UTC)
I don't think that is even necessary to take care to draw the way downhill or uphill (think of the hard work if a trail goes down and up and down...) That scale is not intended for routing I think. I just can't imagine some one say his GPS : my skill is S4, please tell me where to go. This looks much like a tool for trail planning, and people are requested to use their brain. Seeing an uphill scale, will give a clue for people who want to know if they can ride uphill, but if there are no uphill scale, I assume they will use contours to define wether it is downhill or uphill. Sletuffe 14:50, 2 December 2008 (UTC)
Trail planning can be done with the help of routing software! "show me all ways from x to y with scale:mtb:sts below z" --Phobie 08:03, 6 December 2008 (UTC)


mtb:scale/smoothness

  • Query: maybe people following this for longer have cleared this one up.

If something is added as smoothness(or whatever the key becomes)= and graded as suitable for a mountain bike and anything above (e.g tank/foot etc.) then what mtb:scale would this be assuming. Level 0 seems right to me. This would then mean a level 5 MTB run would be the hardness smoothness grade (only suitable on foot/impassable) level 5 mtb. The contradiction would be justified by smoothness being considerate of the 'normal' mountain bike rider; normal as opposed to specialised. Ben 13:48, 10 December 2008 (UTC)

I wouldn't assume anything. Both are independant values. Assume an unpaved street going up 60%. Some very strong 4WD could still go uphill, but we have to classify it already more difficult (impossible uphill, difficult downhill). On the other hand a very tight and flat path would be easy on a mtb, but impassable with 4 wheel vehicles. Smoothness gives us some additional info however.--Extremecarver 18:57, 10 December 2008 (UTC)
We need to be able to assume, as route planners arn't going to know any better, so if it isn't stated then assumptions would need to be made, and we're not going to state absolutely everything. If the hardest bike routes are set at being usable by a MTB rider, then a 4x4 would be assumed, and in this case incorrectly. The issue, which your example demonstrates, is that in some cases a 4x4 is more capable over x terrain and other times a mountain bike. If smoothness(usability) were to be a hierarchy, with the weekest probable means of transport likely to complete a route stated, then the levels at which these means of transport are graded needs some thought. So would all but the grade of track rated 'zero' class an unsuitable for a MTB, and therefore not get used by a route planner looking for a normal route for a MTB rider, and only doing so if you stated specifically that you wish to also include higher grades in the route, beyond the recommended level for MTB riders which is made clear in the smoothness/usability tag? So there independent, yes, but as far as I can understand, if the above isn't made clear then smoothness/usability would fail over =yes tags. Ben 19:51, 10 December 2008 (UTC)
There is a proposal to rework smoothness. At the moment talking about autorouting for mtbs is still very far off. And no, we definitely don't need to assume anything. Both are completely independant values. If route planners will assume somethings, it's their game no ours. Smoothness will allways be dropped if more specialised values exist. Sac_scale is also in no way directly comparable to smoothness and for hikers much more important. Smoothness is good in that it is independant of specialised use. Before we can start that discussion IMHO at least 6 month have to pass. And no, I don't think once it comes, routing should look at smoothness at all, if mtb:scale is used. On the other hand, if no mtb:scale is given, maybe some complex rules will have to be setup. At the moment not even drawing in the mtb:scale into maps is easily possible. I hope that with mkgmap 804 style branch some new possibilites have come up, which I'll try this evening. For sure is, autorouting on Garmin units will not work for MTBs. Maybe one cane fake Garmin by creating a mtb map, where you assing mtb:scale=0 as 0x01 motorway, mtb:scale=1 as primary roads, etc... but there will have to be much tweaking and doing things creatively to achieve. As for other routing engines, completely new routing engines will have to be written / adapted for mountainbikes.--Extremecarver 22:11, 10 December 2008 (UTC)
I think we're drifting from the original question. I strongly disagree with a multiple things in that reply, but the original question has been missed. These two tags are not completely independent. In the end their both stating what can go down a route. While one is broadly looking at means of transport, and one is looking at skill levels on one means of transport, it seems that there will be an issue by 2 contradicting bits of information being added, unless there is an agreed usability level that is equivalent to the lowest graded MTB run. The overall ability of someone taking any route is always going to be the combined abilities of their transport choice, and their own ability. Obviously these are all in the proposed stages but inevitably something will come or evolve for both of the issues their trying to solve. Ben 00:31, 11 December 2008 (UTC)
With smoothness (and addtional width) you can give a rough impression of the way/path that gives feedback to everyone. With mtb:scale:sts etc. you get specific information for a certain user type. in this case MTB. It is not possible to fit everything into one scale (i said that multiple times in this discussion). If there is a specific routing software for each user (4WD car, hiking, mtb,...) it is the routing softwares job. I don't know where there is a reason to discuss about. --Mightym 19:37, 15 December 2008 (UTC)
Ben. You have to use each scale itself (and the defintions in it of each step) instead of comparing the scale and try to make 'virtually' one out them. There might indeed be a insection. For example (mtb:scale:sts "comparable to" SAC_Scale) S0 and S1 have no equivalent in the sac_scale. S2/T1, S3/T2, S4/ T3, S5/T4, T5 and T6 are impassable for MTB, so when tagged as T5 or T6 by the sac_Scale a renderer would draw that for mtb specific reason as impassable. But thats up to the renderer. BUT IMPORTANT: Not in every cases a T1 is automatically S2 (or a T2 a S3. So this is only just a 'guideline', it doesn'T replaces using the scales itself. For example the imba scale is impossible to compare to the sts scale, because they rate totally different things. --Mightym 20:13, 15 December 2008 (UTC)
Wasn't saying there is any 'replacement', or 'making one out of them' Just saying there is an opening for the adding of contradictory data. I'll leave it at that, I don't object to this proposal, and shall use this tag when necessary. Ben 12:32, 22 December 2008 (UTC)

New Zealand grading system

NZ has a grading system that is similar, but not identical to the abovementioned US and Euro centric ones.

AFAIK it originated in the Kennett brothers "bible" Classic New Zealand Mountain Bike Rides and listed on website

Now essentially adopted by (government) Dept of Conservation 1 with addition of symbols and descriptive names

  • Beginner/Grade 1: Fairly flat, wide, smooth track or gravel road.
  • Easy/Grade 2: Mostly flat with some gentle climbs on smooth track with easily avoidable obstacles such as rocks and potholes.
  • Intermediate/Grade 3: Steep slopes and/or avoidable obstacles possibly on narrow track and/or with poor traction. There may be exposure at the track’s outside edge.
  • Advanced/Grade 4: A mixture of long, steep climbs, narrow track, poor traction and obstacles that are difficult to avoid or jump over. Generally exposed at the track’s outside edge. Most riders will find some sections easier to walk.
  • Expert/Grade 5: Technically challenging. Giant climbs, narrow track and numerous hazards including dangerous drop-offs, sharp corners and difficult obstacles. Expect walking and possibly bike carrying.
  • Extreme/Grade 6: Downhill/free ride specific tracks. Extremely steep sections with large drop-offs and other unavoidable obstacles. May include man made structures and jumps.

How to tag NZ grades?

  1. As listed mtb:scale:nz=1
  2. Translate into STS scale - could be confusing in NZ context. NZ 1..6 -> STS 0..4 ??
  3. Translate into IMBA scale - could be confusing in NZ context. NZ 1..6 -> IMBA 0..4 ??
Translation will not work. You should get in contact with other NZ mountainbikers and decide which system best to use. If NZ mountainbikers are accustomed to the beforementioned scale, probabely it's the easiest to just use it!--Extremecarver 10:54, 8 January 2009 (UTC)

Applicability to highway=footway

  • why not to apply to highway=footway too? in many coutry highway=footway it's the most used way to tag offroad singletrak. --Jinx1971 23:16, 30 January 2009 (UTC)
    • If in your country the tagging guidelines are not that any way that is not only for pedestrians can also be classified as footway, then of course you can use it. Better would be changing the footway to highway=path AND foot=designated.

IBC scale

Another interesting classification scheme: http://www.mtb-news.de/forum/showthread.php?t=117048
How about allowing mtb:scale:ibc=1-10? — vibrog 15:37, 5 April 2009 (UTC) The IBC scale was dropped in favor of the singletrail scale. You would only confuse everyone by using it. Read through page 6 and notice that everyone only talks about the singletrail scale. Of course noone hinders you to use it. On the IBC Forums you will see that the Singletrail scale (so mtb:scale=0-5) is predominant. The creators of the IBC scale were heavily involved in the singletrail scale.--Extremecarver 19:29, 5 April 2009 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Mtb:scale&oldid=2515842"