Feature Proposal - RFC (etc) for crossing:signals

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

voschix
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


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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

Virus-free. www.avast.com

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Tordanik
In reply to this post by Nick Bolten
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Nick Bolten
In reply to this post by voschix
> 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 <[hidden email]> 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


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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

Virus-free. www.avast.com
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Nick Bolten
In reply to this post by Tordanik
> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Tagging mailing list
In reply to this post by voschix
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

dieterdreist
In reply to this post by Nick Bolten


sent from a phone

On 8. May 2019, at 00:54, Nick Bolten <[hidden email]> 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.

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

Cheers, Martin 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

marc marc
In reply to this post by Nick Bolten
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

marc marc
In reply to this post by Tordanik
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

marc marc
In reply to this post by Nick Bolten
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

marc marc
In reply to this post by dieterdreist
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Mateusz Konieczny-3
In reply to this post by Nick Bolten
8 May 2019, 01:30 by [hidden email]:
- 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Philip Barnes
In reply to this post by marc marc
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Joseph Eisenberg
In reply to this post by Mateusz Konieczny-3
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 <[hidden email]> wrote:
8 May 2019, 01:30 by [hidden email]:
- 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Paul Allen
In reply to this post by Philip Barnes
On Wed, 8 May 2019 at 10:42, Philip Barnes <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Paul Allen
On Wed, 8 May 2019 at 13:44, marc marc <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

dieterdreist
In reply to this post by marc marc


sent from a phone

On 8. May 2019, at 11:15, marc marc <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

dieterdreist
In reply to this post by marc marc


sent from a phone

On 8. May 2019, at 11:18, marc marc <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12