Talk:Key:road marking
Potential data uses
Question: What is the potential use of this data? Obviously you could render it but without streets being mapped as areas, the rendering is likely to look rather odd. It seems like it would be more useful to put the effort of mapping these things into mapping their meaning in the form of lanes tags and turn restriction relations. These are tags that are already being used by OSM based tools to improve routing. --ToeBee (talk)
- This is not reserved for highway markings. I think about bus stops for instance. Such tag can be used by road maintenance services for instance. --Pieren (talk) 15:39, 22 August 2014 (UTC)
- I don't think it would look odd. Given road type, width and number of lanes you already can make street markings quite convincing. The only difficulty is that the road width would be rendered only at higher zoom levels --Vanuan (talk) 10:22, 24 September 2014 (UTC)
- I second the need for this information and would add that as autonomous vehicles (AV) become more common, the need for this data will only grow. Pedestrian crossings are particularly dangerous and sometimes road markings fade, rendering vision obsolete. A digitization of this information would help prevent lane incursion and late stops. --pflier (talk)
Integration with the road network
I’ve started using this tag to indicate the positions of stop lines along a road. Contrary to the guidance given on this page, I’ve tagged nodes along the road way with road_marking=solid_stop_line (or road_marking:forward=solid_stop_line or road_marking:lanes=* in the case of a staggered stop line). For stop line data to be most useful, it needs to be connected to the road way. As the road way itself is already an abstraction of the road surface, it would be better to tag stop lines on the road way itself. I think I’d only start mapping stop lines as separate ways once we start generally mapping roads as areas.
As for the other road markings, I haven't felt a strong need to use other tags like road_marking=solid_lane_divider, because so far that's already adequately expressed by tags such as change:lanes=* and overtaking=*. Such tags are more readily consumed by data consumers such as routers.
– Minh Nguyễn (talk, contribs) 04:41, 19 September 2018 (UTC)
- See also highway=stop and traffic sign=stop. OSM can both represent the physical markings and the logistic realities they represent; one does not have to replace the other. Arlo James Barnes (talk) 23:56, 16 December 2018 (UTC)
A bit too detailed?
Personally I think this is a bit too detailed for OSM and the likely hood of software using the data is low.
Mapping individual markings on a road is pointless as they are likely to change and can be determined from the roads tags, size & spacing can be assumes from regional rules. However, bigger things such as road_marking=pedastrian_crossing_rectangle make sense as they are fairly large and unlikely to change, there is also no current way to tell how they should look (it can not easily be assumed).
Rather than road_marking=gore_chevron couldn't we have a way to mark the whole gore marking as an area? Maybe as road_marking=gore
Having this work well together with area:highway=* needs to be a consideration. GoodClover (talk) 12:39, 13 December 2020 (UTC)
- +1, this tag probably needs more discussion before arbitrarily added into the map without concensus made from local community. -- CBRS (talk) 23:59, 30 December 2020 (UTC)
`
Page is completely unclear
Rather than explaining what road markings are, maybe it should focus how to use the tagging? Is this about a feature or a property or both? --Dieterdreist (talk) 12:20, 21 April 2022 (UTC)
Nodes?
There seems to be significant usage on nodes, but it is defined only for linear ways? What about polygons? --Dieterdreist (talk) 12:20, 21 April 2022 (UTC)
Highway Shields
In https://www.openstreetmap.org/changeset/131221054 I have boldly created six items which I give the value "shields". In the editor you can see them, giant blue etc., on the pavement. I used the highway number they show as their ref. Jidanni (talk) 09:45, 13 January 2023 (UTC)
Stroke details
The documented "experimental" values of this key cram details about both the line and its semantic meaning into the same value, such as road_marking=solid_lane_divider indicating that a (single) solid line is being used as a lane divider (as opposed to an edge line, centerline, etc.). I think this is a recipe for increasingly complex values that will be even more challenging for renderers to consume. There's even a popular but undocumented road_marking=yellow_divider value, which crams a color into the value for good measure.
I'm experimenting with more structured values, such as road_marking=lane_divider road_marking:stroke=solid instead of road_marking=solid_lane_divider. I found it necessary to depart from the commonly used values because this road has a double solid line divider separating the travel lane from the bike lane on either side of the road, emphasizing that bikes may not cross into the travel lane. Around driveways, it becomes a double dashed line. road_marking=double_solid_lane_divider and double_dashed_lane_divider would've started to become unwieldy. Other standard line patterns can go in road_marking:stroke=* or its subkeys, such as the distinction between a long dashed line for through lane dividers and a short dashed line for turn lane dividers.
I'm also using road_marking=centerline to indicate the road's centerline, shunting details about the line pattern and color to road_marking:stroke=double_solid and colour=yellow, respectively. After all, a double yellow line in the U.S. means more or less the same thing as a single solid white line in much of Europe. It's much more straightforward for renderers to use the simpler road_marking:stroke=* and colour=* keys to draw a marking regardless of its meaning, while other data consumers can focus on the meaning regardless of the presentational details. Moreover, a centerline in the U.S. may be a double dashed line or a dashed-solid line combination, depending on whether vehicles can overtake on one side or the other (overtaking=*).
– Minh Nguyễn 💬 21:32, 8 April 2023 (UTC)
- For this I suggest not to use *=double_solid due to the one-side solid lines. It is then unclear how to handle them. turn=* is shown by road_marking=left;through;right , so this can be exploited with *=solid;solid .
For me it's the opposite. As road_marking=left;through;right (and road_marking=dash , though the practicality of this being low) are using the symbol, I would use eg road_marking=solid_line + change=no to follow traffic_sign=* id + meaning attributes. I see there are already 1k road_marking=GB:* . Unlike traffic_sign=* , road_marking=* are more easily described.
The advantage of this is it can be generalized to any unprescribed usage of the pattern easily. In Japan, there is a wide variety of non-legislated speed control markings. There is now a further test to use them in yellow to show yellow solid line ahead simultaneously. https://trafficnews.jp/photo/103811#photo7
It may be difficult to classify whether some of these are longitudinal or transverse. http://sohotora2009.blog72.fc2.com/blog-entry-373.html
While the parallelograms / broken sharrows are marked along other longitudinal lines, they do not mean the edge, lane, or central line themselves. They can even be used in parallel or converging when there are no lane markings per se. - So using the pattern in road_marking=* would allow all these to be represented generically and visually, without worrying about their meaning, which there can be multiple too. The meanings can be relegated to the standard attribute tags, and this can be referred to on the highway=* road line.
However, I will acknowledge two shortcomings that can be illustrated by Japan at the same time. https://car-me.jp/articles/19242/photo?p=2- Broken turn arrows are used on dashed lane line sections on the approach upstream, to show the turning movement ahead. Solid turn arrows are used on solid lane line sections on near-side before the intersection, to discourage changing.
- Disjoint turn arrows are used when auxiliary lane will appear downstream. The internationally standard joined arrows are used for shared movement lanes only. One may incorrectly expect one set of arrows in one lane, if the solution is separate points.
- Anyway, my intention is to be the uniform with cycleway:*:marking=* from Proposed_features/separation#Symbolic_separation:_marking . Otherwise, it needs to be explained whether edge or lane line should be used for bike lanes, and the recently discussed pedestrian lanes. Parking lines is another issue. Using the line style in road_marking=* removes any question concerning the meaning, allowing it to focus on the markings.
--- Kovposch (talk) 13:29, 10 April 2023 (UTC) - Another thing I'm reminded of is edge of carriageway markings at junctions. Although you could use *=dash (instead of the *=solid at hard shoulder and hard strips; however other countries eg Ireland use dash for this as well), there's significant difference with the edge of carriageway in between.
This gets complicated in roundabouts, where they can have an additional give-way meaning. But is not a standard give-way marking per se, unlike UK double short dashed lines, or US's extra shark teeths. On UK Zebra Crossing, the transverse (?) dashed line mean both crosswalk border to pedestrians, and give-way line to vehicles. So all these have multiple meanings.
--- Kovposch (talk) 09:27, 12 April 2023 (UTC)
@Kovposch: The function needs to be part of the tagging too. Otherwise we can't reliably associate an arbitrary line with a particular attribute on the navigable way (and I hope we don't have to use relations for this purpose). In fact, the main reason I've been mapping road markings at all is that mapping highway=traffic_signals and highway=stop at the stop bar is highly imprecise when each lane has a stop bar in a different place; I'm using the road markings to indicate where the stop bars really are.
I agree that a given line style can have many different meanings, even within the same jurisdiction. That's why I'm intent on separating the function from the style. It doesn't matter very much to me whether the function or the style gets top billing, as long as they're separate. But while we're at it, we might as well separate the color and dash pattern from the style too.
– Minh Nguyễn 💬 06:17, 1 May 2023 (UTC)