Poll (hopefully better): Tracktype never dies!

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 :slight_smile:

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.

1 Like

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):

1 Like

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 :smiling_face:

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.

1 Like

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 :grinning_face_with_smiling_eyes:

1 Like

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.)

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)

We already do. In case people missed it:

1 Like

Should we have a poll about what sort of poll to have :winking_face_with_tongue: ?

9 Likes

Jokes aside, what exactly are we hoping to learn from this new poll?

We already know that:

  • presets frame tracktype around 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:

tracktype is 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 tracktype may differ by region, and locally documented guidance may take precedence.

2 Likes

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.

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.

1 Like

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.

2 Likes

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.

1 Like

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)

1 Like

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.

2 Likes

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:

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:

1 Like

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 :smiley: .

2 Likes