Proposal talk:Crossing=marked

From OpenStreetMap Wiki
Jump to navigation Jump to search

Railway crossings

Probably worth mentioning the existence of railway=crossing for pedestrian rail crossings, particularly around light rail lines. – Minh Nguyễn (talk, contribs) 20:41, 20 June 2018 (UTC)

This might be a good reason to expand this proposal to include nodes (railway crossings are ~100% node features right now). --Nbolten (talk) 20:52, 20 June 2018 (UTC)

Various kinds of signalized crosswalks

How to distinguish the following kinds of crosswalks?

  • A timed, signalized crosswalk at a road intersection (not necessarily marked)

    A timed, signalized crosswalk at a road intersection (not necessarily marked)

  • A crosswalk with flashing lights, triggered by a "beg button" (not necessarily marked)

    A crosswalk with flashing lights, triggered by a "beg button" (not necessarily marked)

  • A mid-block crosswalk that has normal traffic lights on the roadway and no cross street

    A mid-block crosswalk that has normal traffic lights on the roadway and no cross street

 – Minh Nguyễn (talk, contribs) 20:41, 20 June 2018 (UTC)

This is a very good question. So far as I can tell, it's ambiguous whether traffic_signals=* communicates signals-for-pedestrians or signals-for-cars, and that's the key issue with all of these examples: some combinations of car vs. pedestrian signals. As for how I'd currently tag them, I'd focus on the ways and tag them with *only* pedestrian signal info: highway=footway footway=crossing crossing=marked traffic_signals=yes. In all cases, traffic_signals=yes would refer to the 'pedestrian walk' lights, and not the lights for traffic.
Personally, this is the reason I would prefer to have a new tag: pedestrian_signals=yes/no. This would allow for separately describing the signals for pedestrians and those for cars, which are useful for both pedestrian and automotive data consumers. My current plan is to put that in a separate proposal, to hopefully increase the chance of both being accepted / improved. --Nbolten (talk) 21:04, 20 June 2018 (UTC)
traffic_signals=* is normally used for roadway signals. Key:crossing describes the use of keys namespaced by traffic_signals: but not a traffic_signals=* key itself. This is a bit unusual as namespaced tags go; normally, the namespace is also a key in its own right. Some of the examples above could require a node to be both a (road) traffic signal and a crossing node, depending on where a mapper prefers to place traffic signal nodes. – Minh Nguyễn (talk, contribs) 04:05, 21 June 2018 (UTC)
I completely agree. The use of keys namespaced by traffic_signals=* at Key:crossing is doubly weird because it doesn't have use of the top-level key (currently part of this proposal: traffic_signals=yes/no) and is using a key that is normally used for car traffic. I think pedestrian_signals=* is a better descriptor of signals-for-pedestrians in combination with crossing=*, but that would be another change to tagging standards. traffic_signals=* would then be freed up for describing signals-for-cars that exist at a crosswalk, which is useful information for pedestrians. Do you think that tag would also make sense as part of this proposal (changing 3 tags at once seems like a lot)? --Nbolten (talk) 05:21, 21 June 2018 (UTC)
Changing those tags simultaneously would lead to a less confusing tagging scheme and less conflict with other tagging schemes, so I think it would be a positive move. Mappers can continue to use the older tags simultaneously if they want to maximize compatibility with existing software. – Minh Nguyễn (talk, contribs) 06:39, 22 June 2018 (UTC)
I fully agree the current crossing scheme is confusing. This is a good start at an update. My concern with a key like pedestrian_signals=* is that it seems to leave a gap for non-vehicular crossings (e.g. cycle ways). Invidious (talk) 20:31, 12 August 2018 (UTC)
This perhaps isn't as big an issue as I thought. In my jurisdiction, bicyclists are legally either pedestrians or vehicles depending on whether they are riding on the sidewalk or the street. For any dedicated cycle lane crossings traffic_signals=* or cycle_signal=* would work. I am of mind to start using crossing=marked with the striping details moved to crossing_ref. Invidious (talk) 05:32, 25 October 2018 (UTC)

