Yes and no. Uncontrolled intersection are relatively rare in the U.S.; when they occur, we can tag junction=uncontrolled on the intersection node. It would be up to the data consumer (likely a traffic simulator) to infer an all-way yield, first to come, first to go. On the other hand, if an intersection has yield signs and/or markings, weād map highway=give_way at the waiting position indicated by those traffic control devices.
Technically, thereās also an uncontrolled intersection at the beginning of each service=driveway, such that only traffic coming from the driveway must yield as a practical matter, if not by law. We donāt generally map those waiting positions as highway=give_way.
May I ask about the lowered curb in this image you gave as an example in the proposal?
Is the requirement to yield merely perfunctory, or is the purpose to allow pedestrians to cross the street? Can you map a highway=crossingcrossing=unmarked at that location? A traffic simulator could assume that vehicles would yield to pedestrians crossing the street. This is the law in most U.S. states, in general, but as usual, the details are more complicated. Although high-risk crossings have signs to remind drivers of these laws, we typically only map highway=give_way when thereās an explicit marking or sign, which is more common in parking lots.
Thereās still an open question about how to handle signs that indicate where to yield for a pedestrian in the crosswalk. I map those as highway=give_way, but it does have the potential to throw off any router that tries to count blocks (which are more intuitive than fractions of a mile in urban environments).
In suburban America, most driveways go over a rolled curb or lowered curb cut, and this is routinely mapped as a barrier=kerbkerb=* node on the driveway. Sometimes this happens along residential streets too; we map a curb node similarly. As far as I know, kerb=* only refers to curb cuts to either side of the roadway when paired with highway=crossing.
maxspeed=* is not only for backwards compatibility. In the U.S., speed limit laws often vary from village to village, with most states only setting general laws in the absence of more specific local laws. The maintainer of the quasiāmachine readable āDefault speed limitsā wiki page has actively removed any attempt to account for local laws, so there is no viable alternative to mapping maxspeed=* on the relevant roadway, even when implied. If a mapper wants to cite a law as justification, they can use related_law=* for that.
And you donāt tag anything else?
Rhetorical question, just cause people canāt agree on stuff doesnāt mean itās impossible. Itās an unfortunate situation from your description, but at the end of the day, it just becomes tagging for the router. Which is sometimes ok, but I donāt think is necessary for the case of lowered kerbs.
Yes, I would also not use highway=give_way for these as it is generally the case that coming from a highway=service you have to give way to traffic that is driving on the street that you want to drive onto.
The picture is not perfect, I couldnāt find a better one. There is a street (with surface=paving_stones) coming from left in this picture. Vehicles driving on it towards the street with surface=asphalt are only driving across a kerb after crossing the sidewalk. This means that vehicles do not have to yield pedestrian traffic here. The purpose is to give vehicles on the asphalt street priority (which inside a 30 km/h speed limit zone in Germany is legally only possible this way because you are not allowed to use give way or priority road traffic signs there).
Yes, if the sidewalk was mapped separately, otherwise I probably wouldnāt do it as it is usual that people walking on the sidewalk are crossing roads at junctions. But the highway=crossing would need to be mapped separately from the highway=give_way.
In theory, yes, but when you look at the examples I linked above, many people also use them without highway=crossing.
I do not think this is sane mapping, e.g. here Node: 1423904509 | OpenStreetMap or in your other examples. Even more when there is no crossing infrastructure tagged, just ākerbā.
In cases like here: Node: 7040984425 | OpenStreetMap
it is easier to understand, as a crossing feature is present.
If the crossing way is drawn, I would expect the kerb to be at itās actual position, e.g. like this: Node: 12188197920 | OpenStreetMap
My proposal has two sides, and we are mainly discussing one of them:
The give_way:type subtag: It seems to me that many of you think that this is not needed as we already have tags to define the presence of road markings, kerbs and signs.
Clarifying the definition of highway=give_way: Nobody had anything to say about that.
So I am unsure how to proceed from here. One way would be to split this into two proposals. One to clarify and vote on the existing documentation of highway=give_way, including the definition that this is not mapping the traffic sign (as we have a different tag for that) but all situations where something is indicating to drivers that they have to give way to traffic from all directions at a junction. And a second proposal that discusses if and how different types of give_way infrastructure should be mapped with a new tag (if discussion continues to be one-sided, I might even not do this second proposal).
A mapper is free to tag related_law=* if they want, but the more important and practical information is the numeric maxspeed=*. Even in the parts of this country that are subject to civil law, speed limit signs are objective and explicit, whereas the scope of individual local laws can be subject to interpretation. This is true of a variety of traffic laws, by the way. A comprehensive system of implicit defaults is largely a pipe dream.
I would rather tag for a routing engine that exists than for a hypothetical insurance claim adjuster or traffic ticket estimator that can read these laws (probably based on AI technology ).
Anyways, I agree that the situation with speed limits isnāt analogous to the issue of lowered curbs. You either do or donāt yield before crossing one. Yielding for pedestrians would have a minuscule but highly variable effect on travel time estimates, so Iād imagine this information would be more interesting to traffic simulators such as A/B Street. Whereas information about the waiting location is of interest to detailed renderers, but only to the extent that thereās a traffic control device.
I think that generalisation is useful in principle, to cover situations which might not be obvious. To that end, there might be a place for give_way:type (or whatever) as a validation tag.
However, and thatās the main point for me, the tag highway=give_way should ideally not be used at all, instead using the remaining information (principally the kerb in my case) to infer that situation. This is particularly difficult with traffic signs, so itās a useful abstraction there.
Itās just incorrect to say that itās impossible to tag these situations correctly without such new tag. And in some cases (like with lowered kerbs), there is even a reasonable way to do it that improves the map generally.
This is factually inaccurate (or at least canāt happen in Germany?), though it got me thinking about Abknickende Vorfahrt ā Wikipedia, where the priority road makes a turn. Simply tagging highway=give_way cannot say to whom we have to yield.
clarify that highway=give_way can apply not only to yield signs, but also to other physical forms of priority indication. ā
I understand your good intentions but I donāt share your āangleā of vision. Probably there are more than 200 traffic signs in every country (more or less).
Also there are also more than 10 different road markings per country (which most of them had also an specific code).
Today thereās no human readable tag for every existing traffic sign so, although you use the example of maxspeed, I would not encourage to tag from the specific to general because in OSM we used major tags as a containers.
In Spain we called āvertical traffic signsā to the signs and āhorizontal traffic signsā to road markings.
What is the most important fact (to develop an international scheme)?
-A traffic sign could be a give way?
or
-A give way item could be a traffic sign?
Give way, in a road marking or in a sign is a traffic sign in reality.
I understand there is no attractive position to remember that in present. But reality is persistent.
First of all, is a traffic _sign. And in each country thereās an id for it. It is not a big problem that software does not know traffic_sign:id=DE:xxx and traffic_sign:id=GB:xxx (or the scheme the community will deserve to this), is the same meaning, you will always have traffic_sign=give_way or highway=give_way for fix this problem. Codes are specific for each item.
There isnāt an established tag yet for the markings, but I pointed to some that are quietly in use. This would be a good opportunity to formalize them if thereās a need.
If I understand correctly, youād clarify that highway=give_way can be indicated by something other than a particular traffic sign. Iād agree, at least for the āYIELDā and āshark-toothā markings in various jurisdictions, and maybe even for āYield Here to Pedestriansā signs. The only other option for mapping these is traffic_sign=* and road_marking=*, which are less amenable to automated route planning because theyāre more about infrastructure than behavior.
And I donāt know about you, but I love it when the signs are designed to troll self-driving cars.
Question is whether this is true. The german example with lowered kerbs certainly does one thing: It shows that give-way-rules arenāt exclusive to traffic signs of any kind.
But are we mainly mapping rules or physic items in OSM ? (yes, relations, but this proposal does not cover that in that way). And mapping rules without mapping the physic item?
The predominant understanding of highway=give_way, highway=stop, and highway=traffic_signals is about the subset of rules that are indicated by physical objects. The question is whether the physical objects need to be traffic control devices designed solely for that purpose, or whether we can also use these tags for when the rules are implied by some other kind of feature.
Thatās part of the issue, isnāt it? We generally map physical items (and I certainly favor that), though there are situations (like with traffic signs) where that isnāt enough to be useful. Either, because there is a lack of established tagging for the feature or combining the different objects and tags proves too computationally difficult.
Then weād need a way to avoid the trap where abstractions get tagged, but the physical objects donāt. That would probably be a good use case for give_way:type, so it becomes easier to find the places needing improvement.
Iām agree with you. It is so difficult to make some agreement that make happy all people when we have three or four schemes or three or four ways of mapping an item.
But Iām talking about the proposal. Iām imaging a kerb=lowered, so how we tag that in your example:
-Add give way tag
-Add your tag, soā¦
kerb=lowered
highway=give_way
give_way:type=lowered_kerb
correct?
Yes, this is the important thing:
Are we sure we are not capable of mapping the traffic control devices itself but we would be able to map everything that is not a traffic device but has some kind of relation with it?
I donāt oppose me to add extra info to the give_way tag, but I think first we have to map the main traffic devices because a give_way or yield is a traffic_sign mainly rather than an action (the action of give way if you are crossing a sidewalk with your car).
I am very much in favour of stating the kind of type explicitly.
Since the node represents the give_way point on the road, there is no need to repeat the give_way part. Itās a give_way node, so the taged attributes pertain to the give_way node.
The direction tag does not need to be prefixed with give_way: ; neither do other tags.
A simple sign=stop|yield could be enough to express the effect of the local signage.
Iām not OP, sorry for the confusion.
In the case of kerbs, I donāt think that my condition is met, as there is standard tagging for it (barrier=kerb as a line) and itās easy enough to figure out whether the way is crossing such line.
Thanks for the clear example. Is this give-way restriction distinct from what a vehicle would need to do anyways before crossing (what appears to be) a crossing:continuous=yes crossing? If I recall correctly, one of the reasons for this tag was precisely in order to communicate that vehicles need to yield before crossing or turning into a sidepath that has a continuous crossing with a side street.
Even if the sidepath isnāt mapped as a separate way yet, itās still possible to map a continuous crossing as a node. In most places Iāve mapped, most crossings were represented as nodes long before we started mapping separate sidewalk and crosswalk ways. The crossing nodes were very close to the highway=stop and highway=give_way nodes, but we didnāt combine them.
AI technology 
