It's a little disappointing to see these points rehashed given the lengthy
recent discussions, but at the risk of creating a new massive thread I'd
like to clear some things up.

> "The "traffic_signals" namespace is used to describe both vehicular
traffic signals and pedestrian/bicycle traffic signals, to everyone's
confusion."
> This statement is simply completely factually wrong.
> a) traffic_signals is the *value* here, not the name of the tag

Yes, that was a silly typo/flub. It's been fixed.

> b) there are 2 distinct tags to describe the presence of traffic signals
for the road way and foot/cycle way:
> highway=traffic_signals for signals controlling traffic on the road
> crossing=traffic_signals for signals controlling crossing pedestrians

If we acknowledge the typo, this isn't actually a contradiction. It's still
the same value being used for both, everyone is still confused, and believe
it or not, many in the previous thread explicitly stated that
crossing=traffic_signals is not solely about signals controlling
pedestrians, but implies signals controlling street traffic as well.

> "To make matters worse, it forces mappers to choose between tagging a
crossing's markings, [...], or whether it has signalization."

> Personally, I can not remember having ever seen, in my whole life, a
signal controlled pedestrian crossing that does not have road markings (...)

Have you done an audit? It's easy to miss these things if you aren't
directly concerned about them. There are several right in downtown Seattle,
Washington by Westlake Park, if you want to see an example. Plenty of neat
designs on the ground, but none are actually saying where the crossing is.
I've seen the situation in New York and Montana, as well.

> And even if there should really be signal controlled crossings that on
purpose do not have any road markings, I would consider that to be
basically completely irrelevant (...)

I find this attitude surprising. Why not ask if anyone finds it relevant?
This map isn't just for any single person.

- People with low vision use crosswalk markings to help navigate.
- Marked crossings assist in establishing a pedestrian space where car
traffic should not stop (which is one of the reasons they are installed
even when there are signals).
- Marked crossings increase pedestrian safety.

I, and many others, want to know when a crossing is marked or not.

> Deprecating a tag that has been used almost 600000 times and has
widespread software support, just to replace it with a different tag that
means exactly the same seems somewhat insane to me, and while I can't speak
for anyone else, I can guarantee to always vote no for this.

I would urge you to wait for responses before making up your mind.

As can be seen in the previous threads, none of the tags I've proposed mean
"the exact same thing" as what currently exists, because the meaning and
tagging of what exists is in no way agreed upon by even long-term expert
mappers. crossing=uncontrolled has the unfortunate reality of not actually
meaning "uncontrolled" and crossing="traffic_signals" says nothing about
markings (in addition to confusion about what it even describes about
signals).

Concerning the number of times the tag is used, consider that there are
33,000 marked crossings in my city (Seattle) alone. We have not mapped
anywhere near enough marked crossings/signaled crossings: they are
effectively unmapped for the vast majority of locations. Now is the perfect
time to deprecate any bad tags: there is intense interest in mapping these
typically unmapped features, but I can barely even tell people what to do
in terms of tags. I've also tried to figure out what data consumers even do
with the existing tags, particular those on nodes. I have found very few
uses, which would make sense given the shoddy coverage: you certainly can't
depend on them being mapped where they exist. Here's all that I know of:

- Adding a delay to car routing software, as the car might have to stop.

- Locally-scoped projects showing visual metaphors for "traffic signaled"
and "uncontrolled/marked/whatever" on a base map.

- A 3D renderer that shows continental crossings wherever
crossing=uncontrolled exists on a node.

I'm always interested to hear about more examples, but it's clear that
coverage is poor, which will limit applications.

> I can agree with this one, but it's essentially a non-issue as this has
already been done.

It's a successful example of orthogonalizing pedestrian crossing
information away from this catch-all namespace.

> crossing=uncontrolled and crossing=zebra have been used a combined 1.25
million times. In practical usage, they mean exactly the same thing, and
they have widespread software support already. Trying to replace them with
a 3rd value that still means exactly the same things is a classical case of
https://xkcd.com/927/

That comic is literally linked in the proposal about this very issue.

In practical usage, they clearly don't mean the same thing: it varies by
the mapper and what tool they used. See the previous discussions in the
list. Some folks even said they marked crossings as "uncontrolled" when
there are merely curb ramps available. It's also clear that crossing=zebra
has significant right-of-way (and marking type) implications in the UK and
other countries following similar traffic systems that go well-beyond
"marked".

> Looking at taginfo, there are already 168281 cases of crossing=marked
right now, so the unfortunate reality is that we already have the case of 3
different values meaning the same thing and no matter how much you try to
dictate the usage of a particular one by fiddling with the wiki, it's
unlikely that there will ever be a day when all 3 aren't in widespread use
synonymously.

Not unless we gather around a collective *single* standard and create
strategies for updating existing tags, something that proposal does discuss
(without depending on it).

> As such the best that can be done is to slightly adjust the wiki to
document the reality that all 3 values are used synonymously.

