Feature Proposal - crossing=marked

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Feature Proposal - crossing=marked

Nick Bolten
https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dmarked

Hello, fellow tagging enthusiasts! At long last, and after many discussions on a variety of fora, I am putting this proposal forward in the hopes of getting feedback, making any necessary revisions, and then moving to a vote.

The motivation for changing how we tag pedestrian crossings has emerged from the collective experience of many mappers and teachers of OSM mapping (as well as developers of editors), where this is one of the primary challenges to coherently mapping pedestrian features: crossing=* tags have a ton of problems in terms of orthogonality, understandability by new and veteran mappers alike, and semantic correctness (which also impacts consumability). One of the primary confusions is the "uncontrolled" (and "zebra") values, which are, in effect, intended to mean that a crossing is "marked", but do not clearly communicate this fact to mappers, leading to all kinds of data issues and difficulties in explaining mapping to newcomers (and therefore getting good data).

While the proposal itself goes into detail about why crossing=marked is a good idea and other tags are a bad idea, this is the short version:
  - crossing=* values are not truly orthogonal and this needs to be addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are not truly orthogonal descriptors. This proposal is part of a larger effort to improve the values used for pedestrian crossings, but does not depend on that effort.
  - There is fragmentation in tag usage for marked crossings between "zebra" and "uncontrolled".
 - I believe that a significant portion of this fragmentation can be attributed to the unconventional use of the term "uncontrolled", which is technically incorrect, extremely jargon-y, and currently describes *two* things whereas other values for 'crossing' describe just one.
  - crossing=marked is direct and clear about its meaning and use cases.
  - crossing=marked is already in use and supported by various editors, including being the default in iD and an auto-filled option in JOSM.
  - crossing=marked has the potential for subtag uses, e.g. marked=zebra.
  - We can address fragmentation via machine edits and/or reviews using MapRoulette.

The primary goal of this proposal is to create truly orthogonal, descriptive, and intuitive tag values for markings on crossings. If related proposals are also accepted, the only values used on crossings would be marked/unmarked/no, with other attributes being namespaced tags (crossing:island, crossing:signals, etc), but acceptance of this proposal does not depend on those other proposals becoming accepted.

Please let me know any concerns you have regarding the impacts of this proposal or semantics. I'd like to make any ambiguities clear and have the proposal page be as thorough as possible.

Best,

Nick

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

Re: Feature Proposal - crossing=marked

marc marc
Le 07.05.19 à 22:57, Nick Bolten a écrit :
> - crossing=* values are not truly orthogonal and this needs to be
> addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
> not truly orthogonal descriptors.

I suggest that you read the discussion I started in December about
crossing=zebra because it is the main cause of the current situation.
Bryan replaced crossing=zebra with crossing=marked in iD but as the
crossing=zebra problems were not understood, the alternative has exactly
the same problems as the replaced solution.
the crossing key is however simple to use except for badly chosen values
does the passage have a fire? crossing=traffic_signals
otherwise, does the passage have a marking on the ground?
crossing=uncontrolled (the work is not perfect because a marking a kind
of controll)
otherwise crossing=unmarked

>    - There is fragmentation in tag usage for marked crossings between
> "zebra" and "uncontrolled".

Last year, I have review ~1k crossing=zebra,
the fragmentation is mainly due to iD

>    - crossing=marked is direct and clear about its meaning and use cases.

for now, the "new" iD preset destroys perfectly valid data
at a frightening rate!
if someone modifies a pedestrian crossing with a light, iD replaces it
with crossing=marked, which disrupts the information of the presence of
the light.
There is already a tag for the reference of a crossing.
if the reference is not known, it would be easy to use crossing_ref=yes
as it is done with many keys.

> - crossing=marked is already in use and supported by various editors,
> including being the default in iD

a bad preset is not a good usage

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

Re: Feature Proposal - crossing=marked

yo paseopor
I don't know why we need a new tag scheme.

I remember my explanation of the question and the adaptation of the possibilities. I repeat them here:

crossing=no (prohibited)
crossing=yes (most generic)

crossing=traffic_light is with traffic lights. So implies crossing=controlled.  
crossing=controlled is with traffic signs or with police people or similar (it does not matter the marks because of the laws. Traffic signs are more important than road marks, and, in conflict you have to obey the traffic sign not the road mark.) 
crossing=uncontrolled but with marks. So one of them implies crossing=uncontrolled
crossing=unmarked with no marks, with no control, but crossing

