<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Verdana">I do belief that creating a new tag or
two-tier system for this could be very useful. Both to express
usability by mappers as for data consumers.<br>
Again I am trying to look at this on a global scale, relying on
local experience.</font></p>
<p><font face="Verdana">Paved and unpaved, neither does any of these
values say or provide conclusive information about the
drive-ability of a road. Smoothness=* does in some way. Neither
does it provide for easy tagging changing road conditions due to
weather conditions, and or related issues regarding run-off,
drainage etc... of roads.</font></p>
<p><font face="Verdana">F.i. many of the roads in Africa are unpaved
but have a base layer of compacted ground and a top layer of
murram. Murram, in dry conditions is often as smooth and
drivable as asphalt, it turns however into a slide hazard, for
all road users, when wet. We consider it as a kind of pavement.
Not ground, although it is a natural material mix abundantly
available. It is also often mixed with gravel, to counteract the
hazards in wet conditions. Paved also doesn't mean sealed. </font><font
face="Verdana"><font face="Verdana">Same for asphalt. Many
asphalt roads worldwide become more a hazard during rainy
conditions. Forming of tracks, poor drainage, water freezing
on the surface etc... </font>Asphalt is also a mix of
different materials, and their mix is adopted to make the top
layer semi-permeable, or more open to cope with wet or freezing
conditions. In many cases asphalt can not be called a seal.
Same goes for other "pavements". All very useful data, not so
difficult to obtain on the ground, and very useful to data
consumers targetting different purposes or audiences like
cyclists, hikers etc... all could benefit from it.<br>
<br>
I am not saying a two tier system is the optimal solution here,
but it deserves us thinking about a new tag or tagging to
provide more conclusive and simple tags instead of making the
existing data or structures more ambiguous and complicated
(unusable in the long term) for data consumers and renderers
alike.</font><br>
</p>
<div class="moz-cite-prefix">On 05/03/2021 13:42, Mateusz Konieczny
via Tagging wrote:<br>
</div>
<blockquote type="cite" cite="mid:MV0yuTT--3-2@tutanota.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Mar 5, 2021, 11:06 by <a class="moz-txt-link-abbreviated" href="mailto:marc_marc@mailo.com">marc_marc@mailo.com</a>:<br>
</div>
<blockquote class="tutanota_quote" style="border-left: 1px solid
#93A3B8; padding-left: 10px; margin-left: 5px;">
<div>Le 05.03.21 à 10:50, Richard Fairhurst a écrit :<br>
</div>
<blockquote>You really do not need two keys to express this.<br>
</blockquote>
<div><br>
</div>
<div>I agree, but the fact that each tool has to build a list of
values<br>
</div>
<div>and then classify them into main groups is not ideal
either.<br>
</div>
</blockquote>
<div>Why? Different tools will have different needs and<br>
</div>
<div>data consumers will need to make their own decisions.<br>
</div>
<div><br>
</div>
<div>For example surface=grass_paver is horrible for bicycles and
fine for cars,<br>
</div>
<div>surface=sand is bad for cars and bicycles, fine or maybe
preferable<br>
</div>
<div>for hikers.<br>
</div>
<blockquote class="tutanota_quote" style="border-left: 1px solid
#93A3B8; padding-left: 10px; margin-left: 5px;">
<div>you have made such a list, others also make such a list and
with each<br>
</div>
<div>new value, you have to make a new piece of code to say that
the new<br>
</div>
<div>"ultra precise" value is in practice in category A or B<br>
</div>
</blockquote>
<div>What is preferable to taking classification from some
external dataset.<br>
</div>
<blockquote class="tutanota_quote" style="border-left: 1px solid
#93A3B8; padding-left: 10px; margin-left: 5px;">
<div>at least there should be a way to build this list in a
collaborative way<br>
</div>
<div>and easily readable by a program, this would allow to build
a<br>
</div>
<div>preprocessor to group all the ultra detailed values into
larger groups<br>
</div>
<div>for those who do not need to make the difference between a
paving_stone<br>
</div>
<div>variant A and variant B.<br>
</div>
</blockquote>
<div>That would be far more complex.<br>
</div>
<div><br>
</div>
<div>BTW, you may use <a
href="https://wiki.openstreetmap.org/wiki/Data_items"
moz-do-not-send="true">https://wiki.openstreetmap.org/wiki/Data_items</a><br>
</div>
<div>for that.<br>
</div>
<div><br>
</div>
<div>But it would not be not useful at least in cases known to me.<br>
</div>
<div>For any place where I processed surface values I would prefer<br>
</div>
<div>a manually curated list.<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Tagging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
</body>
</html>