<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Verdana">Thank you Paul, for sure, what we have in
most cases, if you are creative allows us to tag simple, but
also detailed and sometimes complex situations.<br>
I think however there is a need to bring more clarity in the
whole concept to serve several purposes:<br>
</font>1. Avoid tagging schemes that promote data to be repeated.
Over time data consistency gets jeopardised, it creates confusion
amongst common users but also at specialised use cases, like I
can't find any routing application that uses OSM's lane tagging
schemes for reserved lanes, yet, is that caused by data
inconsistencies, overlapping tagging schemes, or just a functional
option not yet provided by the routing application, I don't know
but duplicating data surely contributes to that issue. It's like
normalising a database scheme to avoid all kinds of confusion and
a "mess", our data scheme is not normalised.<br>
</p>
<p>2. Avoid using values that don't add any clarification to the
concept. I refer to your advise to use access:lanes=no|yes|yes.
Yes or no doesn't add anything here to the already psv:lanes
tagging. The "no" value means what, no psv's, no bicycles, no
motorcycles ? It needs to be related to a specific access value,
like psv, hov etc.... So one could see value in
access:lanes=psv|yes|yes, yet, then my question would be again
what does this add to the already psv:lanes which defines clearly
the access, the location and the number.</p>
<p>So in my opinion their is an opportunity and a need to take some
actions here, not to normalise completely (that is too big to do
in one step, needs a master plan) or promote one classification
principle in favour of another but at least to deprecate tagging
that contains duplicate data or non-deterministic values.<br>
In this particular case: <br>
</p>
<p>A. clarify lanes=* does count all the lanes (including dedicated)
of the way where the tag is used (supports both highways where
lanes are mapped on a single way as where lanes are mapped as
single drivelanes with each there own way);</p>
<p>B. consider promoting specific access lane tagging schemes like
psv:lanes or access:lanes but deprecate all the separate lane
counting tags.</p>
<p>C. Discourage the use of general values as yes/no in the access
lane tagging schemes that don't refer to a specific access
category.</p>
<p>Maybe a small clarification to normalisation: normalisation
should not mean we favour a certain classification principle.
Different classification systems deserve and should be supported
by OSM. Normalisation should be practised on different
classification principles but avoid duplicating data in the same
sense. That way we get competing tagging schemes, that might
contain duplicate data in competition with a different
classification principle, however most of the time they can be
considered as different as they might be overlapping but not
exactly the same across different classification principles. This
justifies the existence also in other examples which are bothering
us for a long time like the competing landcover and natural
tagging schemes. Normalisation should however eliminate completely
identical and duplicate values.<br>
</p>
<p>Greetings,</p>
<p>Bert Araali<br>
</p>
<div class="moz-cite-prefix">On 24/02/2021 09:36, Paul Johnson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMPM96pZMGH0Me1BV_T09q4Wec+TYTML8gR-8v2VRFwMA_nxOw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Sun, Feb 21, 2021 at 3:26 PM Bert -Araali- Van
Opstal <<a href="mailto:bert.araali.afritastic@gmail.com"
moz-do-not-send="true">bert.araali.afritastic@gmail.com</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><font face="Verdana">Struggling for long time with the
same issue Mateusz. It is not clear if the PSV lane
count should be counted in the total lane count or
not, if they are deicated.</font></p>
</div>
</blockquote>
<div>I would say "yes, they do count", lanes=* should be all
lanes, including reserved lanes. I would also argue
regardless of the width of those lanes, as well.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><font face="Verdana"> </font></p>
<p><font face="Verdana">What seems to work though is to
use psv:lanes instead and define the psv usage of each
lane individually, without providing lanes:psv as a
separate count (dedicated or not).</font></p>
<p><font face="Verdana">So in your example we would get:</font></p>
<p><font face="Verdana">lanes=3<br>
psv:lanes=dedicated|yes|yes (notice we drive on the
left hand side, so we tag the lanes in the driving
direction from left to right and reserved psv lanes
are mostly located on the "outer" lane)<br>
</font></p>
</div>
</blockquote>
<div>I would say this is correct. This also works for bus
lanes, hov lanes and bicycle lanes. If the lanes are
exclusive to that use, be sure to also add <font
face="monospace">access:lanes=*</font> as well to set the
default access for the lanes.</div>
<div><br>
</div>
<div>So, for your example above, if only PSVs are allowed in
the left lane, then also add <font face="monospace">access:lanes=no|yes|yes</font>.</div>
</div>
</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>