[Tagging] Tags useful for rendering of roads in poor conditions

Fernando Trebien fernando.trebien at gmail.com
Fri Jan 3 23:10:01 UTC 2014

So, the idea of unifying the classification systems is not popular.
I'll leave you with one last thought, and then I won't insist anymore.

To challenge that idea, I decided to plot my own subjective
"trafficability" values (what I think each of these tags mean for
choosing a way based on the description of its surface) for each of
these new classes that I proposed. I'll repeat, "subjective" values. I
arrived at them asking myself: if I had one 100km way in perfect
conditions and a shortcut to the same destination with this other
particular surface/relief, how long could the latter be to remain a
better choice than the former? Here's what I answered to myself:

Of course, each person would have a different parameter set and
routing developers should query many people and average these results
out. To note: I had little doubt about what the actual value would be
for each class, except in one situation: the new class 5 +
surface=gravel + vehicles with thin tires (wheelchairs and bikes).
Maybe gravel should not be in that class, or maybe the physics of
gravel would require an extra tag.

One remarkable thing: the largest change happens from class 3 to 4,
and continues from 4 to 5. This is where I believe our discussion on
visually distinguishing unpaved/unsealed ways is focused. What changes
there? Several values of the surface tag, the wheelchair tag (from yes
to limited), the smoothness tag (from intermediate to bad) and the
tracktype tag (from grade1 to grade2). So, for me, the semantic of any
of these tags could be used to achieve what I want for the new
rendering style.

Again, these are all my own subjective conjectures and are just an
extension of my previous arguments. I would be quite curious to see
how each one here would plot that graph, and whether you'd feel unsure
on how to assign values to each of these classes (if you read the
description of the similar tags first).

On Fri, Jan 3, 2014 at 8:24 PM, Fernando Trebien
<fernando.trebien at gmail.com> wrote:
> +1 Smoothness is not necessarily more descriptive than tracktype, and
> it may actually produce more disagreement if users skip reading what's
> on the wiki.
> However, I like that "smoothness" tries harder to cover more transit
> types. As the table I posted a while ago shows, both provide more
> detail on surface quality in different situations, with tracktype
> providing more detail on unpaved ways and smoothness providing more
> detail on paved ways.
> On Fri, Jan 3, 2014 at 7:15 PM, Janko Mihelić <janjko at gmail.com> wrote:
>> 2014/1/3 Pieren <pieren3 at gmail.com>
>>> On Fri, Jan 3, 2014 at 1:05 PM, Janko Mihelić <janjko at gmail.com> wrote:
>>> > but in the long run it's going to give us less precise
>>> > maps.
>>> If you like precise maps, how can you recommend "smoothness" ? what is
>>> precise between "smoothness=intermediate" (city bike) and
>>> "smoothness=good" (racing bike) ?
>> I agree those are not very good values, but how is that not better than
>> tracktype? If we have a horribly rugged paved road, is that grade1 or
>> grade3? What if we have a very smooth grass road in some posh golf club? If
>> we went with the wiki, that should be grade5.
>> The question is, what is smoothness? I think we should define it internally
>> with a number of millimeters of the average hole in the road. That is just
>> so we have internal consensus of what is good, bad, horrible etc.
>> For the average mapper, I think the best solution is to have a picture of
>> most surfaces and their corresponding smoothnesses. So a picture of
>> excellent asphalt, a picture of good asphalt,... a picture of intermediate
>> ground,... and a picture of horrible sand. And everything in between.
>> Actually you don't need all combinations because some of them don't make
>> sense. Those pictures would then show up in all editors when you search for
>> the surface you need.
>> Janko
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> --
> Fernando Trebien
> +55 (51) 9962-5409
> "The speed of computer chips doubles every 18 months." (Moore's law)
> "The speed of software halves every 18 months." (Gates' law)

Fernando Trebien
+55 (51) 9962-5409

"The speed of computer chips doubles every 18 months." (Moore's law)
"The speed of software halves every 18 months." (Gates' law)

More information about the Tagging mailing list