Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Martin Koppenhoefer]

sent from a phone

> On 22. May 2019, at 21:16, Nick Bolten  wrote:
> 
> Ah, I see. Would you envision the only value for crossing:markings be "no", 
> or would it potentially have yes/no/{type}, where mappers use it at their 
> discretion - such as in this example?


yes/no/type 
preferably no/{type}


Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> crossing=traffic_signals
> crossing:markings=no

Ah, I see. Would you envision the only value for crossing:markings be "no",
or would it potentially have yes/no/{type}, where mappers use it at their
discretion - such as in this example?

On Mon, May 20, 2019 at 10:49 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 20. May 2019, at 17:17, Nick Bolten  wrote:
>
> > I would suggest to tag the exception, i.e. the absence of crossing
> markings where there is a pedestrian traffic light controlled crossing,
> with an additional property for the crossing node.
>
> I'm not following, could you give an example?
>
>
>
> crossing=traffic_signals
> crossing:markings=no
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> The core of the issue seems to be that there are two conflicting
mindsets: Mapping "types" of crossings versus having a "construction kit"
of several tags which each describe one facet of the crossing.

I agree, this is the central issue behind the tags being non-orthogonal:
crossing=* implies the "type" of crossing whereas the values often describe
(or are interpreted as describing) a "construction kit". The crossing "is
a" type (unmarked, uncontrolled, traffic_signals) vs. "has a" properties
(markings, signals, etc).

I'm open to the idea of crossing:markings=yes/no/* rather than
crossing=marked/unmarked.

> If we want to have "types of crossings" at all, it would be highly
unexpected to ignore the presence of traffic signals for that purpose.
> And the crossing=* key clearly seems to be intended for mapping the
type of the crossing. That meaning is suggested by the name of the key
itself, not just the current set of values, so I believe it's
counter-intuitive to turn it into just one of several equally important
orthogonal keys.

