[Tagging] lanes:psv, lanes:bus - reserved or available?

[Paul Johnson]

On Wed, Feb 24, 2021 at 7:09 AM Bert -Araali- Van Opstal <
bert.araali.afritastic at gmail.com> wrote:

> 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.
> I think however there is a need to bring more clarity in the whole concept
> to serve several purposes:
> 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.
>
This gets to be a bit of a chicken-or-egg problem. Consumers won't use
something that isn't there.  While human readability is a factor, getting
more specific aids in machine understanding of a situation while not
sacrificing human readability, with more feature-complete editors capable
of visualizing this.  There's not really a way around complicated tags to
describe complicated roads, and that situation is honestly favorable to
error by omission.  We've already proven that if you build it, they will
come with the existence of OSM in the first place.

> 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.
>
access=* is generally understood to be the default access for an object
unless otherwise posted further down.  access:lanes=no| would mean the left
lane is closed, except psv:lanes=designated| would mean the left lane is
open and designated for PSVs.

For a road that is entirely closed except to PSV, then you could just go
access=no, psv=designated and that would be the default access for all
lanes on the way.

> 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.
> In this particular case:
>
> 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);
>
Please, by all means, this is almost as long overdue as moving away from
tagging road routes as ref=* on ways.

> B. consider promoting specific access lane tagging schemes like psv:lanes
> or access:lanes but deprecate all the separate lane counting tags.
>
This is already in active use and well documented
<https://wiki.openstreetmap.org/wiki/Key:access>.

> 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.
>
Suffice to say that there's good reason to both include all lanes and have
a blanket access tagged for a lane and not assume that "designated" means
only that kind of traffic can use that lane.

This doesn't really work.  A flush median in the middle of a road that's
legally treated as a raised median would be lanes:both_ways=1,
access:lanes:both_ways=no.  This is a pretty common beast in the US.
Likewise there's plenty of situations like HOV-only or bus-only turn
lanes.  Vancouver, Canada has situations where this is the case but only
specific, predetermined times of the day on a two-way road which means,
yeah, we're going to need access:lanes:forward:conditional=*to cover that
kind of situation.  Any kind of access tag currently in circulation is
usable as a lane access tag.

My city has several examples of designated bicycle lanes with different
access types.  A combined reserved bus/bike lane would have the access
values of access=no, bus=designated, bicycle=designated, for example.
There's also a lot of bicycle lanes that are access=yes, bicycle=designated.
And a big part of why I favor including all lanes, this sometimes happens
to more than one lane in each direction and not a curb lane, with an even
edgier edge case being the curb lane being closed to bicycles.

California, especially in the two megacities, designate lanes for hgv,
usually signing the leftmost lane that trucks can use as "Trucks OK", with
hgv=no being the access for all lanes left of that.

So, we can't assume that a designated lane implies access=yes or
access=no particularly
safely.

> 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.
>
But, we also should be able to fix problems that paint us into a corner and
not so resistant to fixing those problems because of an already embedded
tagging scheme.  The fact bicycle lanes weren't counted in the original
lanes=* proposal is a serious shortcoming that further refinements to turn
lane, lane width and lane access tagging have already rendered moot, yet,
there's been needless resistance to fixing this problem and that has led
entirely to this confusion about psv- and other reserved-lanes.

I'm not saying "let's move fast and break things", there's nothing
significant to break yet.  Let's get this ship steered in a direction that
handles lanes inclusively given the additional access, width and turn lane
tagging schemes *do* handle this in a consistent way regardless of what
that lane is, in the wild, all we have to do is say, "yes, this is a thing"
and start chipping away at the error by omission over time.  Especially
since data consumers aren't heavily relying on lane tagging yet except for
showing colorful arrows as lane suggestions (and not even getting that
right in cases where reserved bicycle lanes and perhaps some other reserved
lanes are present thanks to this "are all lanes really lanes" situation
we're discussing right now).

But let's not let "it's hard" get in the way of moving forward like we did
on route relations.  I think this thread is producing some good, actionable
discussion.  The relation primitive was created to describe routes and turn
restrictions over a decade ago now and we're still slowly peeling the
band-aid off on that.  Let's move faster than that, please.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210224/f41aa91d/attachment.htm>