Such as this one It's complicated! (trackype again) - #47 by Hungerburg I just closed it. Is this also biased in your opinion? It did not receive that much attention. We are a small circle here ![]()
The question is different (regarding what mappers think editor preset descriptions mean), and the options donât seem biased to me, BUT you said the following in the same post near the poll question, which may have influenced some voters:
And then this, possibly influencing some too:
As an opinion pollster, it would have been better to reserve your opinions on the matter and vote at the end. Comments are allowed, of course, but better as a separate comment, preferably not immediately. Let readers reflect freely on the matter first.
The poll is âhiddenâ in the middle of the discussion as comment #47. Surely it will receive much less attention from casual forum readers, only from those who are interested enough in the issue to read that many comments. And besides, weâve had then 4 (and now 5) long threads on the same topic in a short time, some people are probably tired and abandoned the subject.
Finally, some polls were conducted in the Tagging subsection of the forum, others in the General talk section, the readers of each are not the same, this may also influence the results. Faced with a complex consistency issue, some readers of the General talk section may reply without knowing the details, while some readers of the Tagging subsection tend to delve deeper and propose inherently prescriptive solutions.
In that case it should allow choosing multiple options at the same time.
I do not think there will ever be a poll or any other rally that will ever satisfy @ftrebien or @rhhs
PS: I first learned that tracktype (particularly) was about firmness from a post here by @bradrh â this would have never occurred to me, though in my corner of the woods, track is more than half of all highways (meant for vehicles) (and tracktype the most used tag to describe their âtypeâ or âqualityâ or âusabilityâ or whatever):
Discourse allows for that, one should click on that gear icon when creating a poll.
Iâd like to use this opportunity to raise awareness of Arrowâs impossibility theorem; here is appetizer:
Arrowâs impossibility theorem is a key result in social choice theory showing that no ranked-choice procedure for group decision-making can satisfy the requirements of rational choice. [âŚ]
So there is no need to be surprised by that, itâs proven by hard math ![]()
I remember from studying this subject years ago that the best voting systems (most resistant to strategic voting and manipulation) are score voting and approval voting (simpler and therefore more practical, but needs many votes to be robust).
In fact, if, for each criterion, people could vote whether they approve or reject their inclusion in a possible new definition of tracktype, the result would likely be socially very robust. It would still suffer from having only a small number of interested participants that may not be representative of the world at large. But the voting system could also be used on the data, just that in this case each examined way would be a vote approving (if it fits) or rejecting (if it doesnât fit) every considered criterion. Hard work, but possible, if the goal is to accurately describe mapper behaviour instead of prescribe ideal methods. In the case of approval voting, a key difference from forum polls is that the participants must either approve or reject all criteria (one by one, of course), they cannot choose to abstain about a specific criterion, while with score voting, indecision could be expressed numerically.
This poll is telling: editor presets frame tracktype around firmness, which inevitably nudges new mappers in that direction. Yet the experienced mappers who shape wiki pages and participate in these discussions clearly donât limit themselves to firmness when tagging tracktype, and the other poll results reflect that. It suggests the presets are lagging behind actual practice, not the other way around.
If a new poll is on the cards, worth chatting about the questions and multiple options here first before posting, could save us another long round of debate just to end up back at square one ![]()
A new poll with non-overlapping options should also allow the user to assign weights to the options.
(BTW any key with âtypeâ in it has this discussion built-in, because it does not specify the typology to use. track:firmness would avoid that, though I suspect mappers would still fig^H^H^Hdebate about different types of firmness.)
A new poll with non-overlapping options should also allow the user to assign weights to the options.
Well, there is option for âRanked choiceâ in Discourse multi-option voting under that gear button, which allows one to specify which option is preferable to which (but not their exact weights though)
though I suspect mappers would still fig^H^H^Hdebate about different types of firmness
We already do. In case people missed it:
Thus I would propose two tags: wet_firmness=* and dry_firmness=* instead. That way: new information could be added to the map which wasnât available before (firmness as a dependence on the weather conditions) name itself is not confusing so there is much less potential for misunderstanding people who only care about one but not the other can map just that one even without reading the wiki (which is the real risk as we see) it is quite likely that most mappers would get the meaning mostly righâŚ
A new poll with non-overlapping options should also allow the user to assign weights to the options.
Should we have a poll about what sort of poll to have
?
Jokes aside, what exactly are we hoping to learn from this new poll?
We already know that:
-
presets frame
tracktypearound firmness and tend to nudge new mappers in that direction -
(Most) experienced mappers often donât limit themselves to firmness alone and instead consider multiple dimensions
Knowing which other dimensions are considered and their relative weight could be interesting, but this likely varies significantly by region, so it may be difficult to derive a clear global definition from it.
Also, the current wiki wording says âtracktype is a measure of how well-maintained a track isâ, but the page does not define any maintenance criteria. In practice, most examples seem to classify tracks based on physical characteristics (surface structure, improvement, firmness) rather than maintenance itself.
A more practical path forward might be:
a. clarify the overall description of tracktype in the wiki
b. define a rough global interpretation that reflects common usage
c. update editor presets so they align with that description
d. allow regions or countries to document their own more specific interpretations where needed
For example, something along the lines of:
tracktypeis a rough classification of the physical condition of a track or similar unpaved road.
It typically reflects a combination of observable characteristics such as the degree of surface improvement or engineering, surface firmness, and overall usability.In practice, mappers may infer this from factors such as surface structure, smoothness, vegetation encroachment, or apparent maintenance, when these affect how usable the track is for typical vehicles.
Because road construction practices and environments vary widely around the world, interpretation of
tracktypemay differ by region, and locally documented guidance may take precedence.
overall usability
smoothness is the key that describes overall usability. We should not have two keys that describe more or less the same thing, so tracktype should not become a duplicate of smoothness and avoid overlapping with smoothness as much as possible.
We should not have two keys that describe more or less the same thing, so
tracktypeshould not become a duplicate ofsmoothnessand avoid overlapping withsmoothnessas much as possible.
Some overlap between tags is not necessarily a problem in OSM. The goal of tracktype is a rough classification, not a precise description. It can already correlate with tags like surface=* when interpreted as firmness.
In practice, many tracks with tracktype still lack surface or smoothness. Adding those later simply provides more detail and accuracy.
It is not about should or should not. Tracktype is already used that way and there does not seem to be a way to change that. Wiki should descrybe how it is used in practice.
Personally, I think it is time to start updating the wiki.
Personally, I think it is time to start updating the wiki.
Ideally, we should not start wiki-fiddling until there is common consensus on what should be changed and in which way. And it does not seem to me that weâre there yet.
I would suggest proponents of changing the wiki to apply good software engineering principles, especially âkeep commits smallâ. In other words, propose a very small change which is mostly uncontroversial, and if mostly everyone thinks it is a good idea, apply the wiki change.
Then repeat for next small (slightly more controversial) change and see if that one can has support. Rinse, repeat.
Suggesting big âlump-sumâ changes is likely to always be opposed by some group.
In practice, many tracks with
tracktypestill lacksurfaceorsmoothness. Adding those later simply provides more detail and accuracy.
It seems to me that youâre of the opinion that tracktype is just a rough classification, and that surface and smoothness which express the more or less the same thing but in more detail?
If that was a case, would you say that (in your opinion) when surface and smoothness are added, tracktype should be removed as useless low-precision duplicate?
In any case, I disagree, at least in grades 3-5. To me (as noted in all previous posts) the tracktype conveys additional information which is not present either in surface or smoothness (e.g. âmostly firmnessâ as those polls show).
IOW, one should be thinking about e.g. surface=ground + smoothness=bad when evaluating âwhat information would additional tracktype convey to meâ; and not of surface=asphalt + smoothness=good (for which trackype=grade1 is indeed redundant and might be removed/deprecated)
for which
trackype=grade1is indeed redundant and might be removed/deprecated
tracktype does seem often redundant for several surface values:
And for smoothness too:
Mostly replaceable, but not entirely. The variation in tracktype is greatest for unpaved surface values except those mentioned for grade2 in the wiki (compacted, fine_gravel and gravel; may be described as the subgroup of imported surface materials), and in the paved group thereâs wood and grass_paver with a wide range of tracktype values. wood and grass_paver again have more variable smoothness in the paved group along with concrete:plates and concrete:lanes, while in the unpaved group rock has notoriously variable smoothness, as well all mostly-soil types (sand, dirt, grass, earth) and the two unspecific values which are likely usually mostly-soil (unpaved, ground). Another notorious divide is that, for paved surfaces, smoothness varies the most in the range that affects common urban/built-area vehicles (normal cars, different types of bicycles and motorcycles, wheel chair), whereas for unpaved surfaces it varies the most in the range affecting specialized non-urban/natural-area vehicles. Of those surfaces with highly variable smoothness or tracktype, the really common ones are unpaved, ground and dirt, the rest is rarer.
So, the wiki should recommend for all highways (including tracks) mapping surface first, smoothness second, and only then other surface(/state) descriptions like tracktype, firmness, maintenance, etc. And I think applications (especially Carto) should focus on representing tracks according to surface and smoothness too, not just tracktype, as this creates an incentive to continue the use of an ill-defined tag.
Personally, I think it is time to start updating the wiki.
What could be added to the wiki at this time that would contribute to more consistent mapping practices and closer mutual understanding? No changes to the definitions, but a summary of the correlations between different criteria for illustrative purposes only, perhaps like this:
Tracktype Engineered Structure Material Presence Firmness / Deformability Maintenance Level Typical Appearance Vehicle Requirements (rough guidance) grade1 Fully engineered Hard materials dominant (asphalt, concrete, compacted gravel) Solid (non-deformable) Regular / road-like Clearly constructed road Normal passenger cars grade2 Engineered base Mixed hard + natural Mostly solid Periodic maintenance Maintained gravel with some soil Normal cars usually OK grade3 Partial structure Mixed materials Yielding (moderate deformation) Occasional Two-track with partial base Care needed, clearance helpful grade4 Minimal structure Mostly natural Soft (deforms easily) Little to none Earth track, ruts common High clearance often needed grade5 No engineered structure Natural ground only Very soft / highly deformable None Bare soil, grass, sand Off-road capable vehicles
And I think that a discussion about the usefulness, stability and verifiability of each criterion (as I tried to do earlier) is also worth including:
When considering rewriting the wiki, I think it is important to take into account not only practices but also how the resulting data will be used. Based on this summary: I would consider, for a possible redefinition definition of new tags in the wiki, how useful and stable each criterion is and whether independent mappers can verify it reliably. Hereâs what I think: Criterion Partial overlap Indicates surface reliability Indicates obstacle likelihood Mapping stability Verifiability MâŚ
does seem often redundant for several
surfacevalues:
No it isnât. Two OSM keys that âtend to indicate the same thingâ should not be consolidated because of âdata purityâ or similar - this other thread explains one reason why (it enables detection of errors).
Another is that a data consumer may only consume a small number of keys; if a key is removed then all they can determine is âunknownâ, if they donât already check the ânew oneâ. The original idea is well described here, and that is in no way redundant. By all means also tag surface. If you want to also tag firmness, well ATYL, so no problem there. But please donât try remove tags to try and get mappers and data consumers to use tags that a âwiki astronautâ has dreamt up 5 minutes ago
.


