Proposal talk:Road marking revision

From OpenStreetMap Wiki
Jump to navigation Jump to search

Namespace

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)

As it turns out, symbol=* is used as a description=* for osmc:symbol=* . They will need to be road_marking:*=* .
—— Kovposch (talk) 20:31, 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.

—— Kovposch (talk) 19:44, 18 April 2025 (UTC)
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)

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)

I'm using road_marking:left=solid_line + road_marking:right=dashed_line , and then there are road_marking:both=solid_line or road_marking:both=dashed_line (which is one reason why I prefer having road_marking=* for the stroke)
—— Kovposch (talk) 19:28, 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)

Coordination and consistency with others

It's preferable for this to be aligned with marking:*=* (which can be changed to this ver here) Proposal:Separation#Symbolic_separation:_marking
—— Kovposch (talk) 19:32, 18 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)

Markings vs Surfacing

For your thinking, road_marking=colour isn't a functionality. File:Modřanská,_cyklostezka_u_Bohemky.jpg would be road_marking=junction / road_marking=crossing + colour=red . But what's the difference with area:highway=* + surface:colour=red ?
—— Kovposch (talk) 19:35, 18 April 2025 (UTC)

You are right, the value colour is not yet well thought out. I think it can be omitted in favor of road_marking=junction + colour=* and area:highway=* + colour=*.
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)

Restrictions vs Locations

Box junction isn't really road_marking=junction despite the naming . It's a stopping restriction, meaning it should be with your road_marking=restricted now.
If used, road_marking=junction should be reserved for actual junction controls similar to road_marking=crossing , eg highway=mini_roundabout .

road_marking=restricted mixing driving and stopping restrictions doesn't seem nice, while I understand both could be present. As I mention how I prefer if the attributes are followed, I would split it between road_marking=access for access=* , and road_marking=restriction (see below) / road_marking=parking:restriction / road_marking=parking for restriction=* / parking:restriction=* / parking=* .
—— Kovposch (talk) 19:49, 18 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)

Form vs Function

For the direction of using road_marking=* for functionality, Proposal:Road_marking_revision#Describing_point_markings is mostly forms. It doesn't fit.

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.
If somebody need this information, this could also be a case for road_marking=arrow + function=turn/oneway/restriction/overtaking...? Similarly with road_marking=text + function=access/hazard/destination.... (Is there a more appropriate term than function=*? meaning=*? intention=*?)
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 "node" to way "line". Supaplex030 (talk) 07:54, 19 April 2025 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Road_marking_revision&oldid=2839843"