Brainstorming a bit based on the image gallery above and some tags I recently discovered with the help of Key:crossing:

These tags should fit with the current proposal, but there are some redundant tags, and the kind of signal isn't always clear from just looking at the tags.

 – Minh Nguyễn 💬 22:56, 24 December 2018 (UTC)

I very much in favor of this proposal. I noticed its been sometime since the last comment or update on this page what needs to be done to get the ball rolling and a vote to be started? Te-ika (talk) 08:28 February 11th, 2019

Other marking types

What about crossing marked by

  • solely traffic sign, without markings on road surface
  • solely by traffic_calming=table, without traffic sign, without markings on road surface
  • by traffic_calming=table and traffic sign, without markings on roads surface

? How it should be tagged according to this proposal? Mateusz Konieczny (talk) 09:29, 8 May 2019 (UTC)

These are all very good points. For traffic signs, I have to ask what kind of signs first, because I have a related crossing:signals=* proposal that might work. For traffic_calming=table, we are lucky that it's already a separate tag, so with good documentation and editor support it could hopefully be treated as a separate question. So, to answer your question, this is how those situations would be considered if *both* proposals were accepted. For a crossing with no traffic sign, road markings, but that does have a table, it would be: crossing=unmarked, crossing:signals=no, traffic_calming=table. For a crossing with a table, traffic sign, but no markings: crossing=unmarked, crossing:signals=yes, traffic_calming=table. --Nbolten (talk) 17:16, 9 May 2019 (UTC)
"what kind of signs first" https://en.wikipedia.org/wiki/File:Znak_D-6.svg https://en.wikipedia.org/wiki/File:Znak_D-6a.svg https://en.wikipedia.org/wiki/File:Znak_D-6b.svg Mateusz Konieczny (talk) 18:47, 9 May 2019 (UTC)
I wonder is it possible avoid "crossing marked with traffic signs only is crossing=unmarked". Maybe use crossing:surface=marked or something else similar to crossing:signals? Proposal seems to be about road surface marking only, without considering other marking methods so maybe it would be useful to reflect it in the tag name? Mateusz Konieczny (talk) 18:47, 9 May 2019 (UTC)
Would you consider the term "marked crossing" ambiguous such that you wouldn't be sure if it meant a crossing with markings on the ground vs. one that had signs (as the examples you provided)? "marked crossing" means crosswalk to me, but that might not be universal. If this is ambiguous for many, you're right that we should take steps to clarify it and separately map these things. What would you think of crossing:sign=yes/no/* for signs if crossing=marked were kept as-is? So, on-the-ground markings status is crossing=marked/unmarked and the existence of crossing signs would be crossing:sign=yes/no/*? --Nbolten (talk) 21:39, 9 May 2019 (UTC)
Personally for me "marked crossing" would include ones marked solely with standing traffic signs without markings on road surface (I would translate it to Polish as "przejście znakowane" or "wyznaczone przejście" or "oznakowane przejście dla pieszych"). Mateusz Konieczny (talk) 16:07, 10 May 2019 (UTC)
"What would you think of crossing:sign=yes/no/* for signs if crossing=marked were kept as-is?" I would expect that in some/many cases meaning of crossing=marked will be ambiguous. At least for me it would be. Mateusz Konieczny (talk) 16:07, 10 May 2019 (UTC)
I'm theoretically open to words other than "marked", but am reluctant because "unmarked" already exists and is about ground markings. Do you think it would be something that a well-written wiki page would be able to address (e.g. the Key:crossing page)? --Nbolten (talk) 00:46, 11 May 2019 (UTC)
I would go for something completely unambiguous if we are introducing yet another standard anyway Mateusz Konieczny (talk) 10:39, 18 May 2019 (UTC)
Another edge case I haven't seen brought up in any of these discussions is whether a change in surface qualifies as a marking. A frequent way to indicate crossings in my area is the crossing itself is paved with red bricks (paving stones in OSM terminology), while the road is paved with (black) asphalt. Would this qualify as marked? Another less common but still frequent occurrence is the crossing being paved with (grey) concrete, while the road is again paved with (black) asphalt. Because of wear that darkens the concrete and lightens the asphalt, this color differential lessens over time. Would that qualify as marked? (Paint, of course, also fades over time.) --Jtracey (talk) 22:09, 14 November 2020 (UTC)

Proposed information loss

https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dmarked#Tag_candidates_for_automated_conversion

Note that converting crossing=uncontrolled to just crossing=marked is losing information that no traffic lights are present there Mateusz Konieczny (talk) 09:31, 8 May 2019 (UTC)

Due to the fact that nobody seems to agree on what the word "uncontrolled" means, I'm not confident that crossings tagged as "uncontrolled" even lack traffic lights, in reality. But you're right, when users have used the tag in that way, that data would be lost in an automated edit. My suggested approach for automated edits, aside from following the suggested protocols and guidelines on this wiki, would be to discuss it with local OSM communities and only do mass conversions on a community-by-community basis. I do no advocate for any mass edits without full feedback and strategies for maintaining data.
Another option would be to use MapRoullette (or something like StreetComplete) and ask both questions: (1) is this crossing marked? (2) does this crossing have pedestrian signals? This would result in the data being improved, rather than discarded. --Nbolten (talk) 17:21, 9 May 2019 (UTC)
I would consider making clear that successful vote of proposal is not automatic permission to start bot edits and that in some cases additional tags may be added upon removal of the old one Mateusz Konieczny (talk) 16:11, 10 May 2019 (UTC)
That's a good idea and I've updated that section. --Nbolten (talk) 00:43, 11 May 2019 (UTC)

Why double tag

Why this proposal encourages use of crossing=* both on highway=crossing node and footway=crossing way? Is there some good reason for that? I know that iD is encouraging that but it is not making it a good idea Mateusz Konieczny (talk) 09:39, 8 May 2019 (UTC)

There are data consumers that use both, so whenever I've brought this up both chime in. In theory, we can get just as much information from an intersecting footway as from a node: all of the same tags and we can use intersection to determine location. we can use these tags: crossing=*, surface=*, crossing:island=*, and as you've noted, traffic_calming=island (and probably more). As a "crossing" footway should share a node with the street(s) it crosses, a data consumer could always "copy" the way data to the shared node and proceed with whatever analysis they'd like. This is not true of extracting way-type data from a crossing node, as the exact footways it connects to is important data and it's impossible to properly represent things like curb ramps with enough specificity.
When I have proposed notnot mapping crossing nodes in the past (because data consumers who want nodes can still get the same value), data consumers have popped in to say that this does not work for them and that it makes the data less accessible. So, to avoid as much of that discussion as possible, this proposal applies to both. --Nbolten (talk) 17:29, 9 May 2019 (UTC)
I Thought about rather skipping crossing=* on way (I add footway=crosssing but add detail just at the node) Mateusz Konieczny (talk) 18:43, 9 May 2019 (UTC)
Ah, I see. So if a pedestrian-focused data consumer wanted to know what kind of crossing it was, they'd look up the containing node. Aside from the same type of issue as leaving the tags off the node (data consumers need advanced processing skills), I think information would be lost or ambiguous. Here's two examples:
* A boulevard is represented as two street ways, has a single crossing way (footway=crossing), and two crossing nodes (highway=crossing). Our goal is to figure out the crossing information from the nodes and interpret how it applies to the way. If the two nodes disagree, which one should we trust? If they disagree, does that mean the feature varies? Perhaps one half is marked and the other is not, and they're bridge by an island, but the mapper neglected to add crossing:island=yes.
* There is a single street, but multiple ways for a single crossing. Perhaps the mapper created separate ways because they split at the curb where they added kerb=*. In that case, the crossing has 3 ways: sidewalk to curb, curb to curb, curb to sidewalk. How do we know to associate the crossing information on the node with the two "sidewalk to curb" ways? They do not actually share the node. I believe the data consumer would have to build some fairly complex graph theoretic heuristics to make guesses.
I think the only option that doesn't require changing OSM primitives and that would be able to consistently manage to keep crossing data in one place and usable for both types of data consumers is a relation. There is not much community support for relations, so I'm wary of including one in this proposal, but I'm not against it in principal if it addresses real data problems. --Nbolten (talk) 21:46, 9 May 2019 (UTC)
The crossing should only refer to the section of the road that pedestrians would be crossing, curb/kerb to curb/kerb.
In the first example above where two street ways have two separate crossings, the island is already represented by the presence of two separate crossing nodes. Adding crossing:island=yes to each crossing would actually imply that there are three crossing islands (one at each crossing node, and another in between.) In this example, each crossing would be from the curb of the central island to the curb of the opposite sidewalk. The footway between the curbs of the island doesn't cross the roadway, so it isn't footway=crossing.
Similarly in the second example above, if I understand the scenario being described correctly, the two 'sidewalk to curb' footways are not part of the crossing but are part of the sidewalk area. --MacLondon (talk) 19:18, 28 May 2019 (UTC)
It is not actually possible to properly represent a single island on a "two-way" (literally two lines) separated boulevard using only nodes. crossing:island=yes has to be placed somewhere and there will be two highway=crossing nodes for such a boulevard. There are no good options: (1) if you place crossing:island=yes on just one node, it gives an incorrect spatial impression, and (2) if it's on both nodes, it indicates that there are two islands. In my opinion, crossing nodes are in no way meant for consumption by anyone offering pedestrian services / routing / maps, and this is one such example. Imagine being in charge of writing routing software for crossing that boulevard, sans a footway. You'd need complex rules about backtracking to the intersection so that you can successfully move from one boulevard to the other, simulating being "on" the crossing, because the actual path is not represented.
crossing:island=yes is described as applying to footway=crossing ways on the wiki: https://wiki.openstreetmap.org/wiki/Key:crossing:island. I prefer your rule (footway=crossing = on the road), but I think we'd need to create a new proposal to make that happen. We'd need a new tag like footway=island or something. --Nbolten (talk) 19:57, 28 May 2019 (UTC)
As I understand it, crossing:island=yes was proposed to avoid splitting ways at simple crossing islands and to free up nodes' crossing tag for use with other crossing=* values. It doesn't make sense to add it when ways have already been split.
We have to be mindful that a crossing node is also part of the road, and essentially it's the road that has a traffic_calming=island for motorists and they have to pass around this island. In contrast the pedestrian refuge itself isn't a "footway_calming=island" that pedestrian have to pass around; it's more like a protected footway area that might or might not have curbs/kerbs.
If a way is already split into two lines, then a physical separation of the two lines is already indicated by this separation and the two crossings are also separate entities. Adding crossing:island=yes to the two crossing nodes in this scenario would wrongly indicate (to motorists) that each line/road has a central island at each crossing node.
In between the two lines, there is a separate footway area which could potentially have amenities like cycle parking, phone etc. This footway area is physically separate from the two drawn lines, so it is not a 'crossing' island/area, i.e. it isn't crossing any line/road (as drawn on OSM).
If appropriate, a footway area could of course be added to OSM to represent the pedestrian refuge area between the two lines/roads. --MacLondon (talk) 18:12, 29 May 2019 (UTC)
While everything you've said makes sense (particularly, *not* tagging split ways with crossing:island=yes), I don't see how else one would use footway=crossing crossing:island=yes on a way aside from on the surface of an island. The documentation on the wiki doesn't really specify the exact conditions for its use, but from what I've pieced together on the mailing list, that seems to be how it's used: it's the way(s) on the island itself. --Nbolten (talk) 19:31, 31 May 2019 (UTC)

"crossing:priority" on nodes

Regarding the overall proposal, while I think there is merit in its use for footway=crossing to tag the footway, it only gives pedestrian focused information about painted markings. For nodes with highway=crossing it is a very different issue as the tagging for intersection points of footways/cycleways/roads needs to give relevant information for the motorists too, not just for those crossing.

In the UK, a zebra-like 'marked' crossing can be:

  • an actual zebra crossing where motorists must give way to pedestrians, but don't have to give way to cyclists,
  • a 'courtesy crossing' in car parks etc where motorists have priority but do generally give way to pedestrians,
  • a tiger crossing where motorists must give way to both pedestrians and cyclists.

It is the need to relay the priority at the crossing nodes that I think needs clarifying as that is the informtion that is relevant to both motorists and those crossing the road.

With nodes tagged as highway=crossing, I'd suggest using something like crossing:priority=yes/no/traffic_signals to convey the priority for those using any type of crossing. Where priority is different for 'crossing' cyclists, crossing:priority:bicycle=* could be used. --MacLondon (talk) 19:44, 28 May 2019 (UTC)

These rules about priority concern right of way. Knowing the right-of-way is definitely valuable, and I think you're on the right track in terms of it being a separate tag (or even multiple tags), but I'd like to consider it beyond the scope of this proposal. Technically speaking, none of the currently-defined tagging schema implies right of way, either, even though many mappers seem to use it as if it does. I can definitely see why, though: "uncontrolled" is all about right-of-way in the real world, OSM is using the term incorrectly.
Full disclosure: I'm a little worried about mapping right-of-way directly on paths, as it's a legal question. There are these risks: (1) mappers can more easily get it wrong versus "there's paint on the ground", (2) correctly mapping right-of-way might actually be nearly impossible without a proper legal ruling from a magistrate/judge, as laws are often ambiguous, (3) you can't verify it "on the ground", (4) when laws change, we'll need to change the whole map for a given country/region/city. I anticipate that those updates won't actually happen, and that if they did, it'd be on the basis of on-the-ground-verifiable features like markings. Would it be possible to derive the right-of-way descriptions you listed solely from an understanding of the law and hypothetical crossing=* tags of on-the-ground features? Here are some attempts:
* a zebra crossing is a crossing with marked=zebra (possibly also crossing_ref=zebra) that intersects a public street.
* a 'courtesy crossing' is a crossing that intersects highway=service.
* a 'tiger crossing' is a crossing with a dotted line casing.
I think that last one isn't quite right, but I didn't want to speculate too much. Tiger crossings actually have to be associated with a pedestrian crossing in addition to the cyclist one, right? I feel like this implies the need for new tags, as we'd need to describe the properties of two ways at once, sort of like lanes. --Nbolten (talk) 20:28, 28 May 2019 (UTC)
Commenting from a UK perspective, true 'zebra crossings' (and newer tiger crossings here) have a required combination of Belisha beacons plus the striped road markings. On their own, striped road markings are just 'courtesy crossings' although in practice most motorists don't seem to realise they are different (or maybe they are just very courteous!) and so these crossings tend to operate as if they were zebra crossings. In a parking lot, marked crossings are probably mostly 'courtesy crossings'... but some can be zebra crossings. On a main road a marked crossing is not a zebra crossing if it doesn't have Belisha beacons.
In the UK, an example of a tiger crossing (with separate crossing stripes for pedestrians and cyclists) is here. These have become increasing common over the last 3-4 years along upgraded cycle routes in London. I'd tag these nodes as highway=crossing crossing=uncontrolled crossing_ref=tiger bicycle=yes and tag the crossing as a single way with highway=cycleway cycleway=crossing footway=crossing segregated=yes. (In the UK, the default for highway=cycleway implies foot=yes, so that doesn't need adding to a shared cycleways.)
If right of way isn't known, then obviously it shouldn't be tagged. If it is known and is tagged, then the safety of the crossing is essentially being tagged. Good tagging of these crossing would be particularly relevant to anyone visually impaired, not from a legal perspective but from a safety perspective. Again from a UK perspective, it's easy to describe crossings here with either a full time or temporary pedestrian right of way simply by using 'type of crossing', and then tagging with crossing_ref=pelican/puffin/toucan/pegasus/zebra/tiger. Any of these could be regarded as being safe, or at least 'designed/intended to be safe crossings'.
The problem in OSM is that using the crossing=* tag on nodes is the only way is tag a crossing as 'safe': uncontrolled/traffic_signals (safe) versus unmarked (potentially unsafe). But the definitions of some of these values are far too vague.
I think the confusion with the crossing=uncontrolled tag in OSM is that it applies to the crossing (as this was the value used for UK-focused definitions of zebra crossings, presumably this was intended for where pedestrians/cyclists crossing the road have an 'uncontrolled' right of way.) However in general use (beyond OSM), an "uncontrolled crossing" probably usually refers to the road being crossed from the motorists' perspective, i.e. where the motorists are 'uncontrolled'.
An issue with marked crossings is that these can be safe or unsafe depending on the 'type of crossing'. In some circumstances crossing=marked on nodes could be useful where no alternative crossing=* is correct, e.g. at marked crossings where traffic_signals exist for motorists but not for pedestrians, e.g. here.
However I don't think it would be relevant to all marked crossings. such as on a UK zebra crossing node, to replace a correctly used crossing=uncontrolled with a less informative crossing=marked that could instead be tagged on the way as is otherwise described in this proposal. If crossing:priority=yes was used to indicate that pedestrians crossing had priority, then crossing=marked could be added if crossing=uncontrolled was eventually deprecated.
I think crossing:priority=* could be used to help decide on a definition of the intended meaning of crossing=uncontrolled etc. However because crossing tags have been used so inconsistently due to different interpretations of the values, I think it's too late to try to refine the definitions of the widely used existing tags, so a new tagging method is probably needed if a better definition of crossings can be decided on. --MacLondon (talk) 15:39, 29 May 2019 (UTC)
Given the technical need for a Belisha beacon at a zebra crossing, I wonder if there's a need for tags to describe it. e.g., hypothetical tags like crossing:warning_lights=yes crossing:warning_lights_ref=belisha (exact form up for refinement, of course). Would that, potentially, allow for the identification of a true zebra crossing without directly tagging right-of-way?
Concerning "uncontrolled", the confusion seems to run much deeper. I've received just about every interpretation you could think up on the mailing list aside from the actual OSM wiki-defined meaning - that it's about street traffic (as you mentioned), that it's established by dropped curbs, that it's established by a nearby sign, that only certain types of markings establish it, and the frequent opinion that markings are next to irrelevant (despite that being the actual tag's description). It's a mess - all of those different ideas are getting tagged as the same thing.
Concerning replacing crossing=uncontrolled with crossing=marked in the UK, keep in mind the wiki's definition: uncontrolled is literally described as just a marked crossing that doesn't have its own traffic flights. We don't actually have a tag that means, "pedestrians have the right of way here" at the moment and no information would be lost. Instead, we'd get clarity: the name of the tag would match the meaning. In the UK, one could always use crossing_ref=zebra in either schema in absence of sufficiently clear tags to infer right-of-way. But I'd still like to see how easy it would be to describe a zebra crossing from ground conditions such that it could be interpreted as providing pedestrian right-of-way so long as the data consumer knows they are in the UK. Imagining that "types" of markings/warning lights are allowed values for their tags, what about crossing=marked, marked=zebra, warning_lights=belisha?
I think it might be good to create a new topic for some of these ideas - too many directions at once!--Nbolten (talk) 19:42, 31 May 2019 (UTC)

crossing=marked/unmarked vs. crossing:marked=yes/no

This section is meant to organize a comparison between two new schemas for tagging whether a crossing is marked or not.

Issue/Feature crossing=marked/unmarked crossing:marked=yes/no
Already in-use Yes No
Supported by at least one editor Yes No
Describes crossing attribute, rather than "type" No Yes
Could peacefully coexist with previous crossings schema during transition No Yes
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Crossing%3Dmarked&oldid=2513131"