road_marking:stroke=* and road_marking:colour=* are already somewhat common; so you feel strongly about ditching the namespace? My only concern is that some markings lend themselves to being mapped as areas, which makes them more likely to be dual-tagged with other primary feature tags, which could cause some ambiguity around words as generic as “stroke” and “pattern”. On the other hand, I’d be inclined to use a plain colour=* on a road marking unless something else forces me to tag otherwise. – Minh Nguyễn💬 17:09, 18 April 2025 (UTC)
For me, the use of symbol=* would be a case of homonymous use. To be honest, I don't see many problems with homonyms, i.e. when a "suitable" key has different meanings depending on the context (except that it makes documentation in the wiki more difficult). Supaplex030 (talk) 07:24, 19 April 2025 (UTC)
It was my intention to use them without namespace, as I always see the danger of inconsistencies in the use of namespaces, if some tags are used with namespace and some without, although they all refer to the primary key. I prefer to use namespaces only if a tag does not refer directly to the primary key itself, but to one of its "components", e.g. one could think about something like lane_markings:stroke=* or cycleway:right:marking:left:stroke=* on highway lines.
Otherwise, maybe I should add a note that road markings should be mapped separately anyway according to "one feature, one element" good practice... But even if you are using road_marking=* e.g. on an area:highway=* polygon, e.g. a junction or bus bay, the meaning of pattern=* would still be clear in my opinion.
However, I wanted to think again about how road_marking=* and stroke=* could be used on the highway line itself to better describe the design of common road markings directly. Supaplex030 (talk) 07:22, 19 April 2025 (UTC)
Lane dividers
I’d suggest lane_divider, because lane could refer to other kinds of lane markings, such as a pattern denoting a bike lane or bus lane. – Minh Nguyễn💬 17:16, 18 April 2025 (UTC)
Personally, if road_marking=* is to be used for functionality, I would align it with attributes. This could be more uniform and direct.
Exactly to avoid having to reflect this "diversity" of lane-related markings in an overly long list of values, I wanted to introduce a simple lane value that is as unspecific as possible and can potentially be used for any longitudinal, lane-related marking. Currently, my idea is that all markings that define a lane in any way come together here, regardless of the mode of transport. So not only for lanes for motor vehicles, but also lanes for bicycles (cycleways), motorcycles, buses, stationary traffic (parking)... And I bet there are more of these types in other parts of the world.
Otherwise we potentially continue following the open-ended character of the value list again... Consequently, I'm even thinking about merging centerline, edge and lane dividers completely into the lane category, but introducing a kind of road_marking:function=* if it's needed to specify this (road_edge, centreline, lane_divider, crossing_edge, cycleway, parking, ...). This function could also be interesting for differentiating areas (gore, traffic_island, no_parking, emergency, bus_stop, junction...) or symbolic markings (access, maxspeed, turn etc. – see also below). Here we are back to finding the balance between function and design... Supaplex030 (talk) 07:31, 19 April 2025 (UTC)
Lane divider versus bus lane pavement application I think intuitively there’s a difference between a marking that divides two lanes and a marking or pavement application that indicates the presence of a lane. Consider a bus lane, which in the U.S. is painted solid red with a “BUS ONLY” or “BUS LANE” in white lettering. This is a lane marking, whereas the solid line immediately to the left is a lane divider. One says “don’t use this lane”; the other says “don’t change lanes”. If you want to consolidate them into a single tag for lane-related markings, that’s fine, but we’ll still need iterative refinement, because “lane-related” is a theme, not a function. – Minh Nguyễn💬 03:49, 21 April 2025 (UTC)
Seems unnecessary to group edge markings with lanes, while it does mark the outer side of outer lanes. Crosswalk edge is basically transverse (except when shared with highway=pedestrian ) , not longitudinal. Mixing them is too much. —— Kovposch (talk) 06:52, 21 April 2025 (UTC)
Longitudinal and parallel stroke patterns
The proposal calls for stroke=solid_dashed and dashed_solid to indicate parallel strokes, presumably read left to right. I think we need a different syntax for this, either solid;dashed or solid|dashed. The current syntax is easily confused with longitudinal dash patterns, such as dash-dot-dash or triple-dot space triple-dot (typical when the marking is made of Botts’ dots or similar). – Minh Nguyễn💬 17:23, 18 April 2025 (UTC)
We could also use stroke:left=* and stroke:right=*. In combination with stroke=* (or stroke:centre=*), even triple markings could be mapped in this way. This notation would also have the advantage that we prevent the development of endless new values such as dotted;solid, dashed;dotted, dash_dot_dashed;solid, ... over time, which nobody would interpret. Supaplex030 (talk) 07:35, 19 April 2025 (UTC)
Yes, marking=* is also part of a proposal of mine, but this part is not yet very well thought out. I think I would later align it more with what is created here with road_markings=*. The alignment to crossing:markings=* is also difficult, which more follows the previous logic of road_markings=* (open ended design approach). Supaplex030 (talk) 07:37, 19 April 2025 (UTC)
What I wanted to avoid is abusing area:highway=*-parts solely for mapping changes in surface colors, as I myself have done so far, e.g. here. This allows nice renderings, but in the end it is the same road area. road_marking=junction + colour=* works very well for this in my opinion. If someone wants to map surface color areas, e.g. on cycle paths, area:highway=cycleway + colour=* seems to me to be a good fit (sample experiment). Supaplex030 (talk) 07:42, 19 April 2025 (UTC)
I am not a fan of area:highway=junction/crossing, but prefer area:highway=tertiary/... + junction=*/crossing=yes. The class of the (higher-ranking) road is very important information that I expect to find directly in the OSM data. And it is also documented and widely used in this way.
But that's another topic. I have now listed the above example as road_marking=crossing + color=red under the examples for now. Supaplex030 (talk) 22:35, 23 April 2025 (UTC)
To finish my take here, in effect this is already not possible. A highway=motorway legally, and other roads officially terminating at junctions would not have the area:highway=* set to it. This would be consistent with how the highway=* lines are classified. —— Kovposch (talk) 08:14, 24 April 2025 (UTC)
I am also unhappy yet with the lack of distinction of the various possible "non-drivable" and "drivable" restriction patterns. However, I strongly tend to not differentiating them by functionally directly in the value, as their meaning might not be immediately apparent to every mapper – and there could be a lot of meanings/functions. I therefore prefer as few or even just one "restricted/restriction" value as possible.
There is currently a suggestion in the proposal to use reason=* to differentiate between various "functions" of restricted areas. However, I am actually more in favor of introducing a function=* sub-tag to be able to capture the type of restriction if necessary/when the mapper knows it. Your Japanese example would then be a case of road_marking=restricted + function=[traffic:]island or something like that. A box junction could then be road_marking=restricted + function=junction or similar. Supaplex030 (talk) 07:48, 19 April 2025 (UTC)
Also symbol=* is being used for freefrom text for osmc:symbol=* . That needs to be worked on.
—— Kovposch (talk) 20:11, 18 April 2025 (UTC)
Your many examples show that it becomes confusing very quickly to consider "point-shaped" road markings in purely functional terms. For pragmatic reasons, I therefore think it is a good compromise to categorize these types of road markings more according to their form. Your three very different cases of arrows (turn, oneway, restriction) alone show that we are otherwise moving into a rabbit hole. I could also think of other arrow-like markings, such as overtaking hints.
By the way, someone pointed out to me that we should map arrows as (directional) lines instead of points with direction=* and length=*. I've noticed that the current usage for arrow road markings is also mostly lines (I seem to be one of the few who have handled it differently so far). I will therefore change the preferred geometry for arrows from "node" to "line". Supaplex030 (talk) 07:54, 19 April 2025 (UTC)
Left or right arrow I probably have been mapping arrows as lines as well, but I wonder what this would mean for a compound arrow that can’t be represented as a single directional way, such as a left;right – it’s either two ways or one of the ways is backwards. – Minh Nguyễn💬 03:55, 21 April 2025 (UTC)
Side-by-side arrows (perhaps not explicitly prescribed, upcoming dedicated auxiliary lane, to distinguish from shared movement lanes): How to reliably associate them, whether spatially is enough File:Akasaka_(15241798665).jpg (this has a slip lane, while being dashed)
Crossed-out arrow (thinking this is not very legal, especially from a private road) File:No_turn_right_marking_2022-04.jpg (Worse they are different colors)
Presumably others can be solved with *pattern=* and *colour=*
On the topic of layout/arrangement, vertically written CJK text markings would similarly need to distinguish the direction=* when drawn as line. Besides multi-line destinations. —— Kovposch (talk) 06:24, 21 April 2025 (UTC)
This could be something for orientation=vertical/horizontal. I use this e.g. for playground equipment where there are vertical or horizontal versions... For multi-line lettering you could either think about several separate features, a line count tag or a max char wrap tag, but I'd rather leave these details to people who would use this in practice ;) Supaplex030 (talk) 22:40, 23 April 2025 (UTC)
By using a “single directional way”, I actually meant a “straight” line that *does not* follow the (curved) geometry of the arrow. In other words, it simply reflects the direction of the “foot” and the length of the marking. I think that due to the large number of arrow shapes, we have to live with the limitation that the “standard tags” can only represent the “standard shapes” and for special shapes you may have to use local sub- or other special tags.
Regarding the crossed arrows mentioned above, you could perhaps use combinations of values from the turn and restriction namespaces, such as through;no_right_turn, only_u_turn or no_u_turn. The exact shape/appearance of the arrows can probably be derived from local conventions.
Finally, it would also be possible to pass an image URL (similar to image-/wikimedia) with the exact shape to a symbolic road marking feature if required. But I think that is outside the scope of this proposal. Supaplex030 (talk) 22:38, 23 April 2025 (UTC)
In my opinion, it is primarily about creating clearly definable “classes” that are as clear as possible in order to develop a tagging scheme that can be used in practice by many mappers and users. And from this perspective, “stop lines” and “arrows” seem to me to be clear classes of lane markings. (Side note: “arrow” can also be understood functionally, as it has the function of indicating a direction. But of course, if you want to evaluate the exact function of the arrow, you need a sub-tag like XXX=turn/oneway/...). Supaplex030 (talk) 22:41, 23 April 2025 (UTC)
Depends on your definition. A solid or dashed stop or give-way line functions as the edge at a junction, and delineates a lane when a lane merges with special priority control. Of course, they are not edge line, or lane line, officially, but then we can also argue about how markings are defined as a "traffic sign" in some countries viz UK. —— Kovposch (talk) 08:24, 24 April 2025 (UTC)
Mapping centerlines and lane dividers separately
After thinking a bit about this, I am not sure that it is a good idea to map road markings that are parallel to the highway separately. Especially road_marking=centerline would often lead to a separate way that is exactly at the same position as the highway=* way. But also when there is more than two lanes, the highway=* way would often share the same position as road_marking=lane. I think that it is better to add this information as tags to the highway=* way. Discostu36 (talk) 15:55, 21 April 2025 (UTC)
Established tags for the highway=* way already communicate everything there is to know about the centerline and lane dividers – except for their geometries and relationships with other markings. In the case of a 2+1 road, the painted center stripe is unlikely to coincide with the drawn way. The same is true with a segment with turn lanes near an intersection. This accounts for the majority of times I've bothered to map centerlines: first it starts with mapping the (staggered) stop lines, then the lane dividers that connect them to each other, and so on. With enough guessing, it is possible to reconstruct these marking geometries from lanes=*, placement=*, etc., but explicitly mapped markings are attractive in cases where tags on other ways simply aren't expressive enough to describe the geometry well. – Minh Nguyễn💬 20:42, 21 April 2025 (UTC)
This is optional micro detail. The centerline is still unlikely to be drawn when the highway=* follows it. Explicitly showing such a situation can be discussed. —— Kovposch (talk) 07:54, 22 April 2025 (UTC)
I actually agree with you: In general, it is not necessary to map road markings separately and I don't really want mappers to feel motivated to do so. Projects like the Straßenraumkarte shows that road markings can already be derived quite exactly from other tags (if well mapped) - at this intersection here, for example, not a single road marking is mapped separately (apart from an experimental cycleway:marking:both=solid_line, which can be expressed just as well by cycleway:lane=exclusive). An interesting use case, in my opinion, would be within intersection areas, for example, where it is currently almost impossible to achieve an accurate representation of the lane layout in OSM. Or in other special cases.
For a “standard road” (i.e. 98% of the road network), lane_markings=*, lanes=*, placement=*, turn:lanes=*, change:lanes=*, width:lanes=* etc. are sufficient to achieve the same result. But I think it would be great if we could use the road markings logic to specify lane_markings=yes (a terribly unspecific pick!) more precisely on the highway=* line itself. I've added a new section with some initial ideas. Supaplex030 (talk) 22:48, 23 April 2025 (UTC)
Colour
surface:color is a color of asphalt (example red bus lane). Need add "symbols:color(colour?)" for marking (example for white-yellow dual color crossong) - Corsa (talk) 09:49, 5 May 2025 (UTC)
What about painted islands? Could this proposal include and deprecate this value of the traffic calming tag? --AntMadeira (talk) 16:19, 1 June 2025 (UTC)
Thanks for that hint! A deprecation is out of scope of this proposal IMHO; whether traffic_calming=painted_island really is an unfavorable choice should be decided elsewhere. But we could add a note on that tag, that with road_marking=restriction (+ reason=traffic_island) there might be a better alternative. There are also “painted_table” and a few other painted_* values – so that's a separate topic. Supaplex030 (talk) 17:11, 1 June 2025 (UTC)
Yes, even without a call to deprecate that tag, if this proposal puts forward and approves a better solution, that should be indicated in the painted island wiki. --AntMadeira (talk) 18:04, 1 June 2025 (UTC)
This reminds me that we need a pattern=solid for solid-filled areas, which the MUTCD devotes seven pages to. [1] Solid painted areas are also used as aesthetic treatments on sidewalk extensions to mimic physically raised areas. [2][3] – Minh Nguyễn💬 05:01, 2 June 2025 (UTC)
Thanks, I added that. This also fits the crossing example with a solid colored area. (I assumed that an area with colour=* implies a solid pattern, but it is better to make this explicit). I have also added pattern=chessboard (was too specific for me at first, but why not...)
Regarding crossing areas, it would also make sense to use the values from crossing:markings=* for pattern=* to specify crossing area marking styles. There is a little break in the tagging logic here: crossing:markings=* is established, it is too late for "crossing:pattern" or similar. But for consistency reasons, I would only use the pattern=* key to specify the style of areal crossing road markings. However, I think it is generally not necessary to specify the type of crossing:markings on crossing road marking areas, as this can be derived from crossing lines and we thus avoid duplicate information.
In the case of solid, there would still be the small inconsistency that this might be identical to surface. But I don't see this as a real issue. Supaplex030 (talk) 06:23, 2 June 2025 (UTC)
School zone warning road markings in Queensland, Australia. Traffic calming road marking?
`road_marking=traffic_sign asks to add traffic_sign=* to specify which sign is shown. How can we distinguish this situation from a case where a physical traffic sign is present in the same place? --Mueschel (talk) 18:09, 1 June 2025 (UTC)
I assume you mean a traffic sign mapped as a node on the highway line? (Not the "real" physical location of the traffic sign, that can be indicated by using highway=traffic_sign?) "Physical" and "symbolic" traffic signs shouldn't share the same node. road_marking=* is a primary key. So a node with traffic_sign=* + road_marking=traffic_sign is a road marking, a node with traffic_sign=*, but without road_marking=*, isn't a road marking. Supaplex030 (talk) 19:28, 1 June 2025 (UTC)
I would do it exactly the same way. As you noted here, symbol=* is already in use for "descriptions" of waymarkers. However, as noted there, I don't see a problem with homonymous use. Also arrow=* is still rarely in use for "turn" values. Supaplex030 (talk) 09:57, 2 June 2025 (UTC)
Sorry, I forgot about that. But perhaps indeed, personally and ideally, I would prefer using symbol=* here, and renaming osmc:symbol=* one to symbol:description=* . —— Kovposch (talk) 17:24, 3 June 2025 (UTC)
The mention of *:center=* should be avoided, as it should be discussed for renaming to British spelling *:centre=* —— Kovposch (talk) 08:33, 2 June 2025 (UTC)
True, we shouldn't "approve" non-BE terms. Not to mention that triple lane markings are an extremely rare case (I don't know of any). P.S. Found one on reddit, but as long as the lines aren't using different strokes, this can be mapped with stroke=tripple_solid (following the stroke=double_solid logic). P.P.S.: Uruguay seems to know the concept of tripple lines with solid lines on the edges and a dashed line in between. If it's a common road marking style, perhaps it has a name that could be used as a stroke value – local mappes need to decide in case of need. Supaplex030 (talk) 10:03, 2 June 2025 (UTC)
road_edge
These lines don't mark the edge of the road, but the edge of the carriageway. I'd suggest renaming to something like edge_line or carriageway_edge to avoid confusion. The actual road edge markers are reflector posts („Leitpfosten“ in German). Nadjita (talk) 16:54, 4 June 2025 (UTC)
Yes, they are called "edge of carriageway" officially in UK. But furthermore, the same is referred to on junction exits/diverges. Should that be considered a lane (when shallow taper/transition resembling a parallel diverging lane), edge-of-carriageway, or junction markings sepatately? File:Traffic-signs-manual-chapter-5-2004-figure-7x01.svg (diagrams 1009,1010) —— Kovposch (talk) 06:41, 5 June 2025 (UTC)
I think edge_line is a good choice. The lines 1009 and 1010 from the junction exits/diverges are an interesting kind of road marking - I would consider them to be edge lines, as they seem to mark exactly this (at least no lane divider, stop lines etc. and in my opinion it is not distinctive enough for an own value). Supaplex030 (talk) 20:05, 12 June 2025 (UTC)
IMHO it's not – as far as I know, it is also the common traffic term for this line (regardless of the associated sign/regulation). Supaplex030 (talk) 08:47, 20 June 2025 (UTC)
Hatchings
What to use for different crossed box junctions instead of pattern=crosshatch ?
Maybe just cross? Dunno if there is a need to document that, as there are certainly some patterns that are rather rare and that appear in TagInfo over time. Supaplex030 (talk) 10:31, 21 June 2025 (UTC)
Marked signs
Would adding traffic_sign=* directly to road_marking=traffic_sign be misinterpreted/ignored/misordered by applications, causing the confusion there is a plate sign on pole there? Also there's an opinion in some countries road markings are legally "traffic signs" there, so they are using traffic_sign=* as a road_marking:id=* instead. So that's why I thought road_marking:*=* prefix would be avoid conflicts with them. —— Kovposch (talk) 08:35, 21 June 2025 (UTC)
To avoid such ambiguities, I have always argued in favor of using highway=traffic_sign when capturing a sign as a physical object. Then it is clear: traffic_sign=* at a highway=traffic_sign node denotes a physical traffic sign, traffic_sign=* at a road_marking=traffic_sign denotes a road marking (depending on the local default also a ‘legal’ traffic sign) and traffic_sign=* at a highway line without one of the mentioned primary keys denotes the “meaning” of a traffic sign. Supaplex030 (talk) 10:39, 21 June 2025 (UTC)
"node" to 
"line". Supaplex030 (talk) 07:54, 19 April 2025 (UTC)
.jpg){kind=link}
.jpg){kind=link}
