Proposal:Road marking revision

Road marking revision
Proposal status:	Approved (active)
Proposed by:	Supaplex030
Tagging:	road_marking=* stroke=* pattern=* arrow=* symbol=* Data item
Applies to:	, ,
Definition:	Improving existing approaches for mapping road markings as separate features.
Statistics:
Draft started:	2025-04-18
RFC start:	2025-06-01
Vote start:	2025-06-27 00:00:00 (UTC)
Vote end:	2025-07-10 23:59:59 (UTC)

Proposal

Road markings are a common part of roads all over the world. Even though road markings are not one of the "typical" things we map in OSM (since we mostly capture their meaning rather than the markings themselves), there are situations or needs where explicitely mapping them with OSM is helpful.

For some time now, there has been a wiki page with suggestions for road marking values, which were initially used by a single mapper. The suggested values do not seem to follow any particular system, but are a collection of rather overspecific values merging function and styling of markings. Nevertheless this tagging is used continuously, especially for mapping stop lines (of which over 35,000 have already been mapped using this scheme). The aim of this proposal is to reorganize the road markings scheme by introducing easier to use categories, making it more applicable to mappers and data consumers.

Note: Usually it is not necessary to map road markings as separate features, as long as their meaning is reflected in the data through appropriate tags. Typical tags that are indicated by road markings are turn:lanes=*, overtaking=*, change=* or crossing:markings=*, for example. The presence of lane markings on a road can be specified with lane_markings=* on the highway line (as well as the number of lanes themselves by counting lanes=*).

Even for rendering, using the tags mentioned above in combination with further information like placement=* or width:lanes=* is sufficient to render exactly representations of road markings. Nevertheless, there may be situations in which it makes sense for some mappers to explicitly map road markings (as the increasing use of the existing schema shows). One use case could be, for example, the cartographic representation of intersections or other complex roadway situations, which up to now can only be represented in OSM in a highly generalized form without being able to identify the detailed layout of the roadway areas.

Rationale

The existing in-use documentation of the road_marking=* key unsystematically lists a large number of different values that describe the type and appearance of markings very specifically (e.g. dashed_yield_line or solid_stop_line). The open-ended approach makes it difficult to interpret the values, in some cases even colors are used as part of the value "in the wild". The list would become longer and less interpretable over time if usage grows in countries all over the world with their different types and styles of road markings. On the other hand, there are suggested values like dash that are also hard to interpret because they could be lane, centerline, edge or crossing lines, for example.

