If you visit another area, you’d have to adapt to the unwritten criteria of the local mapper(s) and you’ll only realize this when you try to use those tracks and encounter unexpected situations. Perhaps then you’ll try to “fix” the problem. Then another mapper sees your new mappings, and “fixes” the problem by applying their own unwritten criteria. Does that make any sense?
My contributions mostly due to not wanting to have an edit war (a bit of like track documentation has seen recently) so being extra careful. I very much appreciate short and sweet wiki documentation!
No.
At this point I’m really exhausted at the level of fear, uncertainty and doubt thrown at usage of an old, widely-adopted, innocuously defined heuristic scale, used in a number of data consumers.
Let’s now go to the square one: what is the purported problem?
4 Likes
I think that wiki article matches exactly what you wanted to turn key tracktype into: Tracktype as a measure of surface firmness
1 Like
No it’s not. That smothness=excellent way might sound like a great choice for your sports car travel at a first glance, but unless you look more closely and see that it also surface=ice + incline=45, you’re going to be in for one nasty surprise.
That might be true, but IMHO tracktype doesn’t describe “overall usability” either (nor does smoothness), so there is no such clash at all. Something can be tracktype=grade2 and smoothness=horrible at the same time.
Mostly replaceable, but not entirely.
Nice tables! But yeah, it seems to be needed still - 6% difference even for least-variable surface (much less 9% for 2nd and 19% for 3rd+) seem quite significant.
What does that right part of the table represents, though?
(Left table seems to say that for surface=concrete, 94% are grade1, 4% are grade2 etc. But right is confusing: for surface=concrete there is 100% grade1, 4% grade2, 1% grade3 - so 105% ? doesn’t make sense to me, and the comment in that post " (left: % of sum / right: % of max)." doesn’t help me much)
I think it would make matter only more complex. Even now it is a mess where it is mostly a mix of 2 different attributes, and table seems to propose making 6 different attributes make single value would IMHO make it several orders of magnitude worse. Adding “That table is descriptive not prescriptive” even in big red letters wouldn’t change that much.
I think the table on the right is really confusing. It normalizes the values relative to the peak, so the column that reaches 100% represents the peak (the most frequent value), and the other columns represent the proportion of its frequency relative to the peak. Only in the table on the left is it possible to sum the values to 100% (except for rounding erors). I would recommend using only the table on the left to interpret the distribution.
1 Like
Probably not, but neither the world makes any sense. I think that is how people map in practice. It might not make any sense, but we are not going to change it by rewriting the wiki to something we wish was true and neither be changing the presets. We need to take human nature into account!
I made this change in response to a comment on the tracktype talk page from @Hufkratzer mentioning that the description of tracktype on the highway=track page was out of alignment with the tracktype=* page. My reasoning from the talk page:
I have changed the description of tracktype on the highway=track page to match the infobox on the tracktype page. I’m disappointed in myself for having made this error five years ago. The reason it happened is because at the time there was significant controversy around all highway=track being described as “unmaintained”. A major goal of that page rewrite was to remove mentions of maintenance because a road’s level of maintenance is not a good reason to choose highway=track as the primary tag. On this line, removing the mention of maintenance left tracktype described only as specifying firmness. I should have foreseen the misunderstanding this could cause. It was an unintentional oversight in a much larger rewrite of the whole page.
I figured to keep it short and be as neutral possible, it would be best to just use the same exact text as the info box description on the tracktype page. The text is right next to a link directly to the tracktype page where a longer description can be read. If all the recent discussions result in any consensus, then the info box text and this text on the highway=track page can both be changed.
2 Likes
Quoting from Verifiability (a good practice):
The concept of verifiability in OpenStreetMap essentially means that another mapper should be able to come to the same place and collect the same data (“verify” the data you have entered).
It is desirable to have objective criteria for a user’s tagging to be verifiable. This principle applies to any observable characteristic, be it numerical or descriptive.
Clearly documenting tags on the wiki always helps with verifiability. This means defining the meaning of values, and nailing down exactly how a mapper should go about measuring or deciding upon a value.
Subjective opinions, reviews or evaluations of places or businesses are not verifiable by other mappers, because other observers might have a different experience.
I believe the table in my previous post linked below contains the two fundamental pieces of information that map users most need to know to determine the best way to navigate open land and natural areas (probability and type of obstacle, and surface reliability for different modes of transport - mostly various types of motor vehicles, but also bicycles), along with two characteristics of great interest to a collaborative mapping project (data stability and verifiability).
The debate could be divided into:
- What are the best criteria in general, regardless of tradition?
- What criteria have already been used and where? Have they been used consistently in each area?
- Should different local communities try to standardize criteria globally? Or is it better to formalize the division between local communities, making further divergence easier?
- Should mappers within local communities use the same tag freely, each with different criteria?
But that does not seem to answer the question: “what is the purported problem?”
At least not in concise, easily understandable and direct way. The best I can guess from that is that you think the main problem is that “mappers are not reading enough documentation nor verifying it by running statistical queries”.
But I have a hunch that this is not the problem you had in mind.
To me, main problem is that the thing which seems to be wanted by people (answering the question: “can I drive my specific vehicle over there, and how much am I going to like it?”) is inherently subjective, and thus is problematic for verifiable mapping.
And methods for making it more objective seem to be based on needing to map too many different factors (which mapper don’t seem to particularly like) and also specifying a lot of details about personal preferences and details about the vehicle - which most users and app writers seem to dislike.
Or, “To summarise the summary of the summary: people are a problem” - as HHGTTG succinctly phrases it.
4 Likes
Deciding the best way to navigate open land and nature areas. Some users are looking for safe routes (so, the easiest ways), others are looking for challenge or fun (maybe harder/riskier ways), a few might be doing something else (like maintenance work, providing emergency services, doing some sort of research, etc.).
Not really. I am trying to find to the characteristics that are broadly useful for most map users that are also viable for mappers who are not field specialists.
Pretty much that, yes.
The same goes for smoothness. The way its problems were solved years ago was by choosing more verifiable characteristics that are actually useful for different types of users.
So, looking for some kind of class:bicycle*=* and/or mtb:scale*=* but for other (i.e. non-bicycle) vehicles (like e.g. low-profile sport cars)?
Ummm, you have not really been following tagging other threads around here lately, have you? 
smoothness recently had as many (or more? I just stopped counting at some point) threads as tracktype did.
If smoothness=* problems were “solved” years ago, I certainly hope tracktype=* can avoid that kind of “solving” 
I’ve been following this one.
I was there twelve years ago too, trying to improve its definition. Maybe I was too early. 
But let’s stick to the issue and address the problems one by one, in order of priority, to ensure our collective sanity.
The problem is that firmness alone, as depicted in the editor presets, is NOT a reliable indicator of overall track quality, and it clearly doesn’t reflect how the tag is actually used by many mappers, as this poll shows.
So why not focus on improving the presets instead?
And if no reasonable compromise can be reached, then we should seriously consider marking this tag as skunked.
Sure, that was just an reaction as to avoid smoothness-alike “solutions”, as you seemed to indicate that you like the way to one was “solved” 
So, to get back on track:
Is that the gist of what you’d like?
I think this question could be a poll. But perhaps a better question would focus on what participants think a diverse set of map users are looking for and/or need. Of course we are map users, but we’re not the only ones.
Oh. I think that tracktype is perfectly verifiable, attested by people happily using it, just like sac_scale for example. It just has a misleading documentation on the wiki:-). I think your way of thinking is way more systematic and definitory (I made up that word) than most’s people. This is not meant to be an insult, just a guess, a world would probably be a lot more orderly if more people saw it that way :-).
Many of these “tagging astronauts” are also among the biggest contributors to OSM: mapping, building tools, filing bugs, and helping new mappers. Writing them off like that feels a bit unfair.
Maybe the wiki should just be maintained by the same people who run iD, Carto, and the OSM website, they already seem quite comfortable making those decisions. 
There’s an edit disagreement on highway=track about mentioning firmness as tracktype’s primary criterion. The text “tracktype specifies roadway firmness” was stable for four years until recently removed with the rationale that detail belongs on the article about tracktype. However, omitting any mention of what tracktype classifies by makes the description uninformative to readers. I’ve restored the mention (supported by the most voted recent forum poll) while keeping the newer text mentioning classification.
Should long-standing text be removed during active community discussion about its subject?