I agree that deciding the "type" to be markings is semi-arbitrary and
acknowledge that many think concepts like signals or "controls" take
precedent. These two proposals could have gone with
crossing=traffic_signals/unsignaled + crossing:markings=yes/no/* and still
solve the core issues.

> So what I would probably do is mix the two approaches instead of going
for a conceptually pure implementation. Use
crossing=unmarked/marked/traffic_signals for a basic classification of the
crossing's type, and then add orthogonal subtags like crossing:island=*,
crossing:marking=* etc. as needed.

I tend to prefer least-resistance / compromise options, and this sounds
like it's in that direction. If I'm understanding it right, these would be
taggable:

crossing=unmarked/uncontrolled/traffic_signals/no
crossing:markings=yes/no/*
crossing:signals=yes/no/*

One downside to allowing both approaches is the amount of redundancy in
tagging crossings: not only do we tag both the node on the street and a way
(if available), we can be tagging something like crossing=traffic_signals
and crossing:signals=yes/no/*, crossing:markings=yes/no/*. Personally, I
would never map or consume crossing=traffic_signals because it's frequently
unknowable what the mapper intended, so we'd have a system of competing
standards. I would also be tempted to convert crossing=* into the
crossing:* namespace tags whenever possible, due to the many problems
listed on these proposals.

But, for the sake of having an option, what do others think about this
approach? New subtags for markings/signals, old tags still allowed?

On Wed, May 22, 2019 at 8:39 AM Tobias Knerr  wrote:

> On 08.05.19 01:30, Nick Bolten wrote:
> > Would it be fair to say you're suggesting something along the lines of
> > crossing:marking=*, where * can be yes, no, or a marking type? You make
> > a good point about the simplicity of avoiding a subtag for markings.
>
> Yes, this is pretty much what I'm suggesting. And I believe it would be
> an useful tag no matter whether we make crossing mapping fully
> orthogonal or just mostly orthogonal.
>
> Taking a step back to explain my thoughts on splitting off signals...
>
> The core of the issue seems to be that there are two conflicting
> mindsets: Mapping "types" of crossings versus having a "construction
> kit" of several tags which each describe one facet of the crossing.
>
> If we want to have "types of crossings" at all, it would be highly
> unexpected to ignore the presence of traffic signals for that purpose.
> And the crossing=* key clearly seems to be intended for mapping the type
> of the crossing. That meaning is suggested by the name of the key
> itself, not just the current set of values, so I believe it's
> counter-intuitive to turn it into just one of several equally important
> orthogonal keys.
>
> What else could we do with crossing=*? In theory, we could just get rid
> of it entirely, but realistically, that's not going to fly, and I'm not
> even sure if it would be desirable. People _do_ tend to mentally put
> things to categories, and describing the most common crossings with just
> one tag is certainly convenient.
>
> So what I would probably do is mix the two approaches instead of going
> for a conceptually pure implementation. Use
> crossing=unmarked/marked/traffic_signals
> for a basic classification of the crossing's type, and then add
> orthogonal subtags like crossing:island=*, crossing:marking=* etc. as
> needed. It lacks the elegance of full orthogonality, but covers all
> practical use cases.
>
> Tobias
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Tobias Knerr]

On 08.05.19 01:30, Nick Bolten wrote:
> Would it be fair to say you're suggesting something along the lines of
> crossing:marking=*, where * can be yes, no, or a marking type? You make
> a good point about the simplicity of avoiding a subtag for markings.

Yes, this is pretty much what I'm suggesting. And I believe it would be
an useful tag no matter whether we make crossing mapping fully
orthogonal or just mostly orthogonal.

Taking a step back to explain my thoughts on splitting off signals...

The core of the issue seems to be that there are two conflicting
mindsets: Mapping "types" of crossings versus having a "construction
kit" of several tags which each describe one facet of the crossing.

If we want to have "types of crossings" at all, it would be highly
unexpected to ignore the presence of traffic signals for that purpose.
And the crossing=* key clearly seems to be intended for mapping the type
of the crossing. That meaning is suggested by the name of the key
itself, not just the current set of values, so I believe it's
counter-intuitive to turn it into just one of several equally important
orthogonal keys.

What else could we do with crossing=*? In theory, we could just get rid
of it entirely, but realistically, that's not going to fly, and I'm not
even sure if it would be desirable. People _do_ tend to mentally put
things to categories, and describing the most common crossings with just
one tag is certainly convenient.

So what I would probably do is mix the two approaches instead of going
for a conceptually pure implementation. Use
crossing=unmarked/marked/traffic_signals
for a basic classification of the crossing's type, and then add
orthogonal subtags like crossing:island=*, crossing:marking=* etc. as
needed. It lacks the elegance of full orthogonality, but covers all
practical use cases.

Tobias

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Paul Johnson]

On Mon, May 20, 2019, 02:53 Martin Koppenhoefer 
wrote:

>
>
> Am Mo., 20. Mai 2019 um 07:53 Uhr schrieb Nick Bolten :
>
>> Hello everyone, this is a late addition to this thread (I'll start a new
>> one soon after I improve the proposal page), but I want to give an example
>> of a crossing that has lights but no markings that is traversed by
>> (guessing) thousands of people per day:
>> https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
>> Despite having a lot of interesting art, there is no way to distinguish the
>> crossing location from non-crossing locations via markings on the ground.
>>
>> This is topical, as crossing=traffic_signals is often claimed to imply
>> crossing=marked.
>>
>
>
> It is very common to see markings at traffic signal controlled crossings,
> but I would not see them as a requirement, and I do not think it is written
> anywhere that it should be. From my understanding, it seemed not
> interesting for most mappers to distinguish traffic light controlled
> markings from unmarked ones, and you will likely have a hard time to
> convince them (as this thread shows) to retag all crossings just because
> there may be exceptions or situations where it may be relevant.
>

Can confirm, marked crosswalks are pretty rare in Oklahoma even at traffic
lights.  Only some school crossings and high pedestrian traffic corners
have them marked, typically.  Otherwise marked crosswalks tend to be for
crosswalks in unusual locations (like midblock).

>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Martin Koppenhoefer]

sent from a phone

> On 20. May 2019, at 17:17, Nick Bolten  wrote:
> 
> > I would suggest to tag the exception, i.e. the absence of crossing markings 
> > where there is a pedestrian traffic light controlled crossing, with an 
> > additional property for the crossing node.
> 
> I'm not following, could you give an example?


crossing=traffic_signals
crossing:markings=no

Cheers, Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> It is?  I hadn't noticed.

Yes.

> I take a very different view, that crossing=traffic_signals says that the
crossing is controlled by traffic signals.  There may or may not be
markings.  Those markings may or may not be similar to markings at
crossings without traffic signals but, if the lights are functioning those
markings have no legal significance and do not determine rights of way.

This is still not true. Cars cannot occupy that space, per law, in my area.
I assume this is probably true in yours as well.

I'd be happy if everyone had this interpretation, however, because it would
make my job of arguing about orthogonality very easy.

> I, like some others here, think it rather obsessive of you to insist on
mapping what we consider to be an irrelevancy.

First, we already map this. It's what the tag crossing=uncontrolled means,
per the wiki: a marked crossing, like a crosswalk in the US. You have to
put aside this idea of what "controlled" and "uncontrolled" mean, they are
apparently irrelevant. Perhaps we should change the schema so this kind of
error stops happening...

Anyways, that's a strange way to frame "mapping something I don't care
about". How is it obsessive? I've already listed several important use
cases, so I will be blunt: do you think people with low vision are
irrelevant and don't matter? Is this an ableist community? Do pedestrians
getting struck by cars not matter? Is it okay that they die?

> The crossing is CONTROLLED by the lights and that is the important factor.

This is completely unstated in the tag definitions. It's not actually the
important factor, per the most official-ish sources we have. Clearly
absolutely everyone (including you) is confused about how to use these tags.

> Sure, if you can come up with something that isn't disruptive and has
other benefits, then it MAY be worth coming up with a tagging scheme that
allows
us to indicate whether a crossing controlled by lights also has markings.

I did. It's this proposal. You should check it out, it makes a
multi-pronged argument regarding the problems of this tag and benefits of
changing it. I'm sure the proposal could always be improved, and I'm very
interested in feedback, but continually rehashing inaccurate and myopic
misrepresentations isn't productive.

> At best, all I've seen indicates that maybe editors should make it
clearer to mappers if they change a crossing tagged as traffic signals to
one with markings that perhaps they're
using aerial imagery to undo what somebody has verified on the ground.

There are currently four headings pointing out problems with
crossing=traffic_signals, several follow-up arguments about disambiguating
the whole traffic_signals namespace, definitions of what the new schema
would be, and a simplification of mapping down to two straightforward
questions (extremely easy to support in an editor) vs. the current
confusing trade-off schema.

The example you list is worse than you've stated, though. The *original*
mapping can easily be from aerial imagery and state crossing=uncontrolled.
Because the crossing subtag is now populated, QA tools / Overpass Turbo
will no longer pick it up as unset and needing data. Only a thorough
in-person audit / broken use case will detect the error.

> I don't deny that such edits may be a problem, I'm not convinced your
proposal is the best solution.

I'm open to other strategies. What do you propose?


On Mon, May 20, 2019 at 5:53 AM Paul Allen  wrote:

> On Mon, 20 May 2019 at 06:53, Nick Bolten  wrote:
>
>>
>> This is topical, as crossing=traffic_signals is often claimed to imply
>> crossing=marked.
>>
>
> It is?  I hadn't noticed.  I take a very different view, that
> crossing=traffic_signals says that
> the crossing is controlled by traffic signals.  There may or may not be
> markings.  Those
> markings may or may not be similar to markings at crossings without
> traffic signals but,
> if the lights are functioning those markings have no legal significance
> and do not
> determine rights of way.
>
> I, like some others here, think it rather obsessive of you to insist on
> mapping what we
> consider to be an irrelevancy.  The crossing is CONTROLLED by the lights
> and that
> is the important factor.  Sure, if you can come up with something that
> isn't disruptive and
> has other benefits, then it MAY be worth coming up with a tagging scheme
> that allows
> us to indicate whether a crossing controlled by lights also has markings.
>
> At best, all I've seen indicates that maybe editors should make it clearer
> to mappers if
> they change a crossing tagged as traffic signals to one with markings that
> perhaps they're
> using aerial imagery to undo what somebody has verified on the ground.  I
> don't deny that
> such edits may be a problem, I'm not convinced your proposal is the best
> solution.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> 

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> It is very common to see markings at traffic signal controlled crossings,
but I would not see them as a requirement, and I do not think it is written
anywhere that it should be.

I agree, and this is one of the criticisms I list for this tag. Every time
I have made this criticism - here or with a wider OSM group - several
people have chimed in to say that they've never seen a crossing with
traffic signals but no markings and thought it was a moot point. There's
one right now responding a bit condescendingly in another thread, in fact.

> From my understanding, it seemed not interesting for most mappers to
distinguish traffic light controlled markings from unmarked ones, and you
will likely have a hard time to convince them (as this thread shows) to
retag all crossings just because there may be exceptions or situations
where it may be relevant.

This is not the sole problem with the tag, so that is not a fair
characterization of this proposal. There is also no part of this proposal
asking anyone to remap their own past work. But I'll push back: as best I
can tell from old mailing list archives and the wiki, these tags did not
emerge from any attempt to map "interesting" things, let alone adequate
ones for pedestrians, but were simply intended to replace the UK-specific
zebra, pelican, toucan, etc tags. You can even see, "uncontrolled" morph
meanings ad hoc. Finally, I get several emails per month from
municipalities and civic tech groups that want to map these exact things,
and I have no legitimate schema to give them. I say this because there are
actually very few tagged crossings, despite the numbers or retagging
seeming impressive at first glance - they will be dwarfed in short order by
any real attempt to map these features.

> In your example it could even be interpreted as if there were some kind
of "markings" (different paving, designated pedestrian waiting area), but
moving forward, the next crossing does not, so we can safely assume it is a
situation that actually occurs.

Hmm, I'm not seeing any markings on the ground (on the street) that
distinguish the crossing location from the street at all.

> I would suggest to tag the exception, i.e. the absence of crossing
markings where there is a pedestrian traffic light controlled crossing,
with an additional property for the crossing node.

I'm not following, could you give an example?

Best,

Nick

On Mon, May 20, 2019, 12:54 AM Martin Koppenhoefer 
wrote:

>
>
> Am Mo., 20. Mai 2019 um 07:53 Uhr schrieb Nick Bolten :
>
>> Hello everyone, this is a late addition to this thread (I'll start a new
>> one soon after I improve the proposal page), but I want to give an example
>> of a crossing that has lights but no markings that is traversed by
>> (guessing) thousands of people per day:
>> https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
>> Despite having a lot of interesting art, there is no way to distinguish the
>> crossing location from non-crossing locations via markings on the ground.
>>
>> This is topical, as crossing=traffic_signals is often claimed to imply
>> crossing=marked.
>>
>
>
> It is very common to see markings at traffic signal controlled crossings,
> but I would not see them as a requirement, and I do not think it is written
> anywhere that it should be. From my understanding, it seemed not
> interesting for most mappers to distinguish traffic light controlled
> markings from unmarked ones, and you will likely have a hard time to
> convince them (as this thread shows) to retag all crossings just because
> there may be exceptions or situations where it may be relevant.
>
> In your example it could even be interpreted as if there were some kind of
> "markings" (different paving, designated pedestrian waiting area), but
> moving forward, the next crossing does not, so we can safely assume it is a
> situation that actually occurs.
>
> I would suggest to tag the exception, i.e. the absence of crossing
> markings where there is a pedestrian traffic light controlled crossing,
> with an additional property for the crossing node.
>
> Cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Paul Allen]

On Mon, 20 May 2019 at 06:53, Nick Bolten  wrote:

>
> This is topical, as crossing=traffic_signals is often claimed to imply
> crossing=marked.
>

It is?  I hadn't noticed.  I take a very different view, that
crossing=traffic_signals says that
the crossing is controlled by traffic signals.  There may or may not be
markings.  Those
markings may or may not be similar to markings at crossings without traffic
signals but,
if the lights are functioning those markings have no legal significance and
do not
determine rights of way.

I, like some others here, think it rather obsessive of you to insist on
mapping what we
consider to be an irrelevancy.  The crossing is CONTROLLED by the lights
and that
is the important factor.  Sure, if you can come up with something that
isn't disruptive and
has other benefits, then it MAY be worth coming up with a tagging scheme
that allows
us to indicate whether a crossing controlled by lights also has markings.

At best, all I've seen indicates that maybe editors should make it clearer
to mappers if
they change a crossing tagged as traffic signals to one with markings that
perhaps they're
using aerial imagery to undo what somebody has verified on the ground.  I
don't deny that
such edits may be a problem, I'm not convinced your proposal is the best
solution.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Martin Koppenhoefer]

Am Mo., 20. Mai 2019 um 07:53 Uhr schrieb Nick Bolten :

> Hello everyone, this is a late addition to this thread (I'll start a new
> one soon after I improve the proposal page), but I want to give an example
> of a crossing that has lights but no markings that is traversed by
> (guessing) thousands of people per day:
> https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
> Despite having a lot of interesting art, there is no way to distinguish the
> crossing location from non-crossing locations via markings on the ground.
>
> This is topical, as crossing=traffic_signals is often claimed to imply
> crossing=marked.
>


It is very common to see markings at traffic signal controlled crossings,
but I would not see them as a requirement, and I do not think it is written
anywhere that it should be. From my understanding, it seemed not
interesting for most mappers to distinguish traffic light controlled
markings from unmarked ones, and you will likely have a hard time to
convince them (as this thread shows) to retag all crossings just because
there may be exceptions or situations where it may be relevant.

In your example it could even be interpreted as if there were some kind of
"markings" (different paving, designated pedestrian waiting area), but
moving forward, the next crossing does not, so we can safely assume it is a
situation that actually occurs.

I would suggest to tag the exception, i.e. the absence of crossing markings
where there is a pedestrian traffic light controlled crossing, with an
additional property for the crossing node.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> If you scroll down a bit, you'll find a map that shows that Pine St
between 4th & 5th Ave's is a "shared street without markings":
https://www.citylab.com/solutions/2015/03/6-places-where-cars-bikes-and-pedestrians-all-share-the-road-as-equals/388351/
which I guess should possibly be tagged in OSM as a highway=living_street?

The language on the SDOT page is very confusing! It's solely about bicycles
not having their own lanes and having to share space with cars, not about
pedestrians. For the CityLab page, that living street is several blocks
away on Bell St closer to 1st and 2nd. It's possible something has recently
changed, but I believe Pine is not a shared / a "living street" between 4th
and 5th.

> Not in iD!

> If you put in a crossing=marked than add that it has traffic signals,
then it immediately changes to a crossing=unmarked!

That does seem like a problem, though I'd suggest that if this tag were
adopted it'd be an easy fix on iD! As of the status quo, what should happen
when there are pedestrian signals re: markings is effectively undefined,
despite opinions on the mailing list. With something like crossing:signals,
tags for markings would never conflict with tags for signals.

Best,

Nick

On Sun, May 19, 2019 at 11:46 PM Graeme Fitzpatrick 
wrote:

>
>
> On Mon, 20 May 2019 at 15:53, Nick Bolten  wrote:
>
>> Hello everyone, this is a late addition to this thread (I'll start a new
>> one soon after I improve the proposal page), but I want to give an example
>> of a crossing that has lights but no markings that is traversed by
>> (guessing) thousands of people per day:
>> https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
>> Despite having a lot of interesting art, there is no way to distinguish the
>> crossing location from non-crossing locations via markings on the ground.
>>
>
> That's an interesting one!
>
> Thought at first that it may have been a diagonal crossing
> https://en.wikipedia.org/wiki/Pedestrian_scramble, but after a bit more
> searching found this:
>
> https://www.seattle.gov/transportation/projects-and-programs/programs/bike-program/protected-bike-lanes/pike-pine-mobility-improvements
>
>
> If you scroll down a bit, you'll find a map that shows that Pine St
> between 4th & 5th Ave's is a "shared street without markings":
>
> https://www.citylab.com/solutions/2015/03/6-places-where-cars-bikes-and-pedestrians-all-share-the-road-as-equals/388351/
> which I guess should possibly be tagged in OSM as a highway=living_street?
>
> So, you're sort of correct in that there are no defined markings, but also
> sort of wrong because the pretty artwork are actually markings to show that
> there are no markings!
>
> This is topical, as crossing=traffic_signals is often claimed to imply
>> crossing=marked.
>>
>
> Not in iD!
>
> If you put in a crossing=marked than add that it has traffic signals, then
> it immediately changes to a crossing=unmarked!
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Graeme Fitzpatrick]

On Mon, 20 May 2019 at 15:53, Nick Bolten  wrote:

> Hello everyone, this is a late addition to this thread (I'll start a new
> one soon after I improve the proposal page), but I want to give an example
> of a crossing that has lights but no markings that is traversed by
> (guessing) thousands of people per day:
> https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
> Despite having a lot of interesting art, there is no way to distinguish the
> crossing location from non-crossing locations via markings on the ground.
>

That's an interesting one!

Thought at first that it may have been a diagonal crossing
https://en.wikipedia.org/wiki/Pedestrian_scramble, but after a bit more
searching found this:
https://www.seattle.gov/transportation/projects-and-programs/programs/bike-program/protected-bike-lanes/pike-pine-mobility-improvements


If you scroll down a bit, you'll find a map that shows that Pine St between
4th & 5th Ave's is a "shared street without markings":
https://www.citylab.com/solutions/2015/03/6-places-where-cars-bikes-and-pedestrians-all-share-the-road-as-equals/388351/
which I guess should possibly be tagged in OSM as a highway=living_street?

So, you're sort of correct in that there are no defined markings, but also
sort of wrong because the pretty artwork are actually markings to show that
there are no markings!

This is topical, as crossing=traffic_signals is often claimed to imply
> crossing=marked.
>

Not in iD!

If you put in a crossing=marked than add that it has traffic signals, then
it immediately changes to a crossing=unmarked!

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

Hello everyone, this is a late addition to this thread (I'll start a new
one soon after I improve the proposal page), but I want to give an example
of a crossing that has lights but no markings that is traversed by
(guessing) thousands of people per day:
https://www.bing.com/maps?osid=0fa511ff-b1e5-4011-b16c-d96c0c4ce8a5=47.611664~-122.336542=19=251.4678=-22.174986=x=z.0=2=2=S00027.
Despite having a lot of interesting art, there is no way to distinguish the
crossing location from non-crossing locations via markings on the ground.

This is topical, as crossing=traffic_signals is often claimed to imply
crossing=marked.

On Tue, May 7, 2019 at 2:08 PM Nick Bolten  wrote:

> https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:signals
>
> Hello fellow tagging enthusiasts!
>
> This proposal suggests the deprecation of crossing=traffic_signals and
> replacing it with crossing:signals=yes, i.e. placing pedestrian
> signalization on a dedicated tag that is separate from crossing=* values.
>
> The current values for the crossing=* tag are not orthogonal:
> crossing=traffic_signals is not actually orthogonal to
> crossing=uncontrolled or crossing=unmarked, for example. This presents a
> significant challenge to understanding the meaning of these tags and in
> creating properly descriptive tags on map elements. For example, let's take
> three attributes of a pedestrian crossing: signalization for pedestrians,
> signalization for traffic, and markings on the ground. What do
> crossing=uncontrolled/unmarked/traffic_signals say about these scenarios?
>
> crossing=uncontrolled:
>   - signalization for pedestrians is undefined
>   - signalization for traffic *should* not exist, but due to confusions
> over the meaning of the tag, might.
>   - markings are implied, but due to confusions over the meaning of the
> tag, might not not.
>
> crossing=unmarked:
>   - signalization for pedestrians is undefined
>   - signalization for traffic is undefined
>   - there are no markings
>
> crossing=traffic_signals
>   - signalization for pedestrians: yes
>   - signalization for traffic is undefined
>   - markings are undefined
>
> So, you can see the problem: the values are describing completely
> different things and the rest is ambiguous.
>
> I'm interested in any/all feedback regarding this tag proposal! Thank you
> for your time!
>
> Best,
>
> Nick
>
>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Warin]

On 08/05/19 19:18, marc marc wrote:

Le 08.05.19 à 10:30, Martin Koppenhoefer a écrit :

„uncontrolled“, as it is a misnomer.

indeed, but what could be a better value ?
crossing=not_controlled_by_a_traffic_signal is a little long


I have used 'uncontrolled' where there is no marking, no aids but a 'common' 
crossing place.

If a crossing has some 'aid' then the aid should be tagged.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> Same around here.  Most of them have tactile paving too.

Please join our discussion of crossing=marked!

Without wanting to invite discussion in this thread, this is not what
"uncontrolled" means in OpenStreetMap, and it's one of the reasons we
should change it.

On Wed, May 8, 2019 at 4:52 AM Paul Allen  wrote:

> On Wed, 8 May 2019 at 10:42, Philip Barnes  wrote:
>
>>
>> Uncontrolled crossings are by far the most common. They are wherever
>> there are drop kerbs, which in my town just about every road junction.
>>
>
> Same around here.  Most of them have tactile paving too.  Which I suppose
> could be considered as
> marking, because it's a different colour to the ordinary paving (but
> sometimes the difference is
> subtle).  For the pedestrian it's obviously marked (even if there's no
> colour change you can see
> the drop kerb and feel the bumps) but around here most motorists seem
> blissfully unaware that
> it's there.
>
> A problem I found way, way back when I looked at how somebody had mapped
> the few pelican
> crossings around here is that, if you did it according to the wiki, it
> didn't render (no traffic lights
> shown). Yes, from the perspective of the pedestrian it's a crossing but
> from the perspective of
> the motorist it's a set of traffic lights.That may havechanged, but I
> found a combination of tags
> that sort of made sense (and could be interpreted as complying with the
> wiki, maybe) and
> actually rendered as traffic lights.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> Uncontrolled crossings are by far the most common. They are wherever
there are drop kerbs, which in my town just about every road junction.

Please join our discussion of crossing=marked!

On Wed, May 8, 2019 at 2:42 AM Philip Barnes  wrote:

> On Wednesday, 8 May 2019, marc marc wrote:
> > Le 08.05.19 à 01:30, Nick Bolten a écrit :
> > > Unmarked crossings are abstract "fictions"
> >
> > beware of caricature :
> > - unmarked pedestrian crossings with lowered kerb for wheelchairs
> > - unmarked pedestrian crossing that connects a sidewalk on each side of
> > the crossing
> >
> > just because you've never seen one before doesn't mean it's a fiction.
> >
> Absolutely Marc.
>
> Uncontrolled crossings are by far the most common. They are wherever there
> are drop kerbs, which in my town just about every road junction.
>
> Needed for wheelchairs, pushchairs, people with limited mobility and me
> occasionally when I need to get my wheeled suitcase to the station.
>
> It would be pointless to provide traffic lights in residential areas with
> minimal traffic.
>
> Phil (trigpoint)
>
> --
> Sent from my Sailfish device
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> Just because mapping something requires real survey rather than mapping
from aerial imagery is not making it fictional or unofficial.

You are correct. To clarify, my use of quotation marks is meant to
communicate that I'm not literally saying they are a fiction - just similar
to one. There is no official, exact linear-ish feature you can trace to
know where an unmarked crossing is. Often, pedestrians can legally cross at
any point across a particular street - but of course, we're not drawing 200
footway=crossing, crossing=unmarked lines down a single street to make sure
we've covered enough options. Mappers (myself included) are doing their
best to simulate where a pedestrian can cross, usually near a street
intersection, and typically in an attempt to connect sidewalks together,
without any dedicated visual indication.

> Typical footway is also linear.

In theory, but often not in actuality. It's easy to make car traffic into
lines, with lanes, where cars move along the path. If they don't, it tends
to be illegal and dangerous! In contrast, pedestrians can walk from the
bank to a bus stop, moving in a completely orthogonal direction to the
"footway" representing the sidewalk: they navigate a 2D space. We are
simply providing abstractions for, e.g., the sidewalk or other footways to
serve a subset of data needs: "how can I get from here to there using
sidewalks?", where "here" and "there" are somewhat distant.

> Unmarked crossings may also have legal implications (for example in
Poland).

Indeed, and this is also true of my area (Seattle, WA, USA).

On Wed, May 8, 2019 at 2:37 AM Mateusz Konieczny 
wrote:

> 8 May 2019, 01:30 by nbol...@gmail.com:
>
> - Unmarked crossings are abstract "fictions" representing where an
> individual might cross the street, marked crossings are identifiable from
> imagery.
> - Because unmarked crossings are "fictions", they are only suggested
> places to cross, according to the mapper. In contrast, marked crossings are
> "official".
>
> Just because mapping something requires real survey rather than mapping
> from aerial imagery is
> not making it fictional or unofficial.
>
> - Marked crossings are one of the few pedestrian spaces that can be
> straightforwardly considered as a linear feature: it connects spaces across
> a street.
>
> Typical footway is also linear.
>
> - Marked crossings tend to have legal implications, as you note.
>
> Unmarked crossings may also have legal implications (for example in
> Poland).
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> and we already have it : crossing_ref

I was only referencing these facts to note a synergy with another proposal.
It won't be productive to hash out the entirety of problems with
crossing=uncontrolled and the proposal to use crossing=marked in this
thread, so I'll ask that we have in-depth discussion on the other thread
instead.

> beware of caricature :
> - unmarked pedestrian crossings with lowered kerb for wheelchairs
> - unmarked pedestrian crossing that connects a sidewalk on each side of
the crossing

> just because you've never seen one before doesn't mean it's a fiction.

I'm going to ask, again, that you keep away from personal accusations,
particularly ones that are speculative in nature.

I have mapped thousands of unmarked crossings and am in no way implying
anything derogatory. It is simply a fact that there are very few visual
indications of where a pedestrian will cross an unmarked crossing.
Therefore, the location where it is drawn is somewhat arbitrary - if you're
lucky, there's a dropped curb and you can draw the line through those
drops, but this is not necessary.

On Wed, May 8, 2019 at 2:10 AM marc marc  wrote:

> Le 08.05.19 à 00:06, Tobias Knerr a écrit :
> > We need a tag for the_type_  of the markings anyway
> >  (as different patterns for marked crossings can have
> > entirely different legal meanings in some jurisdictions), and we can use
> > that same tag for presence/absence by also allowing yes/no values.
>
> and we already have it : crossing_ref
> and indeed i agree that adding yes/no to current value is a good idea.
> the name of the key is not perfect, but it has the advantage of
> existing. changing all the keys and value at once seems unrealistic. it
> seems preferable to me to take out the type of marking of the crossing
> key in favour of the crossing_ref key, it is not a perfect change, but
> it was already a huge step forward. we discussed it on the talk-fr list
> last year, no one opposed the mecanical edit. on the contrary only one
> contributor would have wanted us to go further and change all at once.
> to big to success.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> ground marking but not traffic signal

I listed three discrete categories being covered in the current schema:
on-the-ground markings, signals for pedestrians, and signals for
cross-traffic. There is some further confusion regarding the word
"uncontrolled" having to do with right-of-way, but I'll ask that we keep
that to my other proposal whenever reasonable.

So, with that in mind, what does "traffic signal" mean? Is there a signal
telling pedestrians when to cross? Is there a signal telling cross-traffic
to stop, at which point pedestrians have the right of way? The wiki states
that it's only about the pedestrian signal, which is another problem that I
neglected to cover: traffic_signals is already used for street traffic via
highway=traffic_signals and it applies to automotive traffic. Mappers are
often confused about what traffic_signals means in the context of
crossing=traffic_signals, which is why this proposal originally suggested
crossing=pedestrian_signals.

> sorry I didn't understand what you mean. crossing describe the crossing.
if you want to describe a traffic sign, check traffic_sign key

A crossing with signals can and frequently does have separate signals for
cross-traffic (cars) and pedestrians. Which are present, according to this
tag? Saying, "the crossing" does not disambiguate this question, as any
crossing can have any combination.

> I didn't see where you see this "implied"

The wiki and other OSM resources, including this very mailing list.

> the color of the nearest building is not indicated either, fortunately
because it is not the role of this key. if you want a traffic sign info,
check traffic_sign key

You seem to be implying that crossing=traffic_signals is not describing
signals for pedestrians. This is what the wiki says about this tag:
"Position this tag where the crossing-traffic (pedestrian, bicycles) have
their own traffic lights.". That's it. The mapper is left to try and guess
about what "traffic lights" means and whether it implies that pedestrians
have their own signals. I've seen countless mappers, veteran mappers, say
that crossing=traffic_signals means there is a light telling pedestrians
when they can cross. I would suggest that this means the existing data is
unreliable.

To me, this suggests that we should even have another tag:
crossing:traffic_signals=yes/no, that is dedicated solely to automotive
traffic on the street having a signal at this crossing.

> again... (check crossing_ref)

I don't know what this means (nor the response before it).

> the current situation is far from perfect, but either you have not
understood the current tags, or you are blackening the current situation to
promote your proposal to change everything, which seems unrealistic.

I'm going to ask that we keep personal accusations of dishonesty to a
minimum. These mailing lists are full of unnecessary personal invective
that are issued at the drop of a hat, with zero invitation, and it does
nothing except divide.

On Wed, May 8, 2019 at 1:59 AM marc marc  wrote:

> Le 07.05.19 à 23:08, Nick Bolten a écrit :
> > What do crossing=uncontrolled/unmarked/traffic_signals say about these
> scenarios?
>
> > crossing=uncontrolled:
>
> ground marking but not traffic signal
>
> >- signalization for pedestrians is undefined
>
> sorry I didn't understand what you mean.
> crossing describe the crossing.
> if you want to describe a traffic sign, check traffic_sign key
>
> >- markings are implied
>
> I didn't see where you see this "implied"
>
> > crossing=unmarked:
> >- signalization for pedestrians is undefined
>
> the color of the nearest building is not indicated either,
> fortunately because it is not the role of this key.
> if you want a traffic sign info, check traffic_sign key
>
> >- signalization for traffic is undefined
>
> again...
>
>
> > crossing=traffic_signals
> >- markings are undefined
>
> again... (check crossing_ref)
>
> > So, you can see the problem: the values are describing completely
> > different things and the rest is ambiguous.
>
> the current situation is far from perfect, but either you have not
> understood the current tags, or you are blackening the current situation
> to promote your proposal to change everything, which seems unrealistic.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Martin Koppenhoefer]

sent from a phone

On 8. May 2019, at 11:18, marc marc  wrote:

>> Le 08.05.19 à 10:30, Martin Koppenhoefer a écrit :
>> „uncontrolled“, as it is a misnomer.
> 
> indeed, but what could be a better value ?
> crossing=not_controlled_by_a_traffic_signal is a little long


I’m using crossing=zebra and highway=crossing on zebra crossings (I don’t care 
for the difference of traffic light controlled crossings with or without zebra 
markings, the physical presence of road markings is quite ephemeral, I am not 
yet thinking of keeping track of road marking maintenance) 

The only places I am a bit unsure are those with zebra road markings but not in 
proximity of a road intersection and without vertical signs. Legally these 
aren’t zebra crossings around here, but from a practical point of view, drivers 
will try to not run over crossing pedestrians at these spots as well.

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Martin Koppenhoefer]

sent from a phone

On 8. May 2019, at 11:15, marc marc  wrote:

>> Unmarked crossings are abstract "fictions"
> 
> beware of caricature :
> - unmarked pedestrian crossings with lowered kerb for wheelchairs
> - unmarked pedestrian crossing that connects a sidewalk on each side of 
> the crossing
> 
> just because you've never seen one before doesn't mean it's a fiction


indeed, when a footway crosses the street without any markings you could still 
expect footway traffic crossing there. 
You would not add the tag literally anywhere but only when there are 
indications it is a kind of crossing.

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[marc marc]

Le 08.05.19 à 15:09, Paul Allen a écrit :
> On Wed, 8 May 2019 at 13:44, marc marc wrote:
> 
> Le 08.05.19 à 13:51, Paul Allen a écrit :
>  > pelican crossings <...> didn't render (no traffic lights shown)
> 
> you get it with crossing=traffic_lights crossing_ref=pelican
> 
> I had those, together with a few other things.  At the time I did it, 
> that wasn't how the wiki said to
> do it, but other parts of the wiki implied those were also acceptable.
> 
> I also had (and still have) highway=traffic_signals

the main (render) issue is that both are different things (one 
represents a traffic lights, which may or may not be associated with a 
pedestrian crossing, the other represents a pedestrian crossing managed 
by a traffic_lights that may be in the same place or several metres 
before) but whose rendering is identical.
but that's a bug/improvement needed in the render's style,
not a tagging issue.

> Dunno if that's right or wrong

it's not true or wrong, it's a historic shortcut that it's probably time 
to depreciate in order to focus each tag on a specific meaning

Regards,
Marc
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Paul Allen]

On Wed, 8 May 2019 at 13:44, marc marc  wrote:

> Le 08.05.19 à 13:51, Paul Allen a écrit :
> > pelican crossings
> > it didn't render (no traffic lights shown)
>
> you get it with crossing=traffic_lights crossing_ref=pelican
>

I had those, together with a few other things.  At the time I did it, that
wasn't how the wiki said to
do it, but other parts of the wiki implied those were also acceptable.

I also had (and still have) highway=traffic_signals and
traffic_signals=pedestrian_crossing.  Dunno
if that's right or wrong - I went through many tries before I hit a
combination that worked, and didn't
want to go through even more tries to find out if any of those were
unnecessary.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[marc marc]

Le 08.05.19 à 13:51, Paul Allen a écrit :
> pelican crossings
> it didn't render (no traffic lights shown)

you get it with crossing=traffic_lights crossing_ref=pelican
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Paul Allen]

On Wed, 8 May 2019 at 10:42, Philip Barnes  wrote:

>
> Uncontrolled crossings are by far the most common. They are wherever there
> are drop kerbs, which in my town just about every road junction.
>

Same around here.  Most of them have tactile paving too.  Which I suppose
could be considered as
marking, because it's a different colour to the ordinary paving (but
sometimes the difference is
subtle).  For the pedestrian it's obviously marked (even if there's no
colour change you can see
the drop kerb and feel the bumps) but around here most motorists seem
blissfully unaware that
it's there.

A problem I found way, way back when I looked at how somebody had mapped
the few pelican
crossings around here is that, if you did it according to the wiki, it
didn't render (no traffic lights
shown). Yes, from the perspective of the pedestrian it's a crossing but
from the perspective of
the motorist it's a set of traffic lights.That may havechanged, but I
found a combination of tags
that sort of made sense (and could be interpreted as complying with the
wiki, maybe) and
actually rendered as traffic lights.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Joseph Eisenberg]

In the United States an unmarked crosswalk is usually legally identical to
a crosswalk marked with painted stripes. Vehicle drivers and bike riders
must stop for a pedestrian in a crosswalk whether there is paint or not. In
general, all places where there is a sidewalk on both sides of an
intersection are an unmarked crosswalk, even if there is not a dropped kerb
(curb). I believe this is a general rule, but it is certainly true in  the
western States.

On Wed, May 8, 2019 at 6:37 PM Mateusz Konieczny 
wrote:

> 8 May 2019, 01:30 by nbol...@gmail.com:
>
> - Unmarked crossings are abstract "fictions" representing where an
> individual might cross the street, marked crossings are identifiable from
> imagery.
> - Because unmarked crossings are "fictions", they are only suggested
> places to cross, according to the mapper. In contrast, marked crossings are
> "official".
>
> Just because mapping something requires real survey rather than mapping
> from aerial imagery is
> not making it fictional or unofficial.
>
> - Marked crossings are one of the few pedestrian spaces that can be
> straightforwardly considered as a linear feature: it connects spaces across
> a street.
>
> Typical footway is also linear.
>
> - Marked crossings tend to have legal implications, as you note.
>
> Unmarked crossings may also have legal implications (for example in
> Poland).
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Philip Barnes]

On Wednesday, 8 May 2019, marc marc wrote:
> Le 08.05.19 à 01:30, Nick Bolten a écrit :
> > Unmarked crossings are abstract "fictions"
> 
> beware of caricature :
> - unmarked pedestrian crossings with lowered kerb for wheelchairs
> - unmarked pedestrian crossing that connects a sidewalk on each side of 
> the crossing
> 
> just because you've never seen one before doesn't mean it's a fiction.
>
Absolutely Marc.

Uncontrolled crossings are by far the most common. They are wherever there are 
drop kerbs, which in my town just about every road junction. 

Needed for wheelchairs, pushchairs, people with limited mobility and me 
occasionally when I need to get my wheeled suitcase to the station.

It would be pointless to provide traffic lights in residential areas with 
minimal traffic.

Phil (trigpoint) 

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Mateusz Konieczny]

8 May 2019, 01:30 by nbol...@gmail.com:

> - Unmarked crossings are abstract "fictions" representing where an individual 
> might cross the street, marked crossings are identifiable from imagery.
> - Because unmarked crossings are "fictions", they are only suggested places 
> to cross, according to the mapper. In contrast, marked crossings are 
> "official".
>
Just because mapping something requires real survey rather than mapping from 
aerial imagery is
not making it fictional or unofficial.

> - Marked crossings are one of the few pedestrian spaces that can be 
> straightforwardly considered as a linear feature: it connects spaces across a 
> street.
>
Typical footway is also linear.

> - Marked crossings tend to have legal implications, as you note.
>
Unmarked crossings may also have legal implications (for example in Poland).

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[marc marc]

Le 08.05.19 à 10:30, Martin Koppenhoefer a écrit :
> „uncontrolled“, as it is a misnomer.

indeed, but what could be a better value ?
crossing=not_controlled_by_a_traffic_signal is a little long
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[marc marc]

Le 08.05.19 à 01:30, Nick Bolten a écrit :
> Unmarked crossings are abstract "fictions"

beware of caricature :
- unmarked pedestrian crossings with lowered kerb for wheelchairs
- unmarked pedestrian crossing that connects a sidewalk on each side of 
the crossing

just because you've never seen one before doesn't mean it's a fiction.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[marc marc]

Le 08.05.19 à 00:06, Tobias Knerr a écrit :
> We need a tag for the_type_  of the markings anyway
>  (as different patterns for marked crossings can have
> entirely different legal meanings in some jurisdictions), and we can use
> that same tag for presence/absence by also allowing yes/no values.

and we already have it : crossing_ref
and indeed i agree that adding yes/no to current value is a good idea.
the name of the key is not perfect, but it has the advantage of 
existing. changing all the keys and value at once seems unrealistic. it 
seems preferable to me to take out the type of marking of the crossing 
key in favour of the crossing_ref key, it is not a perfect change, but 
it was already a huge step forward. we discussed it on the talk-fr list 
last year, no one opposed the mecanical edit. on the contrary only one 
contributor would have wanted us to go further and change all at once.
to big to success.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[marc marc]

Le 07.05.19 à 23:08, Nick Bolten a écrit :
> What do crossing=uncontrolled/unmarked/traffic_signals say about these 
> scenarios?

> crossing=uncontrolled:

ground marking but not traffic signal

>    - signalization for pedestrians is undefined

sorry I didn't understand what you mean.
crossing describe the crossing.
if you want to describe a traffic sign, check traffic_sign key

>    - markings are implied

I didn't see where you see this "implied"

> crossing=unmarked:
>    - signalization for pedestrians is undefined

the color of the nearest building is not indicated either,
fortunately because it is not the role of this key.
if you want a traffic sign info, check traffic_sign key

>    - signalization for traffic is undefined

again...


> crossing=traffic_signals
>    - markings are undefined

again... (check crossing_ref)

> So, you can see the problem: the values are describing completely 
> different things and the rest is ambiguous.

the current situation is far from perfect, but either you have not 
understood the current tags, or you are blackening the current situation 
to promote your proposal to change everything, which seems unrealistic.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Martin Koppenhoefer]

sent from a phone

> On 8. May 2019, at 00:54, Nick Bolten  wrote:
> 
> This proposal does not deprecate crossing=uncontrolled.
> 
> For the latter: why not? The tag is, in technical terms, garbage, and other 
> tags in relatively high use have been deprecated before.


I would support the deprecation of „uncontrolled“, as it is a misnomer. Road 
markings like zebra markings are a kind of control, and even more, zebra 
crossings may require additional vertical signage in certain circumstances.

Thinking about traffic control, we seem to miss a value for control by 
policemen. I could speculate there may be several reasons, for one these areas 
will likely have such slow traffic in general that the kind of crossing control 
doesn’t seem interesting to the mappers, there may be few on the ground mappers 
in the area, and no established method how to do it yet.

Around here there is a kind of mix, some traffic light controlled major 
crossings have a police booth nearby, where sometimes there are policemen 
observing or controlling the traffic on the crossing.
E.g. 
https://www.mapillary.com/app/?lat=41.88707399984=12.50389300062=17.57282613084294=n1J7gYYmL5B9Ejx-RzdXeg=photo=false=0.6181064937229852=0.48021931447092797=0

There are many of these, but only a few are frequently staffed.

Cheers, Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Dave F via Tagging]

On 07/05/2019 22:46, Volker Schmidt wrote:

Two spontanous reactions

1) You cannot deprecate a tagging that is used 750k times
(crossing=uncontrolled) or 570k times (crossing=traffic_signals)


In principle, why do you think it can't be performed?


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> However, it seems odd to "demote" traffic signals to a sub-tag when their
presence or absence is perhaps the biggest influence on the crossing's
overall character.

I agree that it's not ideal to have to make these kinds of choices about
"demoting". In case it's helpful, this is my original rationale:

1) To have properly orthogonal values for the crossing key, it should
describe one category of things, like markings or signals. This means
"demoting" all but one feature to other tags (hopefully namespaced) like
crossing:signals. Imagine if highway=primary originally implied 4 lanes as
well as "major, separated high-speed street" and only later did we have to
separate out highway=primary from lanes=4. We agree on this, just thought
it was an important point.

2) Which category should be used as the primary value of crossing? I went
with the marking because it is, by far, the most-tagged value:
uncontrolled/zebra/marked/unmarked account for 3 times as many tags as
traffic_signals.

> In comparison, it seems somewhat less important whether a signalled
crossing also has painted markings on the road. So I would suggest using a
separate tag for the markings instead. We need a tag for the _type_ of the
markings anyway (as different patterns for marked crossings can have
entirely different legal meanings in some jurisdictions), and we can use
that same tag for presence/absence by also allowing yes/no values.

Would it be fair to say you're suggesting something along the lines of
crossing:marking=*, where * can be yes, no, or a marking type? You make a
good point about the simplicity of avoiding a subtag for markings.

Aside from frequency of tagging, the biggest reason I've prioritized
markings as the primary value is that marked crossings are starkly
different from unmarked ones from many different perspectives:

- Unmarked crossings are abstract "fictions" representing where an
individual might cross the street, marked crossings are identifiable from
imagery.
- Because unmarked crossings are "fictions", they are only suggested places
to cross, according to the mapper. In contrast, marked crossings are
"official".
- Marked crossings confer safety and right-of-way information to both
pedestrian and street traffic: this is a place where pedestrians can cross,
so watch out.
- Marked crossings are one of the few pedestrian spaces that can be
straightforwardly considered as a linear feature: it connects spaces across
a street.
- Marked crossings tend to have legal implications, as you note.

Thus, when someone asks me, "what type of crossing is this?", my gut
reaction is to say "a crosswalk" or "not marked", potentially followed up
by a marking type if applicable. A marked crosswalk is a real,
"on-the-ground" thing whereas unmarked is a workaround for needing to
representing and use 2D spaces as lines.

I'd be curious to find some survey data regarding the importance of
pedestrian features that included crosswalks and signals. I could've sworn
I knew of one, but am having trouble finding it.

Best,

Nick

On Tue, May 7, 2019 at 3:08 PM Tobias Knerr  wrote:

> On 07.05.19 23:08, Nick Bolten wrote:
> > This proposal suggests the deprecation of crossing=traffic_signals and
> > replacing it with crossing:signals=yes, i.e. placing pedestrian
> > signalization on a dedicated tag that is separate from crossing=* values.
>
> I agree with separating orthogonal characteristics of crossings into
> different tags. A single tag cannot easily express both the presence of
> traffic signs and the presence of markings.
>
> However, it seems odd to "demote" traffic signals to a sub-tag when
> their presence or absence is perhaps the biggest influence on the
> crossing's overall character.
>
> In comparison, it seems somewhat less important whether a signalled
> crossing also has painted markings on the road. So I would suggest using
> a separate tag for the markings instead. We need a tag for the _type_ of
> the markings anyway (as different patterns for marked crossings can have
> entirely different legal meanings in some jurisdictions), and we can use
> that same tag for presence/absence by also allowing yes/no values.
>
> Tobias
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

> 1) You cannot deprecate a tagging that is used 750k times
(crossing=uncontrolled) or 570k times (crossing=traffic_signals)

This proposal does not deprecate crossing=uncontrolled.

For the latter: why not? The tag is, in technical terms, garbage, and other
tags in relatively high use have been deprecated before.

> 2) please  define the terms you use.
> What is "signalization"?
> I know these terms: traffic signals, road marking (=horizontal traffic
signs), signs (=vertical traffic signs), but signalization?

Visual displays for the specified form of traffic. Signalization for
automotive traffic might be stop signs or stop lights. Signalization for
pedestrians might be a crossing signal / do not cross sign.

Best,

Nick

On Tue, May 7, 2019 at 2:47 PM Volker Schmidt  wrote:

> Two spontanous reactions
>
> 1) You cannot deprecate a tagging that is used 750k times
> (crossing=uncontrolled) or 570k times (crossing=traffic_signals)
>
> 2) please  define the terms you use.
> What is "signalization"?
> I know these terms: traffic signals, road marking (=horizontal traffic
> signs), signs (=vertical traffic signs), but signalization?
>
>
>
>
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_49271051233384562_m_3715203604143881037_m_5214136548138821738_m_4990119247789359937_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> crossing=uncontrolled:
>>   - signalization for pedestrians is undefined
>>   - signalization for traffic *should* not exist, but due to confusions
>> over the meaning of the tag, might.
>>   - markings are implied, but due to confusions over the meaning of the
>> tag, might not not.
>>
>> crossing=unmarked:
>>   - signalization for pedestrians is undefined
>>   - signalization for traffic is undefined
>>   - there are no markings
>>
>> crossing=traffic_signals
>>   - signalization for pedestrians: yes
>>   - signalization for traffic is undefined
>>   - markings are undefined
>>
>> So, you can see the problem: the values are describing completely
>> different things and the rest is ambiguous.
>>
>> I'm interested in any/all feedback regarding this tag proposal! Thank you
>> for your time!
>>
>> Best,
>>
>> Nick
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_49271051233384562_m_3715203604143881037_m_5214136548138821738_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Tobias Knerr]

On 07.05.19 23:08, Nick Bolten wrote:
> This proposal suggests the deprecation of crossing=traffic_signals and
> replacing it with crossing:signals=yes, i.e. placing pedestrian
> signalization on a dedicated tag that is separate from crossing=* values.

I agree with separating orthogonal characteristics of crossings into
different tags. A single tag cannot easily express both the presence of
traffic signs and the presence of markings.

However, it seems odd to "demote" traffic signals to a sub-tag when
their presence or absence is perhaps the biggest influence on the
crossing's overall character.

In comparison, it seems somewhat less important whether a signalled
crossing also has painted markings on the road. So I would suggest using
a separate tag for the markings instead. We need a tag for the _type_ of
the markings anyway (as different patterns for marked crossings can have
entirely different legal meanings in some jurisdictions), and we can use
that same tag for presence/absence by also allowing yes/no values.

Tobias

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Volker Schmidt]

Two spontanous reactions

1) You cannot deprecate a tagging that is used 750k times
(crossing=uncontrolled) or 570k times (crossing=traffic_signals)

2) please  define the terms you use.
What is "signalization"?
I know these terms: traffic signals, road marking (=horizontal traffic
signs), signs (=vertical traffic signs), but signalization?








Virus-free.
www.avast.com

<#m_3715203604143881037_m_5214136548138821738_m_4990119247789359937_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


crossing=uncontrolled:
>   - signalization for pedestrians is undefined
>   - signalization for traffic *should* not exist, but due to confusions
> over the meaning of the tag, might.
>   - markings are implied, but due to confusions over the meaning of the
> tag, might not not.
>
> crossing=unmarked:
>   - signalization for pedestrians is undefined
>   - signalization for traffic is undefined
>   - there are no markings
>
> crossing=traffic_signals
>   - signalization for pedestrians: yes
>   - signalization for traffic is undefined
>   - markings are undefined
>
> So, you can see the problem: the values are describing completely
> different things and the rest is ambiguous.
>
> I'm interested in any/all feedback regarding this tag proposal! Thank you
> for your time!
>
> Best,
>
> Nick
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


Virus-free.
www.avast.com

<#m_3715203604143881037_m_5214136548138821738_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC (etc) for crossing:signals

[Nick Bolten]

https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:signals

Hello fellow tagging enthusiasts!

This proposal suggests the deprecation of crossing=traffic_signals and
replacing it with crossing:signals=yes, i.e. placing pedestrian
signalization on a dedicated tag that is separate from crossing=* values.

The current values for the crossing=* tag are not orthogonal:
crossing=traffic_signals is not actually orthogonal to
crossing=uncontrolled or crossing=unmarked, for example. This presents a
significant challenge to understanding the meaning of these tags and in
creating properly descriptive tags on map elements. For example, let's take
three attributes of a pedestrian crossing: signalization for pedestrians,
signalization for traffic, and markings on the ground. What do
crossing=uncontrolled/unmarked/traffic_signals say about these scenarios?

crossing=uncontrolled:
  - signalization for pedestrians is undefined
  - signalization for traffic *should* not exist, but due to confusions
over the meaning of the tag, might.
  - markings are implied, but due to confusions over the meaning of the
tag, might not not.

crossing=unmarked:
  - signalization for pedestrians is undefined
  - signalization for traffic is undefined
  - there are no markings

crossing=traffic_signals
  - signalization for pedestrians: yes
  - signalization for traffic is undefined
  - markings are undefined

So, you can see the problem: the values are describing completely different
things and the rest is ambiguous.

I'm interested in any/all feedback regarding this tag proposal! Thank you
for your time!

Best,

Nick
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging