Proposal talk:Usability

known issues and maybe improvements over smoothness

Please don't comment in this section but create a new one down there, I'll try to keep it just like a FAQ

This is not perfectly objective

This case is known, I prefere to talk about a "good guess" just like for width=* or sac_scale=* or Proposed_features/Piste_Maps piste:difficulty when you don't really have measured, or because it's a bit subjective, but still gives a rather good approximation and a good information which is easy and fast to tag.

Other alternatives to reach perfectablility are under way, much like surface=* allready tried, but the question what do I need to go there is very hard to answer objectively because of the enormous number of different criteria or number of possible vehicles.

I still think they are complement, but both cannot replace the other.

And keep in mind many users probably will just not use a too complex system, while they still have information to give of a way. Don't block them.

Why only one scale for all ?

I don't want here to replace moutain bike scales, hiking scales, roller scales, off road scales, because that would be impossible in one tag. So they are a very good complement. But remember that "a good guess" is better than nothing until someone tags the specific "moutain bike" scale. If I have gone to a level 3 track, that information allready have with it the information that a tractor or off road vehicle can use it. We don't need to wait for a special tagged scale. A routing program will be easier to use as there is no need to look at every scales and try to make a guess for the scale's vehicle not mentionned.

As a mountain bike begginer, having a track tagged with level 3, I will allready be able to take advantage of it.

share the knowlege when it's possible

perhaps improvement over key:smoothness

• tag smoothness is not a good word because it suggest it is a duplicate of surface=*. This one clearly state it is about usability
• very_bad and very_horrible where not easy to use with possible typo error and too close in goal, I have merge them with others.
• words excellent, intermediate,... are not that clear, and since this is a scale of usability, I went back with numbers easy to use and which will need refering to documentation instead of thinking too much to subjectivity.

Comments

Magic Numbers are the Spawn of the Devil

Good proposal. Usability as a concept is definitely needed - IMO smoothness sucked as it attempted to combine multiple data points into one tag (so it was never going to be an effective tag). However, I really dislike magic numbers (there's a reason in software development magic numbers are regarded as the spawn of the devil.) They are completely meaningless without reference, however using specific names at least makes the key meaningful by itself (ie: you don't have to look up what 3 means - "rollerblade" is self describing). Also, using number sequentially like proposed means you have no room for improvement in the future - you effectively have to either replace the entire tag set with a new one that has the additional values, or convert to a named tag structure where additional values can be easily inserted into the usability sequence. -- Gaffa 01:49, 6 December 2008 (UTC)

Agreed. The problem is finding suitable values. "rollerblade" isn't so good, because the value needs to include a multitude of vehicles: inline skates, traditional roller skates, skateboards, some push scooters, smaller radio-controlled cars, and probably several others that I haven't thought of. --Hawke 00:10, 7 December 2008 (UTC)

Here was the first discussion when we spotted that names where not that well chosen, but we failed to find better one Talk:Proposed_features/Smoothness#Accessibility / Usability? (we tried words related to only one transport such as "car", but it defeat the idea of "group" we have for that key. So I jumped into the devil and proposed a scale with numbers; thus solving the problem of finding words, and creating the problem of being not self-explain and hard to extend. See my thought about "numbers" that we find evil, which I think could do for scales stuff the mtb:scale : Talk:Proposed_features/mtb:scale#Choice_of_values ( Just to give an other info : I'm tagging many sac_scale as I'am a hiker, and the choosen words are a PAIN ! too long, too much typo, and I need to refer to documentation any now and then, with experience, now I can say mtb:scale numbers are easier to use than sac_scale words. Hopefully, JOSM has now them in it's presets ) Sletuffe 16:38, 7 December 2008 (UTC)

Same problem as with tracktype=*. If there are no individual words to describe a problem invent a scale! (If the scale needs an update give it a new name ;). The map/poi-editors should contain descriptions for all scales! --Phobie 07:51, 8 December 2008 (UTC)

Harvester ?

As harvesters do their work on areas and not on ways, this value shall be removed. --Lulu-Ann 13:24, 8 December 2008 (UTC)

Likely they need to get there by themselves and a using a degraded track to get as close as possible is more economical... Since they're designed to roam in the forest they're pretty much on par with atv's and trial bikes. Thought that it could be useful to mention there, but I don't mind. Alv 13:42, 8 December 2008 (UTC)

I thought of this scale as "passability by any wheeled vehicles" and harvesters cannot be "just" considered as "any forest passable". We might say they can pass anywhere by cutting trees first, but that's not my definition of "passable". So yes, to me, harvesters are in the good column and need to be there. I don't think it will hurt anything if we list any vehicles (or at least groups of vehicles ) Sletuffe 14:02, 8 December 2008 (UTC)

I think the harvester is ok as it is much like a tank. While it could go straight over fields, there are still ways which can not be passed by them. Once I saw a tank which failed on a muddy cart track.... that was fun! --Phobie 14:27, 8 December 2008 (UTC)