Hard disagree, because they are not used synonymously. We want them to be,
but that's because we know the thing we actually want to describe is merely
whether there are markings on the ground and we've tried to make due with a
garbage non-orthogonal tagging schema.


On Sun, May 19, 2019 at 9:32 AM <osm.tagg...@thorsten.engler.id.au> wrote:

> "The "traffic_signals" namespace is used to describe both vehicular
> traffic signals and pedestrian/bicycle traffic signals, to everyone's
> confusion."
>
> This statement is simply completely factually wrong.
>
> a) traffic_signals is the *value* here, not the name of the tag
>
> b) there are 2 distinct tags to describe the presence of traffic signals
> for the road way and foot/cycle way:
>
> highway=traffic_signals for signals controlling traffic on the road
> crossing=traffic_signals for signals controlling crossing pedestrians
>
> "To make matters worse, it forces mappers to choose between tagging a
> crossing's markings, [...], or whether it has signalization."
>
> Personally, I can not remember having ever seen, in my whole life, a
> signal controlled pedestrian crossing that does not have road markings,
> excluding cases where there are temporarily no road markings at all because
> they haven't been painted yet after the road has just been laid down or
> resurfaced.
>
> And even if there should really be signal controlled crossings that on
> purpose do not have any road markings, I would consider that to be
> basically completely irrelevant. The presence of signals that control
> traffic and pedestrian movement supersedes the meaning any road markings
> might have. If a signal controlled crossing has road markings or not does
> not in any way change its operation.
>
> Deprecating a tag that has been used almost 600000 times and has
> widespread software support, just to replace it with a different tag that
> means exactly the same seems somewhat insane to me, and while I can't speak
> for anyone else, I can guarantee to always vote no for this.
>
> "Replacing crossing=island"
>
> I can agree with this one, but it's essentially a non-issue as this has
> already been done. At most the wiki might need slight editing to make it
> more clear that the use of crossing=island has been deprecated.
>
> "Replacing crossing=uncontrolled and crossing=zebra with crossing=marked"
>
> crossing=uncontrolled and crossing=zebra have been used a combined 1.25
> million times. In practical usage, they mean exactly the same thing, and
> they have widespread software support already. Trying to replace them with
> a 3rd value that still means exactly the same things is a classical case of
> https://xkcd.com/927/
>
> Looking at taginfo, there are already 168281 cases of crossing=marked
> right now, so the unfortunate reality is that we already have the case of 3
> different values meaning the same thing and no matter how much you try to
> dictate the usage of a particular one by fiddling with the wiki, it's
> unlikely that there will ever be a day when all 3 aren't in widespread use
> synonymously.
>
> As such the best that can be done is to slightly adjust the wiki to
> document the reality that all 3 values are used synonymously.
>
> All this basically leaves the crossing key with the following possible
> values:
>
> no - there is no crossing possible/legal here
>
> unmarked - there are no road markings or traffic signals here, but this is
> a place where people are generally (legally) cross the road, e.g. because
> of lowered kerbs, or because the sidewalk on one side of the road stops
> here, or some other indication that this is a commonly used crossing point.
>
> uncontrolled/zebra/marked - there are road markings, but no signals that
> control traffic flow, that make it clear to both road and pedestrian
> traffic that this is a designated crossing point
>
> traffic_signals - there are traffic signals here that control traffic
> flow, it is extremely likely that there are also road markings, but their
> presence or absence is irrelevant as it would not change how the crossing
> operates
>
> I think you'll find that any proposal that tries to completely throw over
> this well-established tagging scheme is doomed to failure.
>
> > -----Original Message-----
> > From: Markus <selfishseaho...@gmail.com>
> > Sent: Monday, 20 May 2019 00:37
> > To: Tag discussion, strategy and related tools
> > <tagging@openstreetmap.org>
> > Subject: [Tagging] "Unambiguous crossings" proposals and related
> > questions
> >
> > Hi Nick, hi everyone,
> >
> > I welcome these proposals (crossing=marked, crossing:signals=* and
> > footway=island) [1] to bring order to the pedestrian crossing
> > tagging.
> > Thank you, Nick, for your efforts so far!
> >
> > I have two questions, not about the proposals themselves, but about
> > pedestrian crossing tagging in general:
> >
> >   * When the crossing type is tagged on the way (e.g.
> > highway=footway
> > + footway=crossing + crossing=marked + crossing:signals=yes), should
> > the crossing type also be tagged (duplicated) on the crossing node
> > or are routers able to get that information from the crossing ways?
> >
> >   * Should the road be split for short refuge islands into two one-
> > way ways? This would result in unusual maps, especially at
> > crossroads
> > (example: [2]).
> >
> > [1]:
> > https://wiki.openstreetmap.org/wiki/Proposed_features/Unambiguous_cr
> > ossings
> > [2]:
> > https://wiki.openstreetmap.org/wiki/File:Crossroads_with_traffic_isl
> > ands.png
> >
> > Regards
> >
> > Markus
> >
> > _______________________________________________
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to