This proposal aims to eliminate inconsistencies in documentation of the highway=give_way tag and add subtag to specify which infrastructure (sign, marking, lowered kerb etc.) is used to communicate the requirement to yield to drivers.
https://wiki.openstreetmap.org/wiki/Proposal:Give_way:type
Please comment here or on the discussion page.
I like it. It would make it possible to consistently map the lowered kerb-type of give-way that is very common in my area.
Can this proposal be expanded to also eliminate related inconsistencies, like give_way:direction=* and traffic_sign:direction on highway=give_way that are sometimes used instead of the more common direction=*?
Can we find a more descriptive subkey than :type for the classification system that you propose? Otherwise, itâs bound to get diluted by multiple unrelated aspects that mappers personally consider to be âtypesâ of give-way regulations. Or even confusion with give_way=*, which apparently indicates whether the intersection is completely or partially controlled by yield signs, similar to stop=*.
The wiki page of highway=give_way clearly states that the direction= tag is to be used and as far as I know, this is also respected by the major editors. So I donât see a reason to add it to the proposal.
I thought about that but couldnât think of a better subkey. One thing that came to mind (ok, letâs be honest, ChatGPT suggested it) is :indication, but it would be very unusual (never used in an OSM key up to this point). I am open to suggestions.
indication isnât terrible. Normally when we talk about the values of turn:lanes=* and where we get them from, we talk about âturn lane indicationsâ. Off the top of my head, all I can think of besides that is:
device, as in traffic control device (which includes markings, signals, and maybe curb cuts?)force, one of the roles of an enforcement relation 
evidenceIf there isnât a better alternative than :type, it isnât the end of the world, but this seems like a recurring problem that would benefit from a solution finally.
I canât see it being much use for UK mappers. Road markings == traffic signs here. Weâve got traffic_sign=* for that.
A second motivation is the lack of a standardized way to tag situations governed by German traffic law, where vehicles must yield when crossing a (lowered) kerb. [âŠ] In these cases, the lowered kerb acts as a physical indicator that drivers must give wayâyet OpenStreetMap currently lacks a dedicated tag to reflect this.
Just want to point out that Tag:barrier=kerb - OpenStreetMap Wiki exists.
Even in the U.S., where it isnât the case that road markings are a type of traffic sign, I think weâve so far managed to avoid a single unified key that covers all the different manifestations of traffic control. The default assumption is that a controlled intersection has a sign, signal, and/or marking at each approach that needs to stop or yield â quite often both a sign and a marking. However, I routinely encounter intersections where thereâs only a stop sign but no marking. I tag this as highway=stop marked=no.
On private property or in parking lots, the reverse is often true. This configuration could be tagged highway=stop with either signed=no or unsigned=yes.
Naturally, the same variations can occur with yield signs: highway=give_way marked=no.
If we begin tagging marked=* and signed=* even for the âdefaultsâ, then we can satisfy the use cases envisioned by this proposal while skirting the issue of classifying give-way restrictions. Maybe barrier=kerb can address the one remaining value for the situations in Germany.
True, but it doesnât have a direction on the node. Howâs the router supposed to know which travel-direction needs to be penalized? Yes, we could add directions to the kerbsâŠ
In Germany, road markings are traffic signs as well. But a data consumer canât know that traffic_sign=UK:... is the same as traffic_sign=DE:.... So I think an international tagging is useful, also for UK mappers.
Apart from that, some mappers prefer to tag a traffic_sign at its physical location instead of a node in the highway. This tagging proposal would make it possible to have the information in both places.
I know. But I donât want to map a barrier but a give way situation. A router will not know that this barrier has this meaning in Germany. So I would need to use highway=give_way. But the wiki is not clear at the moment that I can use highway=give_way for lowered kerbs.
I also want to make explicit that there is no yield sign at that intersection. I believe a subtag is the best way for that situation.
I am not sure that I understand the traffic law in the US correctly. In Germany, you have to only give way to traffic coming from the right if not indicated otherwise. Is it different in the US?
I donât think it is a good solution to use four tags (signed=no, marked=no, barrier=kerb, kerb=lowered) instead of one (give_way:type=lowered_kerb). The subtag also makes ist clearer that the kerb is not at the sides of the carriageway but across and that it is used to create a give way situation.
It is also much harder to analyze data when you need to look at multiple tags instead of one.
Itâs not necessary to add all 4. Only kerb= is required. Others are free to be added as explicit negative when one needs to express some difference or confusion with the surrounding.
On the contrary, when there are both signage and markings, what give_way:type= should it be??? It simply doesnât work well. This can also be said as =indicated vs =implicit , cf implicit=yes / source:maxspeed=implicit .
*:type= is âestablishedâ well-known to be a bad idea. Even within maxspeed:type= , it has been expanded to include different laws, and =construction would still have signs contrary to =sign (should be âpermanentâ vs âtemporaryâ similar to PSR and TSR in rails). Looking at the tittle, I thought this will be about junctions vs crossings, or who has priority. When comparing, maxspeed:type= and your give_way:type= actually has a different meaning from other *:type= , and maxspeed:variable= has already been used instead of making maxspeed:type= =fixed vs =variable for historical or good reasons.
You have mentioned this in another post, but that instead suggest this should be eg give_way:markings= =yes vs =no to have =shark_teeths , =double_dashed_line , =dashed_line , etc Give_way road_marking, triangle, teeth?
That being said for Germany, traffic_sign=none has been discussed for unsignposted markings-only situations. I donât read German, so someone can update me on any further discussions. Fahrradinfrastruktur Tagging - RealitĂ€t und Fragen
Markings being a traffic sign is a legal technicality. Despite the Vienna Convention being being named as signs, markings are in another chapter similar to the titled signals. TSRGD regulates signals and other lights, but they wonât be said as signs. traffic_sign= has added factor of being established in OSM for id. As further said, they are country-dependent.
Notably, âstop signâ and âgive-way signâ are defined as the âupright signâ only. Interestingly, a matrix sign is defined as a âlight signalâ. The Traffic Signs Regulations and General Directions 2016
I donât think it is advisable to only add a kerb=lowered tag to a highway=give_way as it might be misinterpreted as kerbs being lowered at the sides of the carriageway, as described in the wiki documentation.
To avoid such confusions, I think it is important to use some kind of namespace.
This is explained in the proposal:
Multiple give_way:type=* values can be combined using semicolons if more than one indicator is present.
But I understand your reservations about the :type namespace. So your suggestion would be to tag it like this?
highway=give_way
give_way:signed=yes/no
give_way:markings=yes/no/shark_teeth/etc.
give_way:lowered_kerb=yes/no
The disadavantage I see that this is more complicated than my proposal and that the tag give_way:lowered_kerb would be probably useless everywhere outside of Germany.
But I agree that :type might be not explicit enough. What do you think about a tag like give_way:indication?
Why would kerb=lowered on the highway=give_way express the kerbing of the road? Also, is this position not the same as the barrier=kerb ?
Semicolon is troublesome, canât handle negatives, and doesnât allow variations. It should be avoided when there a limited number of aspects to express, unlike all the different sport= and cuisine= out there.
If you need a single option, maybe *indicator= . For what it is indicated by, not what it is indicating. Yet when give_way:markings= is considered, this is not necessary. Another crossing:*= =traffic_sign / =markings is unneeded when there are crossing:markings= , and crossing:signed= now. Proposal:crossing:signed - OpenStreetMap Wiki
Would propose to change the âpopularâ reference of shark teeth to âyield lineâ. Have mapped thousand of stop/giveway spots with road_markings=solid_stop_line and give_way. and when traffic signed also in addition source:stop/give_way=sign.
I donât understand the question. What I meant is that kerb=* as a node on a street usually describes the kerbs that separate the sidewalk from the carriageway. For example these nodes: 1, 2, 3. I donât think it is wise to also use the kerb=* tag to describe kerbs that go across the carriageway.
The barrier is the reason for the give way situation. We map whatâs on the ground, not the laws giving meaning to it. In the same fashion
They will know if implemented correctly, because they already have to take account of various country-specific rules.
kerbs mapped as a line do have a direction. In fact, that is used to determine which side is the higher one (except for flat kerbs, but thatâs not interesting here). So itâs already possible to determine which direction gets the penalty.
Mapping them as a node doesnât have that, thatâs true.
As a general statement, this is not true. See for example the maxspeed=* tag where we translate legislation into a tag instead of just adding a traffic_sign=* or leaving it up to the router to know how fast one is allowed to drive inside of city limits in Germany. Or see all of the access=* tags as another example.
The idea that routers have a huge database of country-specific rules is often stated here but I donât think it has much to do with reality.
Another thing I donât like about the barrier tag is that a lowered kerb is not a barrier for the vehicles driving on the carriageway.
What is the conclusion of your statement? highway=give_way should only be used for yield signs and other cases should be mapped with traffic_sign=*, road_markings=* or barrier=*?
maxspeed is rightfully controversial since it loses all nuance, so in recent times, the trend has been to add traffic_sign and zone:traffic, though maxspeed is still being tagged for backwards compatibility.
See e.g. graphhopper/core/src/main/resources/com/graphhopper/routing/util/legal_default_speeds.json at master · graphhopper/graphhopper · GitHub for the german speed limits. At the top, there are also rules to determine each type of street.
Thatâs at best a naming issue and not relevant to this discussion. The tag is established and its meaning is known.
Ultimately, yes. In some instances, abstraction can remain useful, but especially in the case of lowered kerbs, I think there is a more concrete way that better reflects the reality on the ground.