Proposal:Crossing:markings

The Feature Page for the approved proposal Crossing markings tagging is located at Key:crossing:markings

Crossing markings tagging
Proposal status:	Approved (active)
Proposed by:	Popball
Tagging:	crossing:markings=* Data item
Applies to:	node , way
Definition:	The existence and style of pedestrian crossing markings
Statistics:
Draft started:	2022-06-24
RFC start:	2022-07-10
Vote start:	2022-09-03
Vote end:	2022-09-17

Proposal

This proposal would add a new key, crossing:markings=* in order to document the existence and style of markings on the ground to mark where pedestrians cross a road.

Deprecate the recently documented but undiscussed crossing:marking=* and move this to the appropriate values of crossing:markings=*, surface=* and surface:colour=* (currently crossing:marking=* contains values created here for crossing:markings=* as well as rainbow and red)

Definition

For the purposes of crossing:markings=*, 'markings' shall be those markings on the ground meant to draw attention to the area where pedestrians are to cross the road. The standard for these markings can vary from country to country, but are usually required to be the same colour as the other road markings, in high visibility white or yellow. This is most commonly done with paint or bright bricks.

Rationale

This scheme attempts to extend the existing schemes regarding pedestrian crossings. Various patterns of road markings are used to mark the area where pedestrians can cross the road. This scheme will allow for detailed rendering of roads, as well as better handling of edge cases. In addition, some government agencies have recommended [1] changing their crossing markings to more visible patterns, and this data may be useful for modeling pedestrian safety.

Some[2] have mentioned the orthogonal usage of crossing=* and how there is no way to indicate the existence of road markings with crossing=traffic_signals

Knowing the existence and/or pattern of crossing marking may be useful also for people with limited mobility for orientation as well as knowing that there are markings to follow at a crossing.

Because of the lack of any way to tag the crossing markings, many mappers have begun to use crossing_ref=* to document the type of markings. For example, current version of the page for crossing_ref=zebra currently specifies the presence of zebra markings (widening from its original meaning of the region specific name of the crossing type). In addition, the page for crossing_ref=* currently documents several US standard crossing marking patterns. All these uses of crossing_ref=* can be better documented with crossing:markings=* to avoid overloading crossing_ref=*. For example, US mappers no longer need to choose between tagging the markings (e.g. crossing_ref=continental) and tagging the type of signalised crossing (e.g. crossing_ref=hawk to tag a HAWK signalised crossing). Besides the U.S., other countries such as Canada [3] and New Zealand [4][5] also allow for multiple styles of crossing markings.

crossing_ref=* would be unaffected in its use for the British "animal" crossing names (zebra, puffin, pegasus, etc.). This is because values of crossing_ref=* imply information about the crossing (becides the markings) which the community has no other way to tag. For example, crossing_ref=zebra in the UK not only implies zebra markings, but also belisha beacons, zig-zag warning markers on the approach, and pedestrian priority.

Name Rationale

The key crossing:markings=* was chosen as it is already compatable with similar tags used with railroad crossings. See crossing:barrier=*, crossing:light=*, crossing:chicane=*, crossing:bell=* for railways as well as the proposed crossing:signals=* for highway crossings. In addition, the values scheme (i.e. yes/no/(something more specific)) is consistant with how kerb=* specifies its values.

Tagging

This tag is most commonly used in conjunction with highway=crossing but can also be used with railway=crossing when the crossing area is marked.

For the purposes of documentation and discussion, markings parallel to the crossed road should be referred to as 'bars' while markings orthogonal to the roadway should be referred to as 'lines'.

Key	Value	Diagram	Description	Example
crossing:markings	yes		An unspecified or unknown crossing marking. Can also be used in document any crossing marking which hasn't been documented.
crossing:markings	no		The absence of crossing markings at a crossing. Implied by crossing=unmarked. May be useful in combination with crossing=traffic_signals where there is no marking on the ground, but there is a pedestrian signal.
crossing:markings	surface		A crossing which is not differentiated by high visiblity road markings, but only by a change in surface. Depending on the juristiction, this may or may not be considered a proper crossing. Additional details can be added with the established tags surface=* and surface:colour=*. crossing:markings=solid has been discussed to document crossing markings which are all high-vis paint for the width of the crossing, but it has been determined that this is too rare (and confusing to mappers) to merit a top level entry in the schema.	.
crossing:markings	lines		Lines on either side of the crossing (U.S.: "standard/transverse"; Canada: "twin parallel lines")
crossing:markings	lines:paired		Pairs of lines on either side of the crossing.
crossing:markings	dashes		Dashed lines on either side of the crossing. Used in some countries (such as Germany) at (nearly) all signalized crossings.
crossing:markings	dots		Dotted lines on either side of the crossing. The dots sometimes are reflectors slightly raised from the carriageway. (U.S.: "dashed")
Zebra style crossings
crossing:markings	zebra		Regularly spaced bars along the length of the crossing. (Called "continental" in the United States.)
crossing:markings	zebra:double		The similar to zebra, but split in the middle. (U.S.: "triple-four")
crossing:markings	zebra:paired		Like a zebra crossing but skipping every third bar to avoid premature tire wear. (U.S.: "double-paired")
crossing:markings	zebra:bicolour		A zebra crossing with alternating colours. The colours can be tagged using crossing:markings:colour=*.
Ladder style markings
crossing:markings	ladder		Lines perpendicular to the roadway along with bars parallel to the roadway.
crossing:markings	ladder:skewed		Two lines orthogonal to the direction of the roadway with diagonal bars connecting the two lines. Sometimes confusingly referred to as "zebra" in the United States.
crossing:markings	ladder:paired		Ladder-style markings with the bars paired together.

More values may be documented as they are discovered or invented by governments.

Implied values of crossing:markings=*

Existing tags may imply a value of crossing:markings=*. A crossing with crossing=traffic_signals, crossing=uncontrolled crossing=marked can be assumed to have crossing:markings=yes (but this can be overridden/further specified using this scheme. On the other hand, crossing=unmarked implies crossing:markings=no, and supplying a value other than "no" could be checked by validators. Further, individual values of crossing_ref=* may be documented in the wiki as implying a default markings pattern within a certain region. For example, crossing_ref=zebra implies crossing:markings=zebra in Germany, as the patterns for pedestrian crossings are highly standardized in Germany.

In addition, any value other than "no" would imply a some sort of markings on the ground, therefore easing data processing.

More difficult cases

In the case of segregated crossings for pedestrians and cyclists, this can be tagged separately as cycleway:crossing:markings=* and footway:crossing:markings=*.

The color of the markings can be specified using the standard colour=* scheme (e.g. crossing:markings:colour=yellow).

Multiple values of crossing:markings=* can be separated by a semicolon to specify multiple patterns atop each other (see examples below).

Crossing with marking which change in the middle of the crossing

Although quite rare, if a crossing has markings which change within a single crossing, one can tag this most precisely by splitting the crossing way and tagging the individual individual segments with the appropriate value of crossing:markings=*. The highway=crossing node should still be tagged with the most prominent value for crossing:markings=* or simply crossing:markings=yes.

Examples

Example	Tagging
	The most accurate way to tag this would be highway=crossing crossing=uncontrolled crossing:markings=zebra;dots crossing_ref=zebra However, simply tagging the markings as crossing:markings=zebra shouldn't be considered "wrong", simply a less detailed description. Note: Dots refers to the very small markings right besides the zebra bars. The more prominent dashed give-way-lines are a separate feature.
	A segregated foot and cycle crossing highway=crossing crossing=traffic_signals bicycle=yes segregated=yes footway:crossing:markings=zebra cycleway:crossing:markings=dots
	A shared pedestrian and cyclist crossing highway=crossing crossing=uncontrolled bicycle=yes segregated=no crossing:markings=zebra;dots
	highway=crossing crossing=uncontrolled crossing:markings=zebra crossing:markings:colour=gold
	highway=crossing crossing=uncontrolled crossing:markings=lines surface=paving_stones
	Artistic crosswalk highway=crossing crossing=uncontrolled crossing:markings=lines This crosswalk is painted in various colors, but it isn't a solid marking; the white lines are still required for it to be a legal crosswalk (in the US).

Where crossing:markings is not appropriate

Buffer markings

These markings act as a painted curb extension for pedestians, somewhat common in Germany.

crossing:buffer_marking=* was proposed to document this. See Berlin/Verkehrswende/Gehwege for more details (in German).

Look left/look right markings

These markings should not be included in crossing:markings=* as they serve a different role from a crossing markings.

No scheme has been proposed to document these (yet).

Rendering

Crossings are not rendered in Carto, but this information would allow for detailed renderings including a more accurate crossing paint texture.

Features/Pages affected

Create a new page crossing:markings=* and pages for popular values as needed.

Deprecate crossing:marking=*.

Add links to other relevant pages, including:

• highway=crossing
• crossing=traffic_signals
• crossing_ref=*
• Crossings

External discussions

• https://lists.openstreetmap.org/pipermail/tagging/2019-May/045177.html
• https://github.com/openstreetmap/id-tagging-schema/issues/408#issuecomment-1065041824
• https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/crossing%3Dmarked
• https://lists.openstreetmap.org/pipermail/tagging/2022-July/065031.html

Comments

Please comment on the discussion page.

Voting

Voting closed

Voting on this proposal has been closed.

It was approved with 29 votes for, 1 vote against and 3 abstentions.

• I approve this proposal. --Popball (talk) 12:24, 3 September 2022 (UTC)
• I oppose this proposal. useless namespace (crossing on highway=crossing is of course about the crossing), no explanation of why the documented key has to be deprecated to add an s, and yet another key to fill in when there is an obvious redundancy with crossing_ref Marc marc (talk) 12:43, 3 September 2022 (UTC)

  1. crossing:*=* is standard for all other attributes on highway=crossing. This makes it clear it's about markings for the crosswalk itself only, not the yield/stop/signal line which can be found without crosswalk marking. Furthermore, any conflict with the actual marking as road_marking=* or equivalent is avoided.

taginfo stats say the opposite : tactile_paving, bicycle, kerb, button_operated for the top 5 doesn't have a unneeded crossing: prefix Marc marc (talk) 13:22, 14 September 2022 (UTC)

• 1. Different definitions may exist, when crossing:markings=* defines the aforementioned, crossing:markings=surface, and excludes edge buffer or look left/right markings. A significant use exists for crossing:marking=rainbow that's moved out.
  2. crossing_ref=* is the general setup or status of crosswalk (ie Pelican etc in UK, HAWk in USA). crossing:markings=* is the marking. Elsewhere around the world, "zebra" stripe markings are used in non-Zebra crossings, especially when it can have no pedestrian priority.

that is precisely my point : we add a key to the 3 previous schema instead of unify the whole. one day a contributor changes one of the keys and the result doesn't mean anything anymore as long as someone doesn't go and see in the history what the last modification was in order to change the other keys describing in the end the same thing but in a different way, 3 key about a zebra is a bad idea Marc marc (talk) 13:22, 14 September 2022 (UTC)

• --- Kovposch (talk) 14:03, 3 September 2022 (UTC)

  @Marc marc: There’s some discussion about crossing:marking=* on the talk page. The short story is that that key was essentially coined and documented while this proposal was already in an RfC stage. I’d contend that this is the more well-thought-out of the two keys, and the one that has more momentum behind it. – Minh Nguyễn ^💬 16:59, 7 September 2022 (UTC)

• I approve this proposal. I support this except the crossing:markings=*:* format. Shouldn't forcefully simplify for simplicity's sake. --- Kovposch (talk) 14:03, 3 September 2022 (UTC)
• I approve this proposal. I think this is a thorough and well thought out proposal, which will improve the ability of mappers to add details to pedestrian crossings in OSM. I agree that current values of crossing= crossing_ref= are currently overloaded with orthogonal values, especially in countries where the one-to-one correspondences with British values are unclear, and I think this will help. --Willkmis (talk) 22:29, 3 September 2022 (UTC)
• I approve this proposal. I nearly missed starting of vote, only passed by to ask, when this is going to happen! There are 12 people that took part in the RfC talks, hope enough will join vote. Maybe I should ping them from talk? On the subject itself: This will allow me to replace the crossing_ref=zebra keys in my area with something much better documented and not giving wrong indications. I want to thank popball for keen perception of the comments brought forward in talk by several participants and careful adoption of the proposed tag values where fit. --Hungerburg (talk) 10:37, 4 September 2022 (UTC)
• I have comments but abstain from voting on this proposal. I would approve this proposal, except that I can't find myself in having crossing:markings=*:* values. Instead, use crossing:markings=*, crossing:markings:*=* or so to specify the type of zebra/ladder or the line count. Hence for now I abstain from voting. --Famlam (talk) 13:44, 4 September 2022 (UTC)
• I approve this proposal. This is a thorough proposal. I like how this would allow clearly separate the markings from the signals. BubbleGuppies (talk) 14:02, 4 September 2022 (UTC)
• I approve this proposal. I have been using this for a while now. It solves the problem of crossing_ref=* being overloaded with markings and also crossing types, while separating signals from markings. crossing=marked is frequently misused at signalized crossings, and crossing:markings=* offers a clear way to untangle this mess. Hamiltonham (talk) 17:41, 4 September 2022 (UTC)
• I approve this proposal. Reasonable way to add more data about crossings in a standard manner. As for the example of "artistic crosswalk", I'd prefer to have more detailed tagging here (some way to indicate the crossing is artistic, and particular some way to distinguish rainbow crossins), but that's a very minor issue and can be added later. --EllieNyaa (talk) 21:33, 4 September 2022 (UTC)
• I approve this proposal. Rtnf (talk) 05:57, 5 September 2022 (UTC)
• I approve this proposal. --Zorae (talk) 08:14, 5 September 2022 (UTC)
• I approve this proposal. While i don't like the crossing:markings=*:* format, i recognize this is a design limitation of storing complex data in a key value array. --Tjuro (talk) 10:19, 5 September 2022 (UTC)
• I approve this proposal. --Rskedgell (talk) 14:20, 5 September 2022 (UTC)
• I approve this proposal. --Omnibeet (talk) 17:22, 5 September 2022 (UTC)
• I approve this proposal. I'd still like to see some guidelines on how to tag crossing:markings:colour=* with examples to make things less chaotic. --VileGecko (talk) 18:59, 5 September 2022 (UTC)
• I approve this proposal. --Hdevine825 (talk) 13:06, 6 September 2022 (UTC)
• I have comments but abstain from voting on this proposal. Many countries only have one style of pedestrian crossing markings. In these countries, the new tags don't add any information, but make editing and reviewing work more laborious. IMO, these tags shouldn't be used there. --Dafadllyn (talk) 16:00, 6 September 2022 (UTC)
• I approve this proposal. "crossing:markings:colour=gold" example seems better represented as "crossing:markings:colour=yellow" for me Mateusz Konieczny (talk) 14:10, 7 September 2022 (UTC)

  I'm not sure about the standards in Switzerland, where that photo was taken, but in the U.S., I'd tag yellow as one of the standard colors for signs and road markings. If I wanted to be more precise, that's when the hexadecimal values would come out. – Minh Nguyễn ^💬 06:29, 9 September 2022 (UTC)

  By law the Swiss paint their zebra stripes in yellow, starting 1936, https://blog.nationalmuseum.ch/2021/11/der-erste-fussgaengerstreifen/. It's the autumn sun that turns them gold on the photo. --Hungerburg (talk) 09:51, 9 September 2022 (UTC)

  @Mateusz Konieczny, @Minh Nguyen, @Hungerburg: It's not just the autumn sun. While the law defines the colour as yellow, the colour RAL 1023 "traffic yellow" is used, which is even more reddish than the web colour gold (nearly web colour orange). Anyway, it would make more sense to define the style and colour as a national default than to tag every single pedestrian crossing. --Dafadllyn (talk) 20:35, 22 September 2022 (UTC)

• I approve this proposal. Finally, a good proposal for an old problem. --AntMadeira (talk) 16:30, 7 September 2022 (UTC)
• I approve this proposal. This is not only a solid proposal but also a good example of how to use the proposal process to rally the community around a fresh approach. We're better off for being able to micromap crossings in even more detail and take some of the pressure off the overloaded crossing=* key. I've been manually using the proposed key locally (even on a crossing multipolygon relation). I appreciate the lack of ambiguity in these tags, even in an international context. – Minh Nguyễn ^💬 18:33, 7 September 2022 (UTC)
• I approve this proposal. --Nbolten (talk) 19:15, 8 September 2022 (UTC)
• I approve this proposal. Thanks for pushing this proposal through and clarifying these tags! --Akadouri (talk) 19:20, 10 September 2022 (UTC)
• I approve this proposal. Like crossing:signals , I think this can make crossing more detailed and standrized. --快乐的老鼠宝宝 (talk) 22:25, 10 September 2022 (UTC)
• I approve this proposal. --Tordanik 19:11, 11 September 2022 (UTC)
• I have comments but abstain from voting on this proposal. comments --Rmikke (talk) 21:28, 11 September 2022 (UTC)
• I approve this proposal. --Nw520 (talk) 23:37, 11 September 2022 (UTC)
• I approve this proposal. Hopefully we can also deprecate crossing=marked in the future now that this tag handles that property. --Riiga (talk) 06:59, 12 September 2022 (UTC)
• I approve this proposal. --EneaSuper (talk) 11:31, 12 September 2022 (UTC)
• I approve this proposal. I oppose this proposal. I don't like that *:* values are introduced in this proposal. Because this further increases the complexity of tagging stuff. And if allowed here it should/must be allowed in all future proposals too. And personally I think such a decision should not be hidden in a proposal about crossing-markings. Or did I somehow miss that *:* are already common tag values...? --Shaun das Schaf (talk) 13:50, 12 September 2022 (UTC)

  There's no requirement for every format to be the same. It's already common in surface=concrete:* vs surface=paving_stones + paving_stones:*=*. --- Kovposch (talk) 18:38, 12 September 2022 (UTC)

  You are right. It's already in common use with surface=concrete:*. I therefore changed my vote. --Shaun das Schaf (talk) 06:45, 13 September 2022 (UTC)

• I approve this proposal. Something B wiki (talk) 22:20, 12 September 2022 (UTC)
• I approve this proposal. I think crossing=zebra should also be cleaned up and deprecated. --Gyotoku810 (talk) 03:04, 16 September 2022 (UTC)
• I approve this proposal. This can clear up some of the confusion and subsequent ambiguity that crossing tagging has had. I would love to see crossing marked deprecated in the future, and also some consideration of data collectibility and interpretability downstream by routing applications so they can provide information in a coherent way about traffic controls that apply to a crossing. --Uwtcat (talk) 19:59, 16 September 2022 (UTC)
• I approve this proposal. --Timmy_Tesseract (talk) 02:53, 17 September 2022 (UTC)