Therefore, this proposal aims to categorize road markings into more generic classes and provide a set of additional attributes to further describe their style and meaning. One difficulty in categorizing road markings is that it can be based either on the function of a marking (e.g. stop line, lane divider, edge of carriageway, crossing edge...) or on its design (dashed line, double solid line, shark's teeth...). Both classifications have advantages and disadvantages, e.g. the design is identifiable even if the meaning is not known. Data users, on the other hand, may be more interested in the function (e.g. distinguishing between solid stop lines and solid lane dividers). This proposal tries to avoid the conflict by proposing functionally oriented, but very generic values that are easy to identify and can be specified using sub-tags.

Tagging / How to map

The road markings key is intended for mapping road markings as separate features, i.e. with their own geometry (and not, for example, on a highway line).^{[note 1]}

Depending on the category, road markings can be mapped as lines, points or areas. Add road_marking=* with one of the values listed below as well as further specifying tags if needed, e.g. for styles (line strokes, area patterns) and physical properties. In many cases, road markings have an influence on other tags, which should always be aligned (see the references in the table below).

If road markings are mapped in a location where the areas of roads and streets are also mapped with area:highway=*, the road markings are always mapped in addition, i.e. "on" the carriageway areas.

Typical Values

Illustration	Value	Geometry	Description	Interdependence with other tags
Describing linear markings
	road_marking=stop_line		A stop line e.g. in front of a traffic signal, traffic sign or (other) junctions. Can be mapped as a line following its real location, or alternatively as a point on the highway line. Add stroke=* to specify the style of the stop line (e.g. solid or sharks_teeth). If mapped on a node on the highway=* line, add direction=forward/backward to specify which direction of travel is affected by the stop line.	highway=stop highway=give_way highway=traffic_signals
	road_marking=lane_divider		Lane markings to demarcate individual lanes. Add stroke=* to specify the style of the lane marking (e.g. dashed or double_solid).	lane_markings=* lanes=* change=* overtaking=*
	road_marking=edge_line		Marking the edge/boundary of the carriageway. Add stroke=* to specify the style of the edge marking (e.g. solid).
	road_marking=crossing_edge		Edge/border markings of pedestrian or cycleway crossings. Add stroke=* to specify the style of the crossing marking (e.g. dashed).	crossing:markings=*
Describing areal markings
	road_marking=restriction		Neutral areas or restriction markings, like gore chevron or no-parking markings. Add pattern=* to specify the style of the restriction marking (e.g. chevron or stripes). Add reason=* to specify, why a restriction is marked (e.g. bus_stop, driveway or emergency).	parking:side parking:side:restriction=*
	road_marking=crossing		The (areal) marking of a crossing to map the extent of crossing markings or colored surfaces in detail. Note: In general, tags like crossing:markings=* or surface:color=* at the highway crossing line should be sufficient to describe such markings. Add pattern=* to specify the style of the crossing marking (e.g. solid). It is also possible to use the values known from crossing:markings=* (e.g. zebra), but these can be derived from any existing crossing lines and duplicate information should be avoided. Add colour=* to specify the colour of the crossing markings.	crossing:markings=*
Describing symbolic markings
	road_marking=arrow		An arrow, usually to indicate turn directions, but also for indicate driving or oneway directions or overtaking hints. In contrast to other symbolic road markings, arrows are mapped as lines (instead of points) by most mappers. It is therefore recommended to map arrows as a simple line between two points corresponding to the length and direction of a single arrow with the line starting at the "foot" (base) of the arrow. Add arrow=* to specify the form of the arrow, usually using values from turn=* (like left, through, through;right, merge_to_left, reverse, ...) or restriction=* tagging (like no_u_turn, no_right_turn).	turn:lanes=*
	road_marking=traffic_sign		An equivalent of a traffic sign applied as a road marking. Add traffic_sign=* to specify the shown traffic sign.	traffic_sign=* maxspeed=* hazard=*
	road_marking=text		Lettering on the road surface like "BUS", "SLOW" or "King St.". Add inscription=* to specify the written text.	lanes=* (like lanes:bus=*) access=* (like bus:lanes=*) hazard=*
	road_marking=symbol		A symbol or pictogram applied as a road marking. Add symbol=* to specify the shown pictogram.	e.g. cycleway=*

Additional attributes

Stroke, pattern and symbol styling

Use the tags stroke=* (for ways), pattern=* (for areas), arrow=* (for arrows) and symbol=* (for symbols) to further describe the design of road markings:

stroke=*

Use stroke=* to describe the style of linear road markings.

Some line attributes like stroke=sharks_teeth are "directed" and therefore dependent on the line direction. In this case, the stroke elements are considered to "point to the right" from the line direction (in case of shark's teeth, the tips of the teeth point to the right).

Double lane markings with different stroke styles on each side can be specified with stroke:left=* and stroke:right=* (seen in the line direction).

• 
  stroke=solid
• 
  stroke=dashed
• 
  stroke=double_solid
• 
  stroke=double_dashed
• 
  stroke:left=solid +
  stroke:right=dashed
  Depending on line direction.
• 
  stroke=sharks_teeth
  Deprending on line direction.
• 
  stroke=zigzag

pattern=*

Use pattern=* to describe the style of areal road markings.

• 
  pattern=stripes
• 
  pattern=crosshatch
• 
  pattern=chevron
• 
  pattern=zigzag
• 
  pattern=chessboard
• 
  pattern=solid

arrow=*

Use arrow=* with the common values known from turn=* to specify the form of an road_marking=arrow (like left, through, through;right, merge_to_left, reverse, ...). In rarer cases, arrow markings may also show icons known from restriction=* (like no_u_turn, no_right_turn).

Examples:

• 
  arrow=left
• 
  arrow=left;right
• 
  arrow=no_right_turn
• 
  arrow=no_u_turn

symbol=*

Use symbol=* to describe the style/form of symbolic road markings (road_marking=symbol). Use a generic term such as bicycle, pedestrian, hov (see hov=*) or airport (see also destination:symbol=*). (Note: In this case, symbol=* is used homonymously with the existing use of symbol=* for the human readable equivalent of osmc:symbol=*, describing route symbols that are used as waymarkers or on guideposts. In the context of road markings, however, symbol=* fits ideally into existing schemes such as destination:symbol=*.)

Examples:

• 
  symbol=bicycle
• 
  symbol=wheelchair

Other additional attributes

There is a bunch of tags that can provide additional information describing the size or other physical properties of road markings:

• width=*, especially for linear road markings to distinguish narrow from wide markings,
• colour=*, e.g. whether there are white or yellow markings,
• direction=* on nodes to specify where the markings are facing to,
• length=* on nodes to specify the size of symbolic road markings (beside width=*).

Others could be added if needed, but aren't part of this proposal, like the technical form (paint, plastic/thermoplastic/tape, surface (like markings made from (paving) stones), studs) or, related to that, material=* (plastic, metal, stone...).

Examples

	Shark's teeth stop lines at a junction. road_marking=stop_line + stroke=sharks_teeth
	Neutral area at an exit ramp forming a theoretical gore. road_marking=restriction + pattern=stripes
	Marking at a bus stop to raise attention and prevent cars from stopping. road_marking=restriction + pattern=zigzag + reason=bus_stop
	A pattern on a junction that can be driven over but it is not allowed to stop within it (see also box junction). road_marking=restriction + pattern=crosshatch + reason=junction
	Colored road surface on a bike lane, intended as a warning indicator on a crossing. road_marking=crossing + pattern=solid + colour=red
	A yellow centerline with dashed lines on one side and a solid line on the other. Note: Do not use road_marking=* tags on highway=* lines itself. To specify the style of road markings directly at the highway line, a further schema needs to be developed in the future. road_marking=lane_divider + stroke:left=dashed + stroke:right=solid (seen in line direction: dashed on the left, solid on the right side) + colour=yellow
	Wavy lane markings around a zebra crossing. road_marking=lane_divider / edge_line + stroke=zigzag
	Turn lanes marked with arrows... road_marking=arrow + arrow=through/arrow=right ...from left to right separated by lane markings... road_marking=lane_divider + stroke=dashed ...and two different neutral areas road_marking=restriction + pattern=chevron/pattern=stripes
	Destination markings (arrow, text, symbol) near an intersection. road_marking=arrow + arrow=through road_marking=text + inscription=TRIER road_marking=symbol + symbol=motorway

Footnotes

External discussions

• Discussion page of the existing road_marking documentation.
• Newer discussion in the community forum about mapping junction and gore road markings.
• (RFC) Feature Proposal – Road marking revision

Comments

Please comment on the discussion page.

Voting

• I approve this proposal. --Pavvv (talk) 22:37, 27 June 2025 (UTC)
• I approve this proposal. --Mueschel (talk) 07:21, 28 June 2025 (UTC)
• I oppose this proposal. I can't see any real-world use case about this kind of micro-mapping that can't be handled through existing tags. And while I can see how standard values are necessary in general, it should be noted that nearly half of this key use are from two imports circa 2014 and 2017. Half of the key use nowadays is about a stop line or a give way, which can already respectively be mapped as highway=stop and highway=give_way. Right now I'd rather recommend against using this key if anything. --Lejun (talk) 11:15, 28 June 2025 (UTC)

We have no relevance criteria at OSM for good reasons. So if you don't see any use cases in this tagging, then don't use it. Others obviously see them, otherwise they wouldn't have used this tagging. (I for example for renderings of intersections: example 1 | example 2.) --Supaplex030 (talk) 12:50, 28 June 2025 (UTC)

@Lejun: One of the (stealth) imports you're referring to was mainly about stop lines at signalized intersections. However, these stop lines could not be represented as highway=traffic_signals due to the prominent local practice of staggered stop lines. – Minh Nguyễn ^💬 21:01, 2 July 2025 (UTC)

I don't think rejecting a proposal for a physical feature makes sense, if the only criticism is "I cannot imagine a use case". --Dieterdreist (talk) 16:09, 3 July 2025 (UTC)

• I approve this proposal. --Tordanik 13:22, 28 June 2025 (UTC)
• I approve this proposal. --Broiledpeas (talk) 15:18, 28 June 2025 (UTC)
• I approve this proposal. --Riiga (talk) 12:49, 30 June 2025 (UTC)
• I approve this proposal. --Chris2map (talk) 15:20, 30 June 2025 (UTC)
• I have comments but abstain from voting on this proposal. I feel like the micromapping is fairly complex and see limited use of it in general, especially. Certain features are very useful when added to existing features, however, such as on the highways themselves, stroke for divider and pattern for the flush median proposal I drafted quite a while ago as well as certain other features like placing stop_line nodes onto the ways (since they're sometimes further away than usual because of driveways or something). --ManuelB701 (talk) 09:43, 2 July 2025 (UTC)
• I approve this proposal. There are still some edge cases to iron out on the margins, like how to tag a crossing edge that doubles as a stop line (extremely common in California). Some raw tag values like pattern=chessboard will need translations into more idiomatic English (checkerboard or draughtboard) for editor preset fields. But overall this is a big step in the right direction compared to the messy table that we've been coping with for years now. I look forward to mass-retagging the import in my area that helped popularize road_marking=* back in 2017. – Minh Nguyễn ^💬 21:14, 2 July 2025 (UTC)
• I approve this proposal. --Dieterdreist (talk) 16:07, 3 July 2025 (UTC)
• I approve this proposal. --Severin (talk) 08:01, 5 July 2025 (UTC)
• I approve this proposal. --Marc Mongenet (talk) 10:17, 5 July 2025 (UTC)
• I approve this proposal. --Tordans (talk) 11:37, 6 July 2025 (UTC)
• I oppose this proposal. I see no value in micromapping to this degree, while the maintenance burden is high. The proposal does not motivate the possible usefulness for this, it handwaves it as "sometimes it's helpful". Could you describe in what way it's helpful? I'm struggling to see any useful application for this apart from making detailed renders, which as others have said elsewhere can be used to legitimise anything. —M!dgard 🇧🇪 (talk) 14:21, 6 July 2025 (UTC)

As already written above: With this argument, you are voting in favor of relevance criteria in OSM and against the “map what you want (whats on the ground)” principle. This proposal is not about motivating mappers to map road markings. But if someone wants to map road markings for any reason, then there will be a schema available. (I personally map road markings for two reasons: As mentioned above for renderings of intersections, and for mapping restricted areas, which are used in OSM parking processing. But I don't care for what reasons others map something, and in my opinion it's not my business to judge it). --Supaplex030 (talk) 17:22, 6 July 2025 (UTC)

Thanks for replying. I'm voting in favour of having a map instead of a painting of the world. By the logic of "map whatever you want" we should be okay with it if people want to map each individual pavement tile as an area. The reasons I'd not be happy about that (and I'm not happy about mapping road markings) is because data doesn't exist in isolation: everything that's mapped is 1) visible in editors, making it more complicated (for beginners) and more involved (for power mappers) to edit, and 2) needs to be maintained, or it becomes stale. We're looking at loads of data with high maintenance requirements and questionable use, so I find we should make a balance. On the up side, it's more intuitive than yet another tag added on the main road, such as the street parking scheme.
Another practical concern: it will require some clever software and quite some processing to have a renderer that can make sense of these lines in combination with roads mapped as lines. I'm not convinced such a renderer will be created.
As for parking spaces, I don't really understand what you mean when we have the tags to express parking prohibitions already? You want to be able to tell definitively for every square foot whether you can park there or not? —M!dgard 🇧🇪 (talk) 22:31, 6 July 2025 (UTC)

Dealing with the increasing complexity of data and "map skeletons" has been a challenge for OSM and its mappers for as long as OSM has existed. The level of detail of our data today is in many places completely different to what it was 5 years ago and of course even more so than 15 or 20 years ago. So far I know of no evidence that this is a significant barrier to contributing to OSM. Perhaps a mistake happens more often if you accidentally edit data that is "in the way" - but at the same time, editors and monitoring tools are advancing and simplifying things. If we had always focused on the concerns about increasing complexity in OSM instead of its opportunities and how tools need to be adapted to deal with it, OSM would certainly not be what it is today. And who knows: maybe the way we map road-related details in the future will also change fundamentally in the next 10 years, with strongly graphically oriented editor support? But in my opinion, these are all exciting fundamental discussions that we should perhaps take up elsewhere.

(And regarding parking: Yes, with precise mapping we can already say for virtually every square meter whether you can park there or not. This is simply a question of precise mapping; the analysis tools for this are available. Here is an example of a processed parking data set based on OSM that we created for a Berlin geoportal). --Supaplex030 (talk) 21:10, 7 July 2025 (UTC)

I think there is a misconception here because we do not vote whether to map these or not, the question is how fit is the proposal for mapping the markings if you want to map them. —Dieterdreist (talk) 19:28, 8 July 2025 (UTC)

• I approve this proposal. --Caboulot (talk) 15:50, 6 July 2025 (UTC)
• I approve this proposal. --scai (talk) 16:05, 6 July 2025 (UTC)
• I oppose this proposal. I see no use for these. Too much maintenance required, virtually nobody will make use of them, and they add unnecessary bloat in the database (I know storage prices keep plummeting, but this much detail makes processing times longer)... and don't say it's "for the renderer" because Carto hates rendering any road details (like highway areas). Oh right I forgot, imagery quality isn't nearly good enough in many places for road markings to be mapped accurately w/o surveying. Le Sharkoïste (talk) 17:13, 6 July 2025 (UTC)
• I approve this proposal. --Michi (talk) 19:43, 6 July 2025 (UTC)
• I approve this proposal. The argument "micro mapping" and "no use case" or "won't be used widely" are imho all faulty arguments. It's better to have a solid proposal in place to have structured data available instead of random cluttered data that doesn't add up, even if the usage is limited. Nothing is worse than unstructured data that follows no rationale/logic so every well-documented proposal to bring structure into adding physical properties to OSM is welcomed by me --Hike&Map (talk) 06:58, 7 July 2025 (UTC)
• I approve this proposal. --Mlvln (talk) 10:31, 7 July 2025 (UTC)
• I oppose this proposal. 1) Until we don't map all road lanes separately, I see no point in mapping all of their markings separately. 2) I think this is also an instance of Tagging for the renderer, even if Carto doesn't render it. 3) This doesn't follow one of the main philosophies of highway (and railway) tagging: map associated objects on the way, not separately. 4) Therefore, connecting separate road_marking=* objects to their respective highway=* elements would be really difficult. —Gymate (talk) 10:36, 7 July 2025 (UTC)

• Regarding 1, 3 and 4: I'm afraid this is a misunderstanding that I will have to clarify in the documentation of the schema after the proposal has been approved. road_marking=* lines should not be used to map standard linear road markings along roads (lane dividers and road edges). Such attributes do indeed belong on the centerline or can be derived from centerline attributes, as described in the proposal. Footnote 1 points out that there is potential here later to record further marking details on the centerline. (During the development of the schema, I thought about extending the schema to centerline tags, but then deliberately excluded this from the proposal, as it involves a different logic).

However, there are situations, especially intersections, that we are not yet able to model well (linearly) in OSM. In such cases, it can be useful to also capture linear road markings such as lane dividers separately. For other, especially non-linear markings, road_marking=* tagging can be an opportunity to capture their location more precisely (or, like in the case of restricted areas, at all). With precise highway mapping (positioning of the centerline, using of lane, placement and width attributes) it is even possible to link individual lanes with separately mapped road markings (I am currently experimenting with this in the context of the further development of the Straßenraumkarte).

• Regarding 2: The principle of "tagging for the renderer" means something different, namely the intentional (mis)use of incorrect tags to create a desired map representation (for example, mapping barrier=walls as 'road markings' to make it look like road markings in maps/renderings). --Supaplex030 (talk) 20:48, 7 July 2025 (UTC)

• I approve this proposal. --Mcliquid (talk) 13:48, 7 July 2025 (UTC)
• I approve this proposal. I second Hike&Map's comments above. --Jarek Piórkowski (talk) 19:01, 7 July 2025 (UTC)
• I approve this proposal. I also second Hike&Map's comments above. I am a novice mapper, and reading the proposal i find it hard on how to implement it. I have the feeling that there are some double ways to map marking. Like the bike crossing lines. I am from the Netherlands and we have more markings, like a green line with dubble white at eachside. Forgive me if i am missing some clues. --De pelgrim (talk) 20:20, 7 July 2025 (UTC)
• I approve this proposal. --Weidner (talk) 08:45, 8 July 2025 (UTC)
• I approve this proposal. --Pogregoire (talk) 19:36, 8 July 2025 (UTC)
• I oppose this proposal. Very unclear to me after reading the proposal how should many of them be mapped. For example, to map an arrow to the left, should I map a 1-segment way (beetween which points ?) ? a 2 segments way (L-shape) ?, should I add a " > " shape at the end of the arrow ?

Similar type of questions for many keys --Djam (talk) 22:17, 9 July 2025 (UTC)