If there is a traffic island in the crossing you can tag traffic_calming=island (you can read in the wiki crossing=island is a  broken tagging scheme . 

And then there are the crossing_ref

zebra is marked but uncontrolled (if it is controlled you can use other value)
pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
pelican and panda is only with traffic lights .Pelican is the evolution of panda
tigger means bicycle=designated and toucan means bicycle=yes.
pegasus means horse=designated  
 (all of these are from U.K.)

But there is no crossing=zebra or crossing=marked.
I know some editor software and renders are very important for OSM, but doing whatever you want avoiding community consensus can generate these problems.
Are you sure we need a new tagging scheme for crossings? Are you sure there is not other existing way to map whatever you want with the present tagging scheme?

I don't think so
Health and maps (Salut i mapes)
yopaseopor


On Wed, May 8, 2019 at 10:51 AM marc marc <[hidden email]> wrote:
Le 07.05.19 à 22:57, Nick Bolten a écrit :
> - crossing=* values are not truly orthogonal and this needs to be
> addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
> not truly orthogonal descriptors.

I suggest that you read the discussion I started in December about
crossing=zebra because it is the main cause of the current situation.
Bryan replaced crossing=zebra with crossing=marked in iD but as the
crossing=zebra problems were not understood, the alternative has exactly
the same problems as the replaced solution.
the crossing key is however simple to use except for badly chosen values
does the passage have a fire? crossing=traffic_signals
otherwise, does the passage have a marking on the ground?
crossing=uncontrolled (the work is not perfect because a marking a kind
of controll)
otherwise crossing=unmarked

>    - There is fragmentation in tag usage for marked crossings between
> "zebra" and "uncontrolled".

Last year, I have review ~1k crossing=zebra,
the fragmentation is mainly due to iD

>    - crossing=marked is direct and clear about its meaning and use cases.

for now, the "new" iD preset destroys perfectly valid data
at a frightening rate!
if someone modifies a pedestrian crossing with a light, iD replaces it
with crossing=marked, which disrupts the information of the presence of
the light.
There is already a tag for the reference of a crossing.
if the reference is not known, it would be easy to use crossing_ref=yes
as it is done with many keys.

> - crossing=marked is already in use and supported by various editors,
> including being the default in iD

a bad preset is not a good usage

Regards,
Marc
_______________________________________________
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 - crossing=marked

marc marc
Le 08.05.19 à 19:37, yo paseopor a écrit :
> zebra is marked but uncontrolled (if it is controlled you can use other
> value)

but if you see a zebra with satellite image, you often have no idea if a
the crossing have a traffic light or not in a lot of country (like in
Belgium/France/Luxembourg/Switzerland)

that's why I proposed that iD change its preset: if someone sees a zebra
on a satellite image, the only thing that can be added is
crossing_ref=zebra. crossing=zebra does not allow incremential mapping
(= one user add info from sat, another user add info from survey)
that's why it doesn't make sense to have the type of marking in the same
tag as the one that talks about the presence of a light.
unfortunately both the previous preset and the current one lead to the
destruction (voluntary since the author has been warned for a long time)
of the crossing=traffic_signals sometimes already present.
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature Proposal - crossing=marked

Graeme Fitzpatrick
In reply to this post by yo paseopor


On Thu, 9 May 2019 at 03:38, yo paseopor <[hidden email]> wrote:
zebra is marked but uncontrolled

Maybe (quite possibly!) I'm getting confused over the whole controlled / uncontrolled concept?

I thought that controlled means that their is signage / indication of some form that says a driver has to stop to allow pedestrians to cross; while uncontrolled basically equals unmarked - there is provision made (gutter ramps etc) to allow people to easily cross the road, but there are no crossing markings of any sort eg 

Now we may (yet again!) be getting caught up in the one-word-different-meanings-worldwide saga, but, in Australia at least, "zebra" crossings (parallel alternating black & white stripes crossing the road) are controlled - they signify a pedestrian crossing & drivers must stop & give way to any pedestrians on or approaching the crossing.

So are there different rules elsewhere, so that you can say "zebra is marked but uncontrolled"?

Thanks

Graeme

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

Re: Feature Proposal - crossing=marked

Clifford Snow


On Wed, May 8, 2019 at 2:48 PM Graeme Fitzpatrick <[hidden email]> wrote:

Now we may (yet again!) be getting caught up in the one-word-different-meanings-worldwide saga, but, in Australia at least, "zebra" crossings (parallel alternating black & white stripes crossing the road) are controlled - they signify a pedestrian crossing & drivers must stop & give way to any pedestrians on or approaching the crossing.

So are there different rules elsewhere, so that you can say "zebra is marked but uncontrolled"?

Where I live in the US, Washington State, a pedestrian has the right of way at any intersection unless otherwise indicated. Other places the pedestrian only has the right of way in marked crossings.  But a marked crossing doesn't necessarily mean controlled. To me that means some sort of signal. Similar to the way we tag supervised crossings  highway=crossing + crossing=* as appropriate + supervised=yes

Best,
Clifford
--
@osm_washington
OpenStreetMap: Maps with a human touch

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

Re: Feature Proposal - crossing=marked

sdoerr
In reply to this post by Graeme Fitzpatrick
On 08/05/2019 22:48, Graeme Fitzpatrick wrote:
> I thought that controlled means that their is signage / indication of
> some form that says a driver has to stop to allow pedestrians to cross

I would take it to be more than that: something that controls *when* the
vehicles have priority and when the pedestrians do. A zebra crossing in
the UK is uncontrolled, and a signal-controlled crossing is, er,
controlled by signals. Maybe a lollipop lady would also be a controlled
crossing (but only at certain times of day).

--
Steve

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: Feature Proposal - crossing=marked

Nick Bolten
In reply to this post by marc marc
> I suggest that you read the discussion I started in December about crossing=zebra because it is the main cause of the current situation.

I read it back in December, but I disagree. The cause of the situation is the huge problems with the crossing=* values for marked crossings. That problem also caused the iD editor to use its zebra and now marked presets.

> Bryan replaced crossing=zebra with crossing=marked in iD but as the crossing=zebra problems were not understood, the alternative has exactly the same problems as the replaced solution.

Such as...?

> the crossing key is however simple to use except for badly chosen values does the passage have a fire? crossing=traffic_signals otherwise, does the passage have a marking on the ground?  crossing=uncontrolled (the work is not perfect because a marking a kind of controll) otherwise crossing=unmarked

I don't understand what you're saying here (fire?), but would be interested in knowing what you mean. Could you please rephrase?

> Last year, I have review ~1k crossing=zebra, the fragmentation is mainly due to iD

I'd expect quite a few tags to come from iD, as it's the default editor on openstreetmap.org, of course. I'm curious about your methodology, since I don't remember seeing this in that December thread. How did you sample? What were the results?

> for now, the "new" iD preset destroys perfectly valid data at a frightening rate! if someone modifies a pedestrian crossing with a light, iD replaces it 
with crossing=marked, which disrupts the information of the presence of the light.

This is not relevant to my proposal. Please keep unrelated gripes regarding editors to another thread.

> There is already a tag for the reference of a crossing.

I'm aware. Please read my proposal, where I explicitly discuss this.

> a bad preset is not a good usage

Please explain why it's a bad preset.

Best,

Nick

On Wed, May 8, 2019 at 1:51 AM marc marc <[hidden email]> wrote:
Le 07.05.19 à 22:57, Nick Bolten a écrit :
> - crossing=* values are not truly orthogonal and this needs to be
> addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
> not truly orthogonal descriptors.

I suggest that you read the discussion I started in December about
crossing=zebra because it is the main cause of the current situation.
Bryan replaced crossing=zebra with crossing=marked in iD but as the
crossing=zebra problems were not understood, the alternative has exactly
the same problems as the replaced solution.
the crossing key is however simple to use except for badly chosen values
does the passage have a fire? crossing=traffic_signals
otherwise, does the passage have a marking on the ground?
crossing=uncontrolled (the work is not perfect because a marking a kind
of controll)
otherwise crossing=unmarked

>    - There is fragmentation in tag usage for marked crossings between
> "zebra" and "uncontrolled".

Last year, I have review ~1k crossing=zebra,
the fragmentation is mainly due to iD

>    - crossing=marked is direct and clear about its meaning and use cases.

for now, the "new" iD preset destroys perfectly valid data
at a frightening rate!
if someone modifies a pedestrian crossing with a light, iD replaces it
with crossing=marked, which disrupts the information of the presence of
the light.
There is already a tag for the reference of a crossing.
if the reference is not known, it would be easy to use crossing_ref=yes
as it is done with many keys.

> - crossing=marked is already in use and supported by various editors,
> including being the default in iD

a bad preset is not a good usage

Regards,
Marc
_______________________________________________
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 - crossing=marked

Nick Bolten
In reply to this post by yo paseopor
> I don't know why we need a new tag scheme.

Please check out my proposal, as I've laid out several reasons. As someone who has personally mapped thousands of crossings, the current schema is absolute garbage for reliably collecting accurate data that can be reliably interpreted by data consumers that aren't solely focused on car routing. It is also virtually impossible for any new user to know what tags to use and what they mean. You can see in this thread as well as the one in my other proposal regarding signals that even veteran, expert OSM users have different ideas on what "crossing=uncontrolled" means.

> crossing=no (prohibited)
> crossing=yes (most generic)
> crossing=traffic_light is with traffic lights. So implies crossing=controlled.  
> crossing=controlled is with traffic signs or with police people or similar (it does not matter the marks because of the laws. Traffic signs are more important than road marks, and, in conflict you have to obey the traffic sign not the road mark.) 

This proposal only concerns crossing=uncontrolled (as well as the still-in-use crossing=zebra).

> crossing=uncontrolled but with marks. So one of them implies crossing=uncontrolled

I don't understand what you mean by "so one of them implies crossing=uncontrolled"? Are you saying that all crossings with markings should be tagged, "uncontrolled"? What if they have pedestrian signal lights? That's a crossing that has both, implying a contradiction.

Note that crossing=traffic_light does not imply whether there are markings on the ground. That's the whole problem: these tags cover information regarding at least 3 discrete categories of information, but do not themselves contain the full gamut of combinations nor even all 3 in every value: (1) markings on the ground, (2) the "controlled" status, and (3) the existence of a pedestrian signal. These should be separate questions a mapper can easily answer: does the crossing have markings? Does the crossing have a pedestrian signal? Does the crossing have a "controlled" status (or, perhaps better, this can be inferred from other properties like crossing_ref, because nobody has any idea what "controlled" means, apparently)?

> If there is a traffic island in the crossing you can tag traffic_calming=island (you can read in the wiki crossing=island is a  broken tagging scheme . 

Yes, and I'm thankful that SelfishSeahorse led the effort to fix that tag. The two proposals I've announced are related to breaking out these non-orthogonal crossings tags, similar to crossing=island. However, traffic_calming=island describes the island itself. For a pedestrian way, use crossing:island=yes.

> And then there are the crossing_ref

This is outside the scope of this proposal, aside from the fact that if crossing=marked is used, it creates an opportunity to use a straightforward subtag for different marking types that are currently tagged as crossing_ref. Try explaining to virtually anyone why the crossing type is called, "crossing_ref". What's a ref? What does it mean to apply a ref to a crossing? With that said, this proposal does not hinge on this, it's just an opportunity for a different proposal down the line.

> But there is no crossing=zebra or crossing=marked.

I mean, they are in current use, but putting that aside, that is the point of this proposal: we should be using a specific tag for markings.

> I know some editor software and renders are very important for OSM, but doing whatever you want avoiding community consensus can generate these problems.

I'm attempting to build community consensus by writing a proposal and then explaining it on this mailing list.

> Are you sure we need a new tagging scheme for crossings?

I am absolutely positive.

> Are you sure there is not other existing way to map whatever you want with the present tagging scheme?

Yes, and I've tried many, many times.

Best,

Nick

On Wed, May 8, 2019 at 10:38 AM yo paseopor <[hidden email]> wrote:
I don't know why we need a new tag scheme.

I remember my explanation of the question and the adaptation of the possibilities. I repeat them here:

crossing=no (prohibited)
crossing=yes (most generic)

crossing=traffic_light is with traffic lights. So implies crossing=controlled.  
crossing=controlled is with traffic signs or with police people or similar (it does not matter the marks because of the laws. Traffic signs are more important than road marks, and, in conflict you have to obey the traffic sign not the road mark.) 
crossing=uncontrolled but with marks. So one of them implies crossing=uncontrolled
crossing=unmarked with no marks, with no control, but crossing

If there is a traffic island in the crossing you can tag traffic_calming=island (you can read in the wiki crossing=island is a  broken tagging scheme . 

And then there are the crossing_ref

zebra is marked but uncontrolled (if it is controlled you can use other value)
pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
pelican and panda is only with traffic lights .Pelican is the evolution of panda
tigger means bicycle=designated and toucan means bicycle=yes.
pegasus means horse=designated  
 (all of these are from U.K.)

But there is no crossing=zebra or crossing=marked.
I know some editor software and renders are very important for OSM, but doing whatever you want avoiding community consensus can generate these problems.
Are you sure we need a new tagging scheme for crossings? Are you sure there is not other existing way to map whatever you want with the present tagging scheme?

I don't think so
Health and maps (Salut i mapes)
yopaseopor


On Wed, May 8, 2019 at 10:51 AM marc marc <[hidden email]> wrote:
Le 07.05.19 à 22:57, Nick Bolten a écrit :
> - crossing=* values are not truly orthogonal and this needs to be
> addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
> not truly orthogonal descriptors.

I suggest that you read the discussion I started in December about
crossing=zebra because it is the main cause of the current situation.
Bryan replaced crossing=zebra with crossing=marked in iD but as the
crossing=zebra problems were not understood, the alternative has exactly
the same problems as the replaced solution.
the crossing key is however simple to use except for badly chosen values
does the passage have a fire? crossing=traffic_signals
otherwise, does the passage have a marking on the ground?
crossing=uncontrolled (the work is not perfect because a marking a kind
of controll)
otherwise crossing=unmarked

>    - There is fragmentation in tag usage for marked crossings between
> "zebra" and "uncontrolled".

Last year, I have review ~1k crossing=zebra,
the fragmentation is mainly due to iD

>    - crossing=marked is direct and clear about its meaning and use cases.

for now, the "new" iD preset destroys perfectly valid data
at a frightening rate!
if someone modifies a pedestrian crossing with a light, iD replaces it
with crossing=marked, which disrupts the information of the presence of
the light.
There is already a tag for the reference of a crossing.
if the reference is not known, it would be easy to use crossing_ref=yes
as it is done with many keys.

> - crossing=marked is already in use and supported by various editors,
> including being the default in iD

a bad preset is not a good usage

Regards,
Marc
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
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 - crossing=marked

Nick Bolten
In reply to this post by sdoerr
This subthread is doing a good job of showing why "uncontrolled" is opaque to users and mappers, as it is primarily an issue of local legal questions and not physical, on-the-ground features, despite the fact that "uncontrolled" in OSM is meant to also describe those (like markings). Because it's a matter of local legal matters, whether a crossing is "controlled" varies from city to city, county to county, region to region, country to country - yet mappers are asked to describe any crossing that has markings but no "traffic signals" are "uncontrolled".

I would be surprised if the vast majority of people could certainly describe whether a particular crossing, even one one a block away from their residence, is "controlled". First, I'd expect wildy varying definitions of what the word means, with most people saying, "I have no idea". Second, if you asked them a question like, "who has the right of way at a marked crossing? How about unmarked?", I expect similar disagreement and lack of certainty.

The use within OSM even disagrees with the definitions available at what I assume are the primary sources of this nomenclature, where the crossing itself does not necessarily have any markings whatsoever, but simply lacks all forms of controls.

On Thu, May 9, 2019 at 1:46 AM Steve Doerr <[hidden email]> wrote:
On 08/05/2019 22:48, Graeme Fitzpatrick wrote:
> I thought that controlled means that their is signage / indication of
> some form that says a driver has to stop to allow pedestrians to cross

I would take it to be more than that: something that controls *when* the
vehicles have priority and when the pedestrians do. A zebra crossing in
the UK is uncontrolled, and a signal-controlled crossing is, er,
controlled by signals. Maybe a lollipop lady would also be a controlled
crossing (but only at certain times of day).

--
Steve

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
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 - crossing=marked

yo paseopor
In reply to this post by Nick Bolten
I have checked out your proposal...and I don't know what is the difference with a crossing=marked (yours) and a crossing=uncontrolled (in OSM)
I don't agree with you. I think you are forgotten all the other items to tag and the others tagging schemes in OSM. Kerbs are not for cars, cycleways are not for cars. And there are other traffic lights rather than car traffic lights.

> It is also virtually impossible for any new user to know what tags to use and what they mean
It is not true. There is a wiki and also a iD which can help to undesrtand the tagging scheme and making easier to tag that crossing.

> This proposal only concerns crossing=uncontrolled (as well as the still-in-use crossing=zebra)
What is the proposal: translate crossing=uncontrolled to crossing=marked?

> Are you saying that all crossings with markings should be tagged, "uncontrolled"?
If there is not any control of the crossing...yes otherwise should be crossing=traffic_signals or supervised=yes as you can read in the wiki.

> Note that crossing=traffic_light does not imply whether there are markings on the ground
Well, in my country it is, when there is a traffic signals with pedestrian traffic signal there is a crossing=traffic_signals. Otherwise is crossing=no because there is no crossing at all.

>does the crossing have markings? Does the crossing have a pedestrian signal? Does the crossing have a "controlled" status (or, perhaps better, this can be inferred from other properties like crossing_ref, because nobody has any idea what "controlled" means, apparently)?

Change the questions:
-Is there any traffic signal in the crossing?
-Is there any supervision in the crossing?
-Is there any mark in the crossing?

A crossing=marked would not inform if it is supervised, and also if is there a pedestrian traffic signal controlled crossing.

> However, traffic_calming=island describes the island itself. For a pedestrian way, use crossing:island=yes
No , for a pedestrian way which passes inside an island I have footway=crossing because there si a footway inside a island. I don't need a tag which says things I can see in the situation for the map. It is the same reason I don't need crossing=marked if I have crossing=uncontrolled. Mark is not a control.

> I mean, they are in current use, but putting that aside, that is the point of this proposal: we should be using a specific tag for markings.
Well, we have it and it is called crossing_ref.

> I'm attempting to build community consensus by writing a proposal and then explaining it on this mailing list.
I was talking about crossing=zebra issue.

> Yes, and I've tried many, many times.
Tell me one situation you cannot map in detail with present tagging scheme.

This is my point of view.
Health and maps (Salut i mapes)
yopaseopor

On Thu, May 9, 2019 at 5:50 PM Nick Bolten <[hidden email]> wrote:
> I don't know why we need a new tag scheme.

Please check out my proposal, as I've laid out several reasons. As someone who has personally mapped thousands of crossings, the current schema is absolute garbage for reliably collecting accurate data that can be reliably interpreted by data consumers that aren't solely focused on car routing. It is also virtually impossible for any new user to know what tags to use and what they mean. You can see in this thread as well as the one in my other proposal regarding signals that even veteran, expert OSM users have different ideas on what "crossing=uncontrolled" means.

> crossing=no (prohibited)
> crossing=yes (most generic)
> crossing=traffic_light is with traffic lights. So implies crossing=controlled.  
> crossing=controlled is with traffic signs or with police people or similar (it does not matter the marks because of the laws. Traffic signs are more important than road marks, and, in conflict you have to obey the traffic sign not the road mark.) 

This proposal only concerns crossing=uncontrolled (as well as the still-in-use crossing=zebra).

> crossing=uncontrolled but with marks. So one of them implies crossing=uncontrolled

I don't understand what you mean by "so one of them implies crossing=uncontrolled"? Are you saying that all crossings with markings should be tagged, "uncontrolled"? What if they have pedestrian signal lights? That's a crossing that has both, implying a contradiction.

Note that crossing=traffic_light does not imply whether there are markings on the ground. That's the whole problem: these tags cover information regarding at least 3 discrete categories of information, but do not themselves contain the full gamut of combinations nor even all 3 in every value: (1) markings on the ground, (2) the "controlled" status, and (3) the existence of a pedestrian signal. These should be separate questions a mapper can easily answer: does the crossing have markings? Does the crossing have a pedestrian signal? Does the crossing have a "controlled" status (or, perhaps better, this can be inferred from other properties like crossing_ref, because nobody has any idea what "controlled" means, apparently)?

> If there is a traffic island in the crossing you can tag traffic_calming=island (you can read in the wiki crossing=island is a  broken tagging scheme . 

Yes, and I'm thankful that SelfishSeahorse led the effort to fix that tag. The two proposals I've announced are related to breaking out these non-orthogonal crossings tags, similar to crossing=island. However, traffic_calming=island describes the island itself. For a pedestrian way, use crossing:island=yes.

> And then there are the crossing_ref

This is outside the scope of this proposal, aside from the fact that if crossing=marked is used, it creates an opportunity to use a straightforward subtag for different marking types that are currently tagged as crossing_ref. Try explaining to virtually anyone why the crossing type is called, "crossing_ref". What's a ref? What does it mean to apply a ref to a crossing? With that said, this proposal does not hinge on this, it's just an opportunity for a different proposal down the line.

> But there is no crossing=zebra or crossing=marked.

I mean, they are in current use, but putting that aside, that is the point of this proposal: we should be using a specific tag for markings.

> I know some editor software and renders are very important for OSM, but doing whatever you want avoiding community consensus can generate these problems.

I'm attempting to build community consensus by writing a proposal and then explaining it on this mailing list.

> Are you sure we need a new tagging scheme for crossings?

I am absolutely positive.

> Are you sure there is not other existing way to map whatever you want with the present tagging scheme?

Yes, and I've tried many, many times.

Best,

Nick

On Wed, May 8, 2019 at 10:38 AM yo paseopor <[hidden email]> wrote:
I don't know why we need a new tag scheme.

I remember my explanation of the question and the adaptation of the possibilities. I repeat them here:

crossing=no (prohibited)
crossing=yes (most generic)

crossing=traffic_light is with traffic lights. So implies crossing=controlled.  
crossing=controlled is with traffic signs or with police people or similar (it does not matter the marks because of the laws. Traffic signs are more important than road marks, and, in conflict you have to obey the traffic sign not the road mark.) 
crossing=uncontrolled but with marks. So one of them implies crossing=uncontrolled
crossing=unmarked with no marks, with no control, but crossing

If there is a traffic island in the crossing you can tag traffic_calming=island (you can read in the wiki crossing=island is a  broken tagging scheme . 

And then there are the crossing_ref

zebra is marked but uncontrolled (if it is controlled you can use other value)
pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
pelican and panda is only with traffic lights .Pelican is the evolution of panda
tigger means bicycle=designated and toucan means bicycle=yes.
pegasus means horse=designated  
 (all of these are from U.K.)

But there is no crossing=zebra or crossing=marked.
I know some editor software and renders are very important for OSM, but doing whatever you want avoiding community consensus can generate these problems.
Are you sure we need a new tagging scheme for crossings? Are you sure there is not other existing way to map whatever you want with the present tagging scheme?

I don't think so
Health and maps (Salut i mapes)
yopaseopor


On Wed, May 8, 2019 at 10:51 AM marc marc <[hidden email]> wrote:
Le 07.05.19 à 22:57, Nick Bolten a écrit :
> - crossing=* values are not truly orthogonal and this needs to be
> addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
> not truly orthogonal descriptors.

I suggest that you read the discussion I started in December about
crossing=zebra because it is the main cause of the current situation.
Bryan replaced crossing=zebra with crossing=marked in iD but as the
crossing=zebra problems were not understood, the alternative has exactly
the same problems as the replaced solution.
the crossing key is however simple to use except for badly chosen values
does the passage have a fire? crossing=traffic_signals
otherwise, does the passage have a marking on the ground?
crossing=uncontrolled (the work is not perfect because a marking a kind
of controll)
otherwise crossing=unmarked

>    - There is fragmentation in tag usage for marked crossings between
> "zebra" and "uncontrolled".

Last year, I have review ~1k crossing=zebra,
the fragmentation is mainly due to iD

>    - crossing=marked is direct and clear about its meaning and use cases.

for now, the "new" iD preset destroys perfectly valid data
at a frightening rate!
if someone modifies a pedestrian crossing with a light, iD replaces it
with crossing=marked, which disrupts the information of the presence of
the light.
There is already a tag for the reference of a crossing.
if the reference is not known, it would be easy to use crossing_ref=yes
as it is done with many keys.

> - crossing=marked is already in use and supported by various editors,
> including being the default in iD

a bad preset is not a good usage

Regards,
Marc
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
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 - crossing=marked

dieterdreist
In reply to this post by Nick Bolten


sent from a phone

> On 7. May 2019, at 22:57, Nick Bolten <[hidden email]> wrote:
>
> One of the primary confusions is the "uncontrolled" (and "zebra") values, which are, in effect, intended to mean that a crossing is "marked"


they are also intended to mean: not controlled by a traffic light (while „marked“ likely would include traffic light crossings)


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

Re: Feature Proposal - crossing=marked

Nick Bolten
> they are also intended to mean: not controlled by a traffic light (while „marked“ likely would include traffic light crossings)

Yes, but a traffic light for whom? I've seen mappers who assume it means "walk"/"do not walk" lights like this: https://commons.wikimedia.org/wiki/File:Do_Not_Walk_sign,_Great_Neck,_New_York.jpg. I've seen mappers who assume it means there is a sign *just* to warn traffic about pedestrians, as can be found in the UK. I've seen mappers who assume it means there is a nearby traffic light that means cars sometimes stop at this location, but it doesn't say anything about having a "walk"/"do not walk" sign.

The wiki only says, "Position this tag where the crossing-traffic (pedestrian, bicycles) have their own traffic lights.". Pedestrians having "their own" traffic lights would seem to imply the lights are specific to the crossing and not that cross-traffic has to stop sometimes, but it does not say which type of traffic light: cross-traffic (cars) or pedestrian traffic. I've tended to assume it's the former, but have run into many, many mappers who think it's the latter.

I tend to avoid mapping it at all because I don't want to add ambiguous data to the map.

On Thu, May 9, 2019 at 2:52 PM Martin Koppenhoefer <[hidden email]> wrote:


sent from a phone

> On 7. May 2019, at 22:57, Nick Bolten <[hidden email]> wrote:
>
> One of the primary confusions is the "uncontrolled" (and "zebra") values, which are, in effect, intended to mean that a crossing is "marked"


they are also intended to mean: not controlled by a traffic light (while „marked“ likely would include traffic light crossings)


Cheers, Martin
_______________________________________________
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 - crossing=marked

Nick Bolten
In reply to this post by yo paseopor
> I have checked out your proposal...and I don't know what is the difference with a crossing=marked (yours) and a crossing=uncontrolled (in OSM)

crossing=marked indicates that a crossing has markings. That's it: the "type" of crossing is declared to be whether it has markings on the ground or not.

crossing=uncontrolled has very unclear meanings. You can see from this and the thread about crossing:signals=* that there are at least 4 different definitions used by veteran-ish OSM mappers, despite most of them saying "of course it means my version". To expound, there are multiple ways in which "uncontrolled" has problems in terms of understanding meaning: 

(1) The term "uncontrolled" is a transit nerd term. Almost nobody uses this word outside of a select few circles. New mappers have no idea what it means (though veteran mappers also seem to disagree with one another) and make an *incorrect* guess, assuming it means the same as unmarked.

(2)  the crossing tag, as currently documented, has values that imply meanings regarding right-of-way, markings on the ground, and pedestrian/traffic signals (it's hard to tell what the latter even means, honestly, which is why I have that proposal). That's three totally different categories that are meant to be summed up in one tag value and the current values don't even cover the full combination. "uncontrolled" does not actually say anything about right-of-way, per the OpenStreetMap wiki.

(3) However, the real-world meaning of "uncontrolled" is entirely about right-of-way based on "controls" for street traffic. Essentially, it's the polar opposite of the OpenStreetMap usage. Anyone who attempts to look up the term "uncontrolled" outside of the OpenStreetMap will come away with the exact wrong meaning and map the data incorrectly.

> I don't agree with you. I think you are forgotten all the other items to tag and the others tagging schemes in OSM. Kerbs are not for cars, cycleways are not for cars. And there are other traffic lights rather than car traffic lights.

I don't think I understand what you mean by this. Could you please rephrase?

> It is not true. There is a wiki and also a iD which can help to undesrtand the tagging scheme and making easier to tag that crossing.

The iD editor never uses crossing=uncontrolled. It actually uses crossing=marked now. It is at odds with the wiki, and what the wiki says is very different from what many people on this mailing list say crossing=uncontrolled means.

> What is the proposal: translate crossing=uncontrolled to crossing=marked?

Only after robust discussion with local communities and with their approval. I am not recommending any automated edits whatsoever as part of this proposal, only suggesting that it might be possible in limited regions, with community assent (and following all of the other protocols regarding machine edits). I anticipate that many US-based communities would be open to converting crossing=uncontrolled and crossing=zebra to crossing=marked, at a minimum, given how frequently they've been edited with iD.



I split this message in two because it was too long - I'm sending another reply shortly.

On Thu, May 9, 2019 at 2:26 PM yo paseopor <[hidden email]> wrote:
I have checked out your proposal...and I don't know what is the difference with a crossing=marked (yours) and a crossing=uncontrolled (in OSM)
I don't agree with you. I think you are forgotten all the other items to tag and the others tagging schemes in OSM. Kerbs are not for cars, cycleways are not for cars. And there are other traffic lights rather than car traffic lights.

> It is also virtually impossible for any new user to know what tags to use and what they mean
It is not true. There is a wiki and also a iD which can help to undesrtand the tagging scheme and making easier to tag that crossing.

> This proposal only concerns crossing=uncontrolled (as well as the still-in-use crossing=zebra)
What is the proposal: translate crossing=uncontrolled to crossing=marked?

> Are you saying that all crossings with markings should be tagged, "uncontrolled"?
If there is not any control of the crossing...yes otherwise should be crossing=traffic_signals or supervised=yes as you can read in the wiki.

> Note that crossing=traffic_light does not imply whether there are markings on the ground
Well, in my country it is, when there is a traffic signals with pedestrian traffic signal there is a crossing=traffic_signals. Otherwise is crossing=no because there is no crossing at all.

>does the crossing have markings? Does the crossing have a pedestrian signal? Does the crossing have a "controlled" status (or, perhaps better, this can be inferred from other properties like crossing_ref, because nobody has any idea what "controlled" means, apparently)?

Change the questions:
-Is there any traffic signal in the crossing?
-Is there any supervision in the crossing?
-Is there any mark in the crossing?

A crossing=marked would not inform if it is supervised, and also if is there a pedestrian traffic signal controlled crossing.

> However, traffic_calming=island describes the island itself. For a pedestrian way, use crossing:island=yes
No , for a pedestrian way which passes inside an island I have footway=crossing because there si a footway inside a island. I don't need a tag which says things I can see in the situation for the map. It is the same reason I don't need crossing=marked if I have crossing=uncontrolled. Mark is not a control.

> I mean, they are in current use, but putting that aside, that is the point of this proposal: we should be using a specific tag for markings.
Well, we have it and it is called crossing_ref.

> I'm attempting to build community consensus by writing a proposal and then explaining it on this mailing list.
I was talking about crossing=zebra issue.

> Yes, and I've tried many, many times.
Tell me one situation you cannot map in detail with present tagging scheme.

This is my point of view.
Health and maps (Salut i mapes)
yopaseopor

On Thu, May 9, 2019 at 5:50 PM Nick Bolten <[hidden email]> wrote:
> I don't know why we need a new tag scheme.

Please check out my proposal, as I've laid out several reasons. As someone who has personally mapped thousands of crossings, the current schema is absolute garbage for reliably collecting accurate data that can be reliably interpreted by data consumers that aren't solely focused on car routing. It is also virtually impossible for any new user to know what tags to use and what they mean. You can see in this thread as well as the one in my other proposal regarding signals that even veteran, expert OSM users have different ideas on what "crossing=uncontrolled" means.

> crossing=no (prohibited)
> crossing=yes (most generic)
> crossing=traffic_light is with traffic lights. So implies crossing=controlled.  
> crossing=controlled is with traffic signs or with police people or similar (it does not matter the marks because of the laws. Traffic signs are more important than road marks, and, in conflict you have to obey the traffic sign not the road mark.) 

This proposal only concerns crossing=uncontrolled (as well as the still-in-use crossing=zebra).

> crossing=uncontrolled but with marks. So one of them implies crossing=uncontrolled

I don't understand what you mean by "so one of them implies crossing=uncontrolled"? Are you saying that all crossings with markings should be tagged, "uncontrolled"? What if they have pedestrian signal lights? That's a crossing that has both, implying a contradiction.

Note that crossing=traffic_light does not imply whether there are markings on the ground. That's the whole problem: these tags cover information regarding at least 3 discrete categories of information, but do not themselves contain the full gamut of combinations nor even all 3 in every value: (1) markings on the ground, (2) the "controlled" status, and (3) the existence of a pedestrian signal. These should be separate questions a mapper can easily answer: does the crossing have markings? Does the crossing have a pedestrian signal? Does the crossing have a "controlled" status (or, perhaps better, this can be inferred from other properties like crossing_ref, because nobody has any idea what "controlled" means, apparently)?

> If there is a traffic island in the crossing you can tag traffic_calming=island (you can read in the wiki crossing=island is a  broken tagging scheme . 

Yes, and I'm thankful that SelfishSeahorse led the effort to fix that tag. The two proposals I've announced are related to breaking out these non-orthogonal crossings tags, similar to crossing=island. However, traffic_calming=island describes the island itself. For a pedestrian way, use crossing:island=yes.

> And then there are the crossing_ref

This is outside the scope of this proposal, aside from the fact that if crossing=marked is used, it creates an opportunity to use a straightforward subtag for different marking types that are currently tagged as crossing_ref. Try explaining to virtually anyone why the crossing type is called, "crossing_ref". What's a ref? What does it mean to apply a ref to a crossing? With that said, this proposal does not hinge on this, it's just an opportunity for a different proposal down the line.

> But there is no crossing=zebra or crossing=marked.

I mean, they are in current use, but putting that aside, that is the point of this proposal: we should be using a specific tag for markings.

> I know some editor software and renders are very important for OSM, but doing whatever you want avoiding community consensus can generate these problems.

I'm attempting to build community consensus by writing a proposal and then explaining it on this mailing list.

> Are you sure we need a new tagging scheme for crossings?

I am absolutely positive.

> Are you sure there is not other existing way to map whatever you want with the present tagging scheme?

Yes, and I've tried many, many times.

Best,

Nick

On Wed, May 8, 2019 at 10:38 AM yo paseopor <[hidden email]> wrote:
I don't know why we need a new tag scheme.

I remember my explanation of the question and the adaptation of the possibilities. I repeat them here:

crossing=no (prohibited)
crossing=yes (most generic)

crossing=traffic_light is with traffic lights. So implies crossing=controlled.  
crossing=controlled is with traffic signs or with police people or similar (it does not matter the marks because of the laws. Traffic signs are more important than road marks, and, in conflict you have to obey the traffic sign not the road mark.) 
crossing=uncontrolled but with marks. So one of them implies crossing=uncontrolled
crossing=unmarked with no marks, with no control, but crossing

If there is a traffic island in the crossing you can tag traffic_calming=island (you can read in the wiki crossing=island is a  broken tagging scheme . 

And then there are the crossing_ref

zebra is marked but uncontrolled (if it is controlled you can use other value)
pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
pelican and panda is only with traffic lights .Pelican is the evolution of panda
tigger means bicycle=designated and toucan means bicycle=yes.
pegasus means horse=designated  
 (all of these are from U.K.)

But there is no crossing=zebra or crossing=marked.
I know some editor software and renders are very important for OSM, but doing whatever you want avoiding community consensus can generate these problems.
Are you sure we need a new tagging scheme for crossings? Are you sure there is not other existing way to map whatever you want with the present tagging scheme?

I don't think so
Health and maps (Salut i mapes)
yopaseopor


On Wed, May 8, 2019 at 10:51 AM marc marc <[hidden email]> wrote:
Le 07.05.19 à 22:57, Nick Bolten a écrit :
> - crossing=* values are not truly orthogonal and this needs to be
> addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
> not truly orthogonal descriptors.

I suggest that you read the discussion I started in December about
crossing=zebra because it is the main cause of the current situation.
Bryan replaced crossing=zebra with crossing=marked in iD but as the
crossing=zebra problems were not understood, the alternative has exactly
the same problems as the replaced solution.
the crossing key is however simple to use except for badly chosen values
does the passage have a fire? crossing=traffic_signals
otherwise, does the passage have a marking on the ground?
crossing=uncontrolled (the work is not perfect because a marking a kind
of controll)
otherwise crossing=unmarked

>    - There is fragmentation in tag usage for marked crossings between
> "zebra" and "uncontrolled".

Last year, I have review ~1k crossing=zebra,
the fragmentation is mainly due to iD

>    - crossing=marked is direct and clear about its meaning and use cases.

for now, the "new" iD preset destroys perfectly valid data
at a frightening rate!
if someone modifies a pedestrian crossing with a light, iD replaces it
with crossing=marked, which disrupts the information of the presence of
the light.
There is already a tag for the reference of a crossing.
if the reference is not known, it would be easy to use crossing_ref=yes
as it is done with many keys.

> - crossing=marked is already in use and supported by various editors,
> including being the default in iD

a bad preset is not a good usage

Regards,
Marc
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
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 - crossing=marked

Nick Bolten
> If there is not any control of the crossing...yes otherwise should be crossing=traffic_signals or supervised=yes as you can read in the wiki.

But the meaning of "control" varies by region and municipality, and does not imply the presence or absence of ground markings. A controlled crossing can have or lack ground markings, and an uncontrolled can have or lack ground markings.

> Well, in my country it is, when there is a traffic signals with pedestrian traffic signal there is a crossing=traffic_signals. Otherwise is crossing=no because there is no crossing at all.

In your country, how do you map a crossing that has traffic controls but does not have markings on the ground?

> Change the questions: 
> -Is there any traffic signal in the crossing?
> -Is there any supervision in the crossing?
> -Is there any mark in the crossing?

I don't know what it means for a crossing to be supervised, but I do like the others you've listed. I would prefer that the crossing=* tagging schema reflect the questions you are asking, they're the right ones for pedestrians. What I'm saying is that the current OSM schema seems to ask the questions I listed, but they get described by a single value like "uncontrolled", to the confusion of all. In other words: crossing=uncontrolled implies at least 3 pieces of information. Imagine if we instead had a schema for your questions that looked something like this:

crossing:traffic_signal=yes/no/*
crossing:supervision=yes/no/*
crossing:marking=yes/no/* (or crossing=marked/unmarked/*)

That would be separating those questions out much better than the current schema and be much easier to map.

> No , for a pedestrian way which passes inside an island I have footway=crossing because there si a footway inside a island. I don't need a tag which says things I can see in the situation for the map. It is the same reason I don't need crossing=marked if I have crossing=uncontrolled. Mark is not a control.

While it is not as thoroughly-documented as it could be, the wiki states that crossing:island can be applied to the footway: https://wiki.openstreetmap.org/wiki/Key:crossing:island. Specifically, "or alternatively on a pedestrian crossing way highway=footway + footway=crossing".

As an example, imagine that you are a data consumer and you want to tell a pedestrian router that they are using an island. If you were to look up a crossing:island key on a given footway, you could tell them, "use a traffic island to get to <whatever>". You can, of course, also use an advanced router that extracts crossing:island from a node.

> Well, we have it and it is called crossing_ref.

crossing_ref is not actually a tag for noting the type of markings, nor was it intended to be. It's a dumping ground for the older UK-centric tagging schema that used zebra, toucan, pelican, etc, with those UK-specific right-of-way implications. For example, crossing_ref does not have a "ladder" key, even though that's an extremely common marking type: https://taginfo.openstreetmap.org/keys/crossing_ref#values. As you can see, pretty much all of them are just "zebra". Many people from the UK get annoyed when you call a US-based ladder crossing a "zebra crossing", as our ladder crossings do not have the same right-of-way implications nor the angled markings.

> I was talking about crossing=zebra issue.

Ah, I see. I just misunderstood, my fault.

> Tell me one situation you cannot map in detail with present tagging scheme.

* Map a crossing that is unmarked and has pedestrian signals ("walk"/"do not walk").
* Map a crossing that is marked and is protected by a stop sign but no traffic light, then say how you would interpret this as a data consumer.
* Map a crossing that is unmarked and is protected by a stop sign but no traffic light, then say how you would interpret this as a data consumer.
* Map a crossing that is unmarked and is protected by its own, non-street-intersection traffic light, then say how you would interpret this as a data consumer.
* Map a crossing that is unmarked, has pedestrian-specific signals ("walk"/"do not walk"), but no traffic signals at all nearby. 
* Map a crossing that has markings and is protected by a traffic light, but that traffic light is part of the overall highway=traffic_signals signalization, not specific to just that crossing. 
* Map an unmarked crossing that has the same type of traffic light situation: the light is to stop traffic at the intersection, not that particular crossing alone. Map an unmarked crossing that has pedestrian-specific signals ("walk"/"do not walk") and has that same "intersection-only" traffic light.
* Map a marked crossing where pedestrians lack the right of way.
* Map an marked crossing that has dropped curbs (keep in mind that some veteran OSM mappers have stated that dropped curbs are a control).

I have no doubt that you can come up with some examples that *mostly* work. But they will be ambiguous to a data consumer and often most mappers.

Best,

Nick

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

Re: Feature Proposal - crossing=marked

Paul Allen
On Thu, 9 May 2019 at 23:46, Nick Bolten <[hidden email]> wrote:

I don't know what it means for a crossing to be supervised,

I assume what is meant by "supervised" is https://en.wikipedia.org/wiki/Crossing_guard

The supervised crossing may have markings or even lights, or possibly neither.  The lollipop
person is there for specific events (usually school start/finish) to provide extra safety. for the
little monsters.  Could also apply to a police officer on traffic duty in countries where traffic
lights are more expensive than police officers.

--
Paul


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

Re: Feature Proposal - crossing=marked

Paul Allen
In reply to this post by Nick Bolten
On Thu, 9 May 2019 at 23:26, Nick Bolten <[hidden email]> wrote:

Yes, but a traffic light for whom? I've seen mappers who assume it means "walk"/"do not walk" lights like this: https://commons.wikimedia.org/wiki/File:Do_Not_Walk_sign,_Great_Neck,_New_York.jpg. I've seen mappers who assume it means there is a sign *just* to warn traffic about pedestrians, as can be found in the UK. I've seen mappers who assume it means there is a nearby traffic light that means cars sometimes stop at this location, but it doesn't say anything about having a "walk"/"do not walk" sign.

Yes, there are warning lights in the UK.  Zebra crossings on public roads have a flashing yellow
globe on a pole (Belisha Beacon) to highlight that there is a crossing.  But nobody refers to it as
a traffic light.  Some crossings by schools have flashing yellow lights (in a similar sort of style
to US railroad crossing lights) but they're not traffic lights either.  Traffic lights control the flow
of traffic by telling drives when they must stop and when they can go, they're not warnings that
there is a crossing.

We have crossings with lights that control both pedestrians and traffic, the Pelican (PEdestrian
Light CONtrolled) crossing.  As far as motorists are concerned it looks like any other set of
traffic lights except there's an additional flashing amber phase telling cars they can go if there
are no pedestrians on the crossing.  As far as pedestrians are concerned it looks like traffic
lights for motor vehicles but also has lights for the pedestrians (and a button, which may or
may not do anything) for the pedestrian to let the lights know somebody is waiting to cross).

I don't recall seeing (in the UK, in other countries it might be different) lights that control
pedestrians but NOT traffic.  It doesn't seem to be a sensible idea.  A signal that tells pedestrians
it's now OK to cross without telling motorists they should have stopped seems like a recipe
for disaster.

To summarize: in the UK there are traffic lights that control motor vehicles and there are traffic lights
that control both motor vehicles and pedestrians; warning lights are not 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 - crossing=marked

Nick Bolten
This all makes sense, but the question is: what does crossing=traffic_lights mean given these contexts? There are at least 3 types of lights and I've seen all of them referred to as "traffic lights", even on UK government websites:

- Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to indicate that pedestrians should cross.
- The traffic lights for street traffic that are specifically associated with a pedestrian crossing, as in the pelican example - the traffic light pole also has all of these things: a pedestrian signal, a light for street traffic (stop/go/etc), and there is generally an APS to request a crossing signal.
- The traffic lights for street traffic that are not explicitly associated with a particular crossing. The crossing is still protected by those lights, there might even be an APS, but the traffic light is located at highway=traffic_signals, i.e. the center of a street intersection.

The OSM wiki describes crossing=traffic_signals as, "Position this tag where the crossing-traffic (pedestrian, bicycles) have their own traffic lights." I still have no idea which of these things that is meant to apply to. I wouldn't personally consider a intersection-centered traffic light to be pedestirans' "own" traffic lights, but they have roughly the same function and impact on pedestrian needs as a pelican crossing, in terms of traffic. I've been told a few times, on this mailing list, that it does not apply to pedestrian signals, but that's hard to reconcile with the fact that pedestrian signals are frequently referred to as "traffic lights" in many official government documents and guides and trying to understand what in the world "their own traffic lights" means.

Personally, I think this suggests a need for a separate value or at least tagging strategy to separate at least these two cases: signals directed at pedestrians vs. signals directed at street traffic. If there is value in knowing whether traffic signals are attached to the crossing in some way, I wouldn't be against that, either.

On Fri, May 10, 2019 at 4:45 AM Paul Allen <[hidden email]> wrote:
On Thu, 9 May 2019 at 23:26, Nick Bolten <[hidden email]> wrote:

Yes, but a traffic light for whom? I've seen mappers who assume it means "walk"/"do not walk" lights like this: https://commons.wikimedia.org/wiki/File:Do_Not_Walk_sign,_Great_Neck,_New_York.jpg. I've seen mappers who assume it means there is a sign *just* to warn traffic about pedestrians, as can be found in the UK. I've seen mappers who assume it means there is a nearby traffic light that means cars sometimes stop at this location, but it doesn't say anything about having a "walk"/"do not walk" sign.

Yes, there are warning lights in the UK.  Zebra crossings on public roads have a flashing yellow
globe on a pole (Belisha Beacon) to highlight that there is a crossing.  But nobody refers to it as
a traffic light.  Some crossings by schools have flashing yellow lights (in a similar sort of style
to US railroad crossing lights) but they're not traffic lights either.  Traffic lights control the flow
of traffic by telling drives when they must stop and when they can go, they're not warnings that
there is a crossing.

We have crossings with lights that control both pedestrians and traffic, the Pelican (PEdestrian
Light CONtrolled) crossing.  As far as motorists are concerned it looks like any other set of
traffic lights except there's an additional flashing amber phase telling cars they can go if there
are no pedestrians on the crossing.  As far as pedestrians are concerned it looks like traffic
lights for motor vehicles but also has lights for the pedestrians (and a button, which may or
may not do anything) for the pedestrian to let the lights know somebody is waiting to cross).

I don't recall seeing (in the UK, in other countries it might be different) lights that control
pedestrians but NOT traffic.  It doesn't seem to be a sensible idea.  A signal that tells pedestrians
it's now OK to cross without telling motorists they should have stopped seems like a recipe
for disaster.

To summarize: in the UK there are traffic lights that control motor vehicles and there are traffic lights
that control both motor vehicles and pedestrians; warning lights are not traffic lights.
--
Paul

_______________________________________________
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 - crossing=marked

Paul Allen
On Fri, 10 May 2019 at 19:27, Nick Bolten <[hidden email]> wrote:
This all makes sense, but the question is: what does crossing=traffic_lights mean given these contexts? There are at least 3 types of lights and I've seen all of them referred to as "traffic lights", even on UK government websites:

- Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to indicate that pedestrians should cross.

In any sane world, lights to control pedestrians also function as lights to control traffic.  I can't
see any sensible use case for lights that tell pedestrians they can cross that do not also
control traffic.  In the UK these usually (always) look identical to "ordinary" traffic lights with
the operational exception of a protracted flashing amber to let pedestrians finish crossing.
From a motorist's perspective they are indistinguishable (at first glance) from "ordinary"
traffic lights.

- The traffic lights for street traffic that are specifically associated with a pedestrian crossing, as in the pelican example - the traffic light pole also has all of these things: a pedestrian signal, a light for street traffic (stop/go/etc), and there is generally an APS to request a crossing signal.

This, rather than your first case, is all I've ever seen in the UK.

- The traffic lights for street traffic that are not explicitly associated with a particular crossing. The crossing is still protected by those lights, there might even be an APS, but the traffic light is located at highway=traffic_signals, i.e. the center of a street intersection.

If they ARE intended as a crossing then, in the UK, they'll be a pelican again, even if they're also
controlling an intersection.  Not to be confused with ordinary traffic lights at an intersection which
may not be intended for use as a crossing but tend to be used that way (because the traffic in
one direction has been stopped, making crossing perhaps a little less difficult).

As far as I can tell (at least in the UK) it boils down to either traffic lights that have nothing to do
with pedestrians or traffic lights that also control pedestrians.

--
Paul


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

Re: Feature Proposal - crossing=marked

Nick Bolten
I still don't know when you think we should use crossing=traffic_signals...

Imagine you're outside the UK. Pelican signals don't exist. No animal signals, mythical or real, of any kind. There's just infrastructure:

- A crossing might be marked on the ground
- A crossing might have lighted signals for pedestrians to cross
- A crossing might be protected by a traffic light that tells traffic to stop. That light might be at the crossing or at a street intersection.
- A crossing might be protected by warning lights to raise pedestrian visibility

Which part(s) of that does crossing=traffic_signals describe?

> In any sane world, lights to control pedestrians also function as lights to control traffic.

Then we live in an insane world! I'm not aware of any lights that control both pedestrians and traffic - they are oriented in orthogonal directions.

> I can't see any sensible use case for lights that tell pedestrians they can cross that do not also control traffic.  In the UK these usually (always) look identical to "ordinary" traffic lights with the operational exception of a protracted flashing amber to let pedestrians finish crossing. From a motorist's perspective they are indistinguishable (at first glance) from "ordinary" traffic lights.

Similar to you, I have yet to find an intersection with a pedestrian signal that does not have some form of either warning or explicit traffic control (but it could be either one), but I wouldn't rule it out based on my experience alone. However, the existence of a traffic light doesn't imply any other infrastructure: the crossing might lack pedestrian signals, its own dedicated light near the crossing, and even any particular visual markings indicating where to cross. Despite this, the crossing=traffic_signals tag has been used to describe all of these things, somehow.

On Fri, May 10, 2019 at 12:31 PM Paul Allen <[hidden email]> wrote:
On Fri, 10 May 2019 at 19:27, Nick Bolten <[hidden email]> wrote:
This all makes sense, but the question is: what does crossing=traffic_lights mean given these contexts? There are at least 3 types of lights and I've seen all of them referred to as "traffic lights", even on UK government websites:

- Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to indicate that pedestrians should cross.

In any sane world, lights to control pedestrians also function as lights to control traffic.  I can't
see any sensible use case for lights that tell pedestrians they can cross that do not also
control traffic.  In the UK these usually (always) look identical to "ordinary" traffic lights with
the operational exception of a protracted flashing amber to let pedestrians finish crossing.
From a motorist's perspective they are indistinguishable (at first glance) from "ordinary"
traffic lights.

- The traffic lights for street traffic that are specifically associated with a pedestrian crossing, as in the pelican example - the traffic light pole also has all of these things: a pedestrian signal, a light for street traffic (stop/go/etc), and there is generally an APS to request a crossing signal.

This, rather than your first case, is all I've ever seen in the UK.

- The traffic lights for street traffic that are not explicitly associated with a particular crossing. The crossing is still protected by those lights, there might even be an APS, but the traffic light is located at highway=traffic_signals, i.e. the center of a street intersection.

If they ARE intended as a crossing then, in the UK, they'll be a pelican again, even if they're also
controlling an intersection.  Not to be confused with ordinary traffic lights at an intersection which
may not be intended for use as a crossing but tend to be used that way (because the traffic in
one direction has been stopped, making crossing perhaps a little less difficult).

As far as I can tell (at least in the UK) it boils down to either traffic lights that have nothing to do
with pedestrians or traffic lights that also control pedestrians.

--
Paul

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
123