Large scale change of traffic_sign to traffic_sign:id

[yopaseopor]

@Minh_Nguyen

When selecting an existing feature, they can visually confirm that the preset icon matches the sign in street-level imagery.

Yes, but after statistics and watching evolution like iD editor, etc. human readable values have to be able to coexist with technical national id’s that like to people like me. Because if not some information can be lost, or not mapped o similar. With the two approaches we give answer to the two audience (specialized and not specialized). OSM is for all.
We have to do in a coherent way. If hazard exist all the other categories have to exist too, and if they not exist…we should create them.

@Minh_Nguyen

I’d contend that it might take an expert to develop these presets but not to use them.

Probably I’m not the best to do that and I hope someone can do this better, or can help, or can collaborate but I will adapt all I can do to the agreement all we will have.

@Minh_Nguyen

traffic_sign=city_limit that don’t necessarily play a role in road traffic safety either.

Here in Spain city limit is traffic_sign:id=ES:S500 and traffic_sign:id=ES:S510. Of course is a traffic sign.

@Minh_Nguyen

Here’s a city limit sign along a bike trail in my hometown. It looks identical to the city limit signs they post along roads, but slightly smaller

Is it legal? Is it the same? Is it in the MUTCD of that zone? If it is…it is.

@Minh_Nguyen

Parking regulatory signs can be posted either streetside or at individual parking spaces in a parking lot:

I would ask the same before: Is it legal? Is it the same? Is it in the MUTCD of that zone? If it is…it is.

@Minh_Nguyen

This is a traffic sign in the sense that it appears in a traffic sign standard

I would ask the same before again.

@Minh_Nguyen

My city has a program that lets residents post yard signs out front encouraging drivers to slow down.

Do you think a personal and customized yard sign without any registry of any administration can called traffic sign?
Here in Spain we have some people in some town that painted in the walls “Please go slowly” but I don’t think this could be a traffic sign. Would be a positive message, good for your city but I don’t think this could be a traffic sign. Would the police put a fine relative to this yard sign, or to the law in general?

@Minh_Nguyen

Could an alternative tagging scheme be based on the newly documented man_made=sign tag?

For me, probably.

@Minh_Nguyen

whether or not you personally consider it to function as a traffic sign?

Because I’m no God. I don’t decide which is a traffic sign or not. Traffic laws decide this. I can’t invent a traffic sign. I can’t put a traffic sign in the street myself. Traffic signs are in laws with its codes. My proposal want to maintain the national code and the human readable value that it has. As traffic signs are similar all over the world we can establish some tagging for them.

traffic_sign=* exists before my proposal so this would not change. And it is so interesting the discussion about was better highway=stop or traffic_sign=stop or highway:id=ES:R2 or traffic_sign:id=ES:R2. But we are far away. We passed that. We have to decide if human readable values should coexist with national codes. hazard=* exist as a traffic_sign human readable values, so only we have to decide if we want to be coherent with other traffic_signs, if we want to establish the step before (traffic_sign=hazard), if we want to develop now other parts of the traffic laws like traffic_sign=mandatory (or similar) and prohibited and if we want to maintain national id’s. Then we have to decide how to map it and with which tags.

My proposal covers all of that.

@Minh_Nguyen

Similarly, if a country’s traffic sign standard numbers road markings, we can add traffic_sign=* to the road_marking=* node/way/area. That element isn’t connected to the roadway, so there’s no risk of a router misinterpreting it.

Good discussion. I think is better to solution one, and then another. I have some ideas for the discussion about that but let’s focus to be able to finish anything.

@Minh_Nguyen

for example, we combine kerb=* with barrier=kerb when tagging the location of a physical curb cut, but we omit barrier=kerb when tagging the kind of kerb associated with some other feature, such as a highway=crossing

The problem of this would be the misinterpretation depending of the country. Eg: The majority of crossings of Spain has traffic_sign:id=ES:S13 before, but the mere existence of a crossing does not put the traffic_sign:id=ES:13 before a crossing. Because you can find other traffic signs so it is not possible to infere 99% secure always which traffic_sign you will have next to/before/after a item. Think about crossing=unmarked in United Kingdom. For a Spaniard is very shocking this idea as here we have the majority as marked.

@Minh_Nguyen

but how many nuclear decontamination centers are there by comparison?

Probably Mapillary copied the MUTCD as is. Don’t care much about that.

@Minh_Nguyen

depending on your point of view, they also serve to warn about a unwelcoming neighborhood

No, depending my point of view if there are not inside MUTCD and are approved by the administration they are other thing that traffic signs. I will not enter about the information you have inside the sign.

@Minh_Nguyen

But local governments and organizations post them anyways under the authority of a local ordinance.

Good for the local authority. Which is the target of this traffic sign for the traffic? Which is the objective of this traffic sign for the traffic? Would the police fine you if you don’t do what this traffic sign say to you to do? If not, I don’t think would be a traffic sign, would be a sign, a plaque, but not a traffic_sign.

@Minh_Nguyen

And then a city ends up posting the national sign anyways, which is how my city wound up with two different shapes of one-way signs at the same intersection. oneway=disputed?

Ok, we can study which code applies, MUTCD or state authority or local authority with its code in traffic_sign:id=*

@Minh_Nguyen

If we can relegate the sign IDs to a secondary key called traffic_sign=*, then the exact scope and format of that key doesn’t matter as much.

traffic_sign:id=* would be for codes, traffic_sign=* and its subcategories for human readable values. Probably major part of mappers who does not know about traffic law would not use traffic_sign:id=* But I think there will be mappers like me that then we will be able to do it without losing the information when have to select human_readable value or national id because there is one only tag to map it.

[Minh_Nguyen (Minh Nguyễn)]

@yopaseopor

Is it legal? Is it the same? Is it in the MUTCD of that zone? If it is…it is.

Yes, yes, and yes. Even this sign that every city wants to install in its neighborhoods, to the consternation of state and federal agencies that would never consider codifying it:

Slow Children At Play

@yopaseopor

Do you think a personal and customized yard sign without any registry of any administration can called traffic sign?
Here in Spain we have some people in some town that painted in the walls “Please go slowly” but I don’t think this could be a traffic sign. Would be a positive message, good for your city but I don’t think this could be a traffic sign. Would the police put a fine relative to this yard sign, or to the law in general?

If you look closely, it has the logos of the city and the state Office of Traffic Safety. The government hands these signs out to residents who want to install it themselves. It functions like a traffic sign in the same manner that a construction warning sign might, and I tagged maxspeed:advisory=20 mph based on it, but its composition is no different than that of a political campaign sign, and no one would call it a traffic sign. It’s a yard sign.

But you’re right, these complexities existed before your proposal and will exist after your proposal too. Regardless of what your proposal says, ordinary non-experts will map miscellaneous traffic signs they come across, even if they don’t know how it fits into a regulatory standard.

[yopaseopor]

@Minh_Nguyen

A good starting point would be to read through these two issues that have ended in a kind of stalemate between the name-suggestion-index and id-tagging-schema projects. It seems like we need to combine the strengths of both projects without bringing along the baggage. You can also get a sense for who else is interesting in helping out with a solution.

Probably after the proposal would get approved (or an agreement about traffic_signs and its mapping) we can start to develope and help to other projects that need some structure. I have read that nowadays tagging could be a problem to make some correspondence table because the composition between codes and texts inside the value. We can “fix” that.

@Minh_Nguyen

Yes, yes, and yes. Even this sign that every city wants to install in its neighborhoods, to the consternation of state and federal agencies that would never consider codifying it:

Sorry, but in the wikipedia article you mention it is explicited that some administrations are arguing that is not a traffic sign. But ok, what code is it? How can I map with traffic_sign:id ? What is the equivalent in other places?
Here, in Europe probably the privates would end with a big fine. (in Spanish)

Así funciona el radar simulado colocado por un vecino de San Sebastián y la...

@Minh_Nguyen

It functions like a traffic sign

No, I’m not agree with you ,any driver can pass about this sign. As advertisement would be good, but is it a traffic sign or not? Not like a, is it or not? If not , there’s no tagging about that. You can map the law that order in that street, the message of the sign but not the technicality of that ad. Would you map in the same way Smoke kills ad?

@Minh_Nguyen

It’s a yard sign.

Correct, it is a yard sign and I think it would be mapped as is, not like would be. Would your local administration can use OSM as inventory if we start to map yard ads as a traffic signs?

Well, we can start to re-edit the proposal to start to add the new text and the new codes.
Here it is. Guide me, and discuss it, please.
https://wiki.openstreetmap.org/wiki/Proposal:Extended_traffic_signs_tagging

[Minh_Nguyen (Minh Nguyễn)]

@yopaseopor

@Minh_Nguyen

A good starting point would be to read through these two issues that have ended in a kind of stalemate between the name-suggestion-index and id-tagging-schema projects. It seems like we need to combine the strengths of both projects without bringing along the baggage. You can also get a sense for who else is interesting in helping out with a solution.

Probably after the proposal would get approved (or an agreement about traffic_signs and its mapping) we can start to develope and help to other projects that need some structure. I have read that nowadays tagging could be a problem to make some correspondence table because the composition between codes and texts inside the value. We can “fix” that.

The impasse between these two projects has little to do with tagging. I don’t think anyone involved in those discussions favors the complicated syntax with the brackets either. Rather, the difficulty seems to be around logistical issues, because traffic signs don’t neatly fit the kinds of tagging that either project is used to. id-tagging-schema is better set up for localization (important in multilingual countries like Belgium and Switzerland) and can specify which empty fields to present the user along with each sign (for example, the Speed Limit maxspeed field for a speed limit sign). On the other hand, name-suggestion-index would be more capable of handling an influx of thousands of new entries, and it can fetch icons dynamically.

@yopaseopor

Sorry, but in the wikipedia article you mention it is explicited that some administrations are arguing that is not a traffic sign. But ok, what code is it? How can I map with traffic_sign:id ? What is the equivalent in other places?
Here, in Europe probably the privates would end with a big fine. (in Spanish)

OK, I didn’t want to go into this rabbit hole, but since you asked: the U.S. is big and complicated. Traffic signs are standardized at the federal, state, and local level. The state regulations are supposed to conform “substantially” to the federal standard, and local ordinances are supposed to follow the state regulations. State laws generally prohibit non-MUTCD-compliant signs from being posted by anyone, but often the state and local governments are the ones who post non-compliant signs. Some states like California and Oklahoma are notorious for nonstandard, even childish signs:

File:US 69 Craig Co.jpg

The federal government’s role is mainly to coordinate the state regulations, sort of like how the OSMF “supports but does not control” OSM. To the extent that state and local funds are used to maintain a highway, the Federal Highway Administration is responsible for enforcing conformance, by threatening to withhold that funding. Otherwise, on a local street maintained with local dollars, the federal government only has the right to send sternly worded letters of disapproval. This is how a town in Indiana gets away with posting its street name signs in German, and in colors that the MUTCD explicitly prohibits:

But even a more conventional traffic sign can lack a standard MUTCD number. For example, here’s a regulatory sign at the Louisiana state border that has no equivalent in the national MUTCD. Louisiana hasn’t adopted a state supplement to the MUTCD, so there’s no state sign number either. This sign still has the force of law, because it follows the general design rules for a regulatory sign. This is exactly the kind of situation that I think would benefit from a set of tags like traffic_sign=regulatory.

As for the “Slow Children at Play” sign, the federal and state governments don’t claim that this isn’t a traffic sign, and they certainly don’t prohibit us from calling it one. (That would be a violation of freedom of speech.) Rather, they say that there’s no valid location along a roadway to post such a sign. Yet cities routinely post these signs (and the neighborhood watch signs) on city streets, intending for them to serve as traffic signs. A police officer may issue you a ticket for violating the sign, but you might be able to argue your way out of the fine. If you get into an accident because of the sign, you might have grounds to sue the city. But not because it isn’t a traffic sign.

OSM maps the world as it is, not as it should be. This means we should have some way to map an uncodified or nonstandard traffic sign. Every now and then, someone in OSMUS Slack asks how to tag a miscellaneous sign. My informal advice is to tag the sign category, such as traffic_sign=regulatory, and provide more details in other keys such as maxweight=* or even maxwheels=*. Then, for good measure, also tag the text on the sign as name=* or inscription=*. People have been following this advice.

I think this approach mostly aligns with your proposal. The aspect we disagree on is whether all the usual signs should also have structured, human-readable tagging. Honestly, I’m still not sure why we’re going through all this trouble to create a new ontology just to accommodate power mappers who don’t want to use presets. Maybe you’ve explained this already, but I didn’t understand?

@yopaseopor

Correct, it is a yard sign and I think it would be mapped as is, not like would be. Would your local administration can use OSM as inventory if we start to map yard ads as a traffic signs?

We agree on this point. What I meant is that some navigation-related tags such as maxspeed:advisory=* can sometimes be tagged based on things other than traffic signs. Granted, yard signs are an unusual example of this, but just think of all the non-government-provided signs that prohibit access to private property:

File:Penlec Substation Danger and Notice signs.jpg

@yopaseopor

Well, we can start to re-edit the proposal to start to add the new text and the new codes.
Here it is. Guide me, and discuss it, please.
Proposal:Extended traffic signs tagging - OpenStreetMap Wiki

I really think you should start new forum discussions with each national community you hope to bring on board with this proposal. Of the very limited set of entries you included in your revamped proposal, I made a couple dozen changes, some of them very significant. The existing signs looked like guesses; you would’ve avoided a lot of confusion by consulting the MUTCD correspondence tables that I keep mentioning. If you got these signs from pages in the Key: or Tag: namespace, then I’m sorry that other non-Americans keep making poor guesses at what our signs mean.

I blanked out some of the table cells in the MUTCD column, because there’s no national sign, only some state specific signs; in other cells, I added as many as 14 more sign numbers that involve the same tag. Some of them are used in different contexts, but I assume you don’t expect U.S. mappers to ignore the sometimes significant differences between these signs just because the corresponding Spanish signs are more uniform or less precise.

Maybe you consider this initial set of signs to be a logical first step, but from my American perspective, it’s a very haphazard set of signs. I don’t know how you’d hope to get this proposal into shape without systematically going line by line through the relevant sign standards or the documentation that mappers in various countries have helpfully put together for you. Again, we could end this difficulty just by tagging the sign ID whenever it’s available.

[yopaseopor]

@Minh_Nguyen

because traffic signs don’t neatly fit the kinds of tagging that either project is used to

I don’t know why I can map any tree of the World and I can’t map a traffic sign (an artificial thing, registred, countered, based on law) of the world.

@Minh_Nguyen

I think this approach mostly aligns with your proposal

Yes, tell me what can add. As you can see there are several categories:

traffic_sign=hazard
highway=Stop and give_way
traffic_sign=max* ,min or advisory
traffic_sign=implicit
traffic_sign=access
traffic_signs=restriction
traffic_signs=mandatory
traffic_signs=information
traffic_signs=lanes
traffic_signs=services
traffic_signs=complimentary
traffic_signs=ref_id
traffic_signs=boundary

traffic_signs=regulatory

What more?

@Minh_Nguyen

The aspect we disagree on is whether all the usual signs should also have structured

Probably I had not explained me well on this.
This proposal is about the way of mapping a traffic sign nor specific examples (the idea is to give examples to show the people how to do that, but as a massive thing the documentation will grow a lot, each community specifying which values uses and what codes have.
As exists hazards and other human readable values , in a future you will have all it around, because each value or category can be the target of a proposal of this kind of values.

At first in OSM there is human readable values attached to traffic signs (city_limit, maxspeed). This proposal only wants to complete the scheme. If you want a top category you will have traffic_sign=* and its category. Then , from the category, as hazard or maxspeed you can derivate all the scheme you will need for your mapping. US is variate, but also Europe too, you can have 300 official signs but with variations approved and installed in our rouds, you can have near 700 (Spain’s case). Codes derived this kind of traffic signs, is for this that are important here in Europe, if you want to be as accurate as you want to be. Some people will not map it, some people will map only stop and give=way, some people will map only OSM well-known values, and some others will use the national code, accompanied of a human readable value as a completed micromapped item.

@Minh_Nguyen

What I meant is that some navigation-related tags such as maxspeed:advisory=* can sometimes be tagged based on things other than traffic signs.

Totally, no discussion about that. But them we will accept controversy cases when informal traffic sign says the opposite to official…but then these will be the problem of the mapper.

@Minh_Nguyen

I really think you should start new forum discussions with each national community you hope to bring on board with this proposal.

It has no sense to discuss about all the bunch of human readable values if I cannot map the signs with direction,position, side, human readable values and national id if I want to. When we have that, then we can discuss with each community how to make this mapping. And also we can front what human readables values are missing in OSM, now hazard exist. I’m not from US, probably you will know better what US roads need. I read a lot of traffic laws, etc, but my presets are about national codes you will find in laws and a way of mapping that because I don’t have the local knowledge that it has the local community. Probably from each country , the community knows better what traffic sign do they need in a preset. I can help, I can adapt, but I’m only be able to do an analytic proposal.

@Minh_Nguyen

Of the very limited set of entries you included in your revamped proposal, I made a couple dozen changes

I accept your changes but be conscient they were only few examples how to tag it. There was a general example, the categories, and then what human readables values looks like, and how to map national id’s together. I can do a complete list of that…but it has no sense if I cannot map the basics of any item in this case: direction, position, side, national code and human readable value.

@Minh_Nguyen

Again, we could end this difficulty just by tagging the sign ID whenever it’s available.

Yes, but when you have human readable value and national code too, what do you map? How to map it together without removing any information? This is the aim of traffic_sign:id=, to let traffic_sign= the human readable value, as the first traffic signs stop and give way does. And this is the topic of this proposal. Also we have to discuss how to tag the position or the direction. Better layer of subkey? Better 0 or forward? In the past I’m only used what others used before. Now I’m asking if that is not sufficient what more do we need, and to established via a proposal, to avoid any missunderstanding with mechanical , automatic or manual mapping because I can use these keys.

Also all this discussion focus in the need of collaboration of biggest “structures” of OSM. iD Editor (via nsi or tagging preset o scheme or whatever) is an “OSM national-structure”.

If we not approve this proposal, then in the future we will have some others that can do. Traffic sign is a big topic inside OSM (more than 2 million worldwide) and some day we will need to think about it. Let’s do now and save time and efforts. Focus the discussion for the structure (because it is clear in OSM quasi-all is mappable, and anything can stop that), how to do that, and then we will talk about the rest.

@Minh_Nguyen

mappers in various countries have helpfully put together for you

Thank you.

[osmuser63783]

So you are planning to take this proposal forward?

I read your proposal and thought you were trying to formalise a whole bunch of human-readable values.

If your proposal is just about the basics, e.g. how to tag position, direction and id, then you can reduce the proposal in length by about 80%…

It would be good if you could make it clear what you are actually proposing: which new tags you are introducing, which existing “in use”/“de facto” tags you are formalising, and which tags, if any, you are deprecating.

[Minh_Nguyen (Minh Nguyễn)]

@yopaseopor

Yes, tell me what can add. As you can see there are several categories:

traffic_sign=hazard
highway=Stop and give_way
traffic_sign=max* ,min or advisory
traffic_sign=implicit
traffic_sign=access
traffic_signs=restriction
traffic_signs=mandatory
traffic_signs=information
traffic_signs=lanes
traffic_signs=services
traffic_signs=complimentary
traffic_signs=ref_id
traffic_signs=boundary

traffic_signs=regulatory

What more?

This list consists of very general values like regulatory and information mixed together with very specific values like lanes and give_way that only pertain to a limited number of signs. In my opinion, this set of values doesn’t seem to be any more consistent or rational than the current mix of sign codes and keywords. For reference, I put together a list of general sign categories in some major sign systems. Feel free to add more standards to it. Obviously it isn’t possible to align 100% to each of the standards, but you can see some common themes among them – much more commonality than at the level of individual signs.

@yopaseopor

At first in OSM there is human readable values attached to traffic signs (city_limit, maxspeed). This proposal only wants to complete the scheme. If you want a top category you will have traffic_sign=* and its category. Then , from the category, as hazard or maxspeed you can derivate all the scheme you will need for your mapping. US is variate, but also Europe too, you can have 300 official signs but with variations approved and installed in our rouds, you can have near 700 (Spain’s case). Codes derived this kind of traffic signs, is for this that are important here in Europe, if you want to be as accurate as you want to be. Some people will not map it, some people will map only stop and give=way, some people will map only OSM well-known values, and some others will use the national code, accompanied of a human readable value as a completed micromapped item.

I see, thanks for explaining your expectations in more detail. I’m not in favor of the existing ad hoc values like traffic_sign=maxspeed. These values are only popular because the documentation and editors historically haven’t done enough to support mappers entering more specific values, based on the more specific signs they can see with their own eyes.

If so far no one has put together presets or a wiki page about your country’s traffic signs, but a mapper wants to tag a speed limit sign, traffic_sign=maxspeed is better than nothing. It’s the same story if they encounter a sign that hasn’t been standardized yet – any tag you like. By contrast, if they’ve already chosen a specific sign code visually using a preset, then they shouldn’t need to additionally provide the sign’s category.

Assuming that a given sign code belongs to a single category every time it occurs, traffic_sign=* can be either a specific sign code or a general sign category, following the approach we approved in 2020. These keywords more or less already exist today, but we can come up with a shortlist for consistency if you prefer. Aside from that, there’s nothing really to fix here, other than to build out the tools for mappers to migrate from the ad hoc values to more specific values. If the indexed :2 syntax would unblock these tools, I suggest making the proposal about that change and setting aside the extended keywords.

@yopaseopor

traffic_signs=complimentary

(By the way, you probably mean complementary; complimentary would be for a “Thank you!” sign. The text of the Vienna Convention calls them “additional panels”, while British English calls them “supplementary plates”.)

@yopaseopor

I accept your changes but be conscient they were only few examples how to tag it. There was a general example, the categories, and then what human readables values looks like, and how to map national id’s together. I can do a complete list of that…but it has no sense if I cannot map the basics of any item in this case: direction, position, side, national code and human readable value.

OK, if I misunderstood the purpose of including sign images and codes in this proposal, then please feel free to revert my changes.

In fairness to you, many key and tag description pages present an oversimplified gallery of signs by country. To me, this practice is rather backwards: it’s not as though anyone window-shops for traffic signs based on a tag they’ve chosen upfront. Often, when you see a gallery of signs in an “Examples” section of a tag description page, it means “This sign proves the need for a tag,” not “If you see this sign, use this tag.” This is especially true of any tag that went through the formal proposal process, such as hazard=children (which confused signs about playgrounds with signs about children playing in the street). Over time, as mappers in more countries put together country-specific tagging pages, we might be able to deemphasize these galleries.

Going through the table you set up, I saw a few reasons why it would be complicated to cleanly map a single human-readable keyword to sign codes across countries:

• Many tagging schemes rely on more than one tag in combination. For example, most countries have signs that we’d tag as hazard=animal_crossing. But animals come in all shapes and sizes, so usually there’s a whole series of signs with cute and cuddly animal pictograms, requiring an additional hazard:animal=* or hazard:species=* tag. The only kind of sign that literally just means hazard=animal_crossing is something like , but most countries don’t have a general sign like that.

• The meaning of a sign can change significantly due to a complementary plate beneath it. For example, means “bicycle crossing” by default. It only means “bicycles riding in the street” (hazard=cyclist) with an additional plaque. But the main sign’s number is the same in both cases. Similarly, Vienna Convention countries use signs for many different situations that we’d tag as hazard=*. By the way, this issue probably complicates your desire for :2 and :3.

• Two signs can have exactly the same function but look very different to a mapper or computer vision algorithm. There is no functional difference whatsoever between Puerto Rico’s and signs. But not every country has two different signs for oneway=yes.

• A single sign can contain multiple pieces of information. Destination signs are some of the most extreme combinations, but combinations like are very common too.

These considerations don’t matter very much when mapping the effect of a traffic sign, for example, hazard=* or highway=stop. I think most mappers would agree that mapping the effect is more important than mapping the traffic sign itself, but mapping the traffic sign isn’t completely useless either. My concern is that requiring every traffic sign node to be dual-tagged with its effect will cause mappers to view one or the other as redundant or superfluous. If you want to dual-tag a single node with an effect and the sign that indicates it in the same location, OK, but don’t make that a requirement.

[IanH]

@yopaseopor

traffic_sign=hazard
highway=Stop and give_way
traffic_sign=max* ,min or advisory
traffic_sign=implicit
traffic_sign=access
traffic_signs=restriction
traffic_signs=mandatory
traffic_signs=information
traffic_signs=lanes
traffic_signs=services
traffic_signs=complimentary
traffic_signs=ref_id
traffic_signs=boundary

traffic_signs=regulatory

I think this a good start this is a lot signs to work on at once. Can take a type or two a work out common themes first? Leading to a consistent way to describe a sign. That way we will have a basic framework that can be applied to other categories.

[yopaseopor]

@osmuser63783

So you are planning to take this proposal forward?

My planning is to be able to map a sign as is, and that every mapper, driver or not can do that, as other people can do that with other elements like street lamps, trees or containers. Before it was an item not important for OSM (no proposals, inconsistent tagging, ignored topic… you think I can be rude but you can read tagging list and see the history of it in OSM.) so anyone can map the basics.

Now it is not as that. Now in OSM now we have big companies, and some users that want to map it .Some communities tried first. But there we are in 2023 without a way to map these common items, with a wiki saying there’s three ways of do it, and with some “de facto” approved or proposed accepted that does not fit the item itself as we can see at the discussion with hazard.

@osmuser63783

If your proposal is just about the basics, e.g. how to tag position, direction and id, then you can reduce the proposal in length by about 80%…

My experience says (could be wrong or not) that not all the proposals are threatened in the same way (again you can see the history of tagging list or import list (I remember some painful -yes- episodes). Stop and give way are one of the oldest, with different tagging, how to change that. Ok. Let’s do in the best way, with all the examples you need to understand what is the aim. Why I have to be condemned to map between brackets? Why I have to use multivalues that has no sense (for me a complementary sign…is a sign too, for others it is residual, let’s take the meaning only). For this reason I would make whatever list I have to demonstrate that I don’t have seven years old and others can arrive here, change one tag or the way to map milion of items that they want to and go on. - it is not the first time and from other mappers - (let’s see first comment of this thread as an example.)

@osmuser63783

which new tags you are introducing, which existing “in use”/“de facto” tags you are formalising, and which tags, if any, you are deprecating.

Ok, would be interesting.

[IanH]

@osmuser63783

If your proposal is just about the basics, e.g. how to tag position, direction and id, then you can reduce the proposal in length by about 80%

I like the idea the of breaking the proposal into smaller chunks. Starting with more straight forwad foundational concepts. Perhaps including more defacto tags because they are already in use.

[Minh_Nguyen (Minh Nguyễn)]

@yopaseopor

@osmuser63783

So you are planning to take this proposal forward?

My planning is to be able to map a sign as is, and that every mapper, driver or not can do that, as other people can do that with other elements like street lamps, trees or containers. Before it was an item not important for OSM (no proposals, inconsistent tagging, ignored topic… you think I can be rude but you can read tagging list and see the history of it in OSM.) so anyone can map the basics.

Now it is not as that. Now in OSM now we have big companies, and some users that want to map it .Some communities tried first. But there we are in 2023 without a way to map these common items, with a wiki saying there’s three ways of do it, and with some “de facto” approved or proposed accepted that does not fit the item itself as we can see at the discussion with hazard.

I think this is a fair question that deserves a straightforward response. Otherwise, we’re wasting our time (myself particularly) trying to massage the proposal into something that the global community could get on board with. Given your stated desire for consistency, the focus would naturally shift from your proposal back to the question of what to do with your widespread edits, which are in the minority.

[yopaseopor]

@Minh_Nguyen

give_way that only pertain to a limited number of signs

With +1 million and one of the traffic sign most mapped would you change for now something about that rather than add national id, position, direction and side?

@Minh_Nguyen

I put together a list of general sign categories in some major sign systems . Feel free to add more standards to it.

Ok, except MUTCD you can find some kind of information, regulatory, complementary and warning (hazard in OSM, to use the proposal accepted) .It is true that there are some more specific categories than others but this is to avoid the major three step classification.

I think it’s better:

traffic_sign=maxspeed (exist)
maxspeed=x (exist)

Than

traffic_sign=regulatory (new)
regulatory=maxspeed (new)
maxspeed=x (exists)

but this is one thing we can talk about, only three big categories with three steps of twenty one categories with two steps?

@Minh_Nguyen

These values are only popular because the documentation and editors historically haven’t done enough to support mappers entering more specific values, based on the more specific signs they can see with their own eyes.

Yes…but at first there are the top values of traffic signs. At first I cannot ignore them.

@Minh_Nguyen

It’s the same story if they encounter a sign that hasn’t been standardized yet

Well, let’s start to build the path to do this. It is difficult to get an approbation of near 250 new key/values (probably only 100 exists now). First approve what exists now and then we can add new content.

@Minh_Nguyen

By contrast, if they’ve already chosen a specific sign code visually using a preset, then they shouldn’t need to additionally provide the sign’s category.

If you give both possibilities then you will have double possibilities of success in mapping these traffic signs. Trees accept species and species in languages, why can’t do some similar? (possibility,not obligation, of be more technic or more “street level”.)

@Minh_Nguyen

but we can come up with a shortlist for consistency if you prefer.

The idea, mid-term is to have a complete system for mapping traffic signs, with all the software adapted to that, with proposals to center all the traffic signs in traffic sign tag and to have a complete list/system/picture table of traffic_sign:id. But step by step. I hope more people would be attracted to this “roadtrip”.

@Minh_Nguyen

The text of the Vienna Convention calls them “additional panels”, while British English calls them “supplementary plates”.)

Sorry for my bad English

@Minh_Nguyen

OK, if I misunderstood the purpose of including sign images and codes in this proposal, then please feel free to revert my changes.

No, your opinion and your suggestions are so valuable, and I respect that instead I could not be agree in all. I think both we’re interested in a way to map traffic signs, and to do the easiest way with the most consistency possible.

@Minh_Nguyen

But animals come in all shapes and sizes, so usually there’s a whole series of signs with cute and cuddly animal pictograms, requiring an additional hazard:animal=* or hazard:species=* tag.

Well , it is the opportunity to use a third level of concretion. One more value-to-key. animal_crossing | Keys | OpenStreetMap Taginfo

@Minh_Nguyen

with an additional plaque. But the main sign’s number is the same in both cases.

Yes, for this reason we need second position. In Europe these plaques are complementary traffic signs, so this would map the second traffic sign with the position system using national id and the human_readable value when decide this.

@Minh_Nguyen

By the way, this issue probably complicates your desire for :2 and :3.

No, it makes easier to see why we need these second or third position. I have identified more than 200 in Deutschland’s traffic law. Probably would not be 200 human readable values but then you have 200 national id’s without problem.

@Minh_Nguyen

But not every country has two different signs for oneway=yes.

Well. That now exists, some countries prefer prohibitory traffic signs to avoid turn left and some others prefer mandatory to turn right or go through. Different national codes, different human readable values…but same action.

@Minh_Nguyen

Destination signs are some of the most extreme combinations,

It is clear destination probably will be another proposal in the future. There are a big variety of colors,positions of the text, orders, functions…It is a complex item. Let’s start by the easier and existing if possible.

@Minh_Nguyen

but combinations like are very common too.

In some countries there will be combinations, in some countries there are two traffic signs, why can’t exists a descriptive way of mapping to make available these two different?

@Minh_Nguyen

My concern is that requiring every traffic sign node to be dual-tagged with its effect will cause mappers to view one or the other as redundant or superfluous

My concern is arrived to a point some mappers would decide which kind of mapping is superfluous and delete my work for example, translating all the national codes (40 different pics) of 40 countries to one readable and unique human readable value. Let’s coexist together. There is no obligation to map whatever you don’t know or you don’t want to, but let the others do.

@Minh_Nguyen

but don’t make that a requirement.

It is not a requirement, it is an option. All of these started because I want to maintain both tagging and I have used widely a few used tag, found in taginfo. These will occur more times in the future when people maps traffic sign as a real item with its importance. There will be tendencies so it is important to establish a way of do it.

[yopaseopor]

@IanH

I think this a good start this is a lot signs to work on at once. Can take a type or two a work out common themes first? Leading to a consistent way to describe a sign. That way we will have a basic framework that can be applied to other categories.

At the proposal you have examples for traffic_sign=hazard and traffic_sign=max* or min* . I think it is a good start to use them (they exist) and start to thinking the other categories with the other human readable values (because traffic_sign:id would be approved in first proposal). I think is so clear:

• First you say the type of the traffic sign: Warning (Hazard in OSM),Regulatory (new)(all the maxspeed,maxwidth,maxheight,maxweight,maxaxleload,overtaking…),Information (new) (includes city_limit traffic_signs) ,Complementary **(new)**or Others. Stop and give_way uses highway (existing) key until community decide to unify all the traffic signs with one key.

• Then you apply the subkey for this type (like hazard).

• Do you know the id of the traffic sign in its country? Use traffic_sign:id=* (new)

• Finally you say the direction relative to the way: direction=forward, direction=backward, direction=90 direction=270 .

• And don’t forget the side of the way the sign is located.

When there is a second traffic sign you use the subtag 2: to traffic_sign tag and so on (e.g. traffic_sign:2=maxspeed and/or traffic_sign:2:id=DE:206).

What am I missing? Tell me, I can fix it before presenting the proposal.

[yopaseopor]

@Minh_Nguyen

I think this is a fair question that deserves a straightforward response

I have said I’ll do, but I’m conscious I can fail. But no worries, If I do not get it, other in the future will get to. This is first time I see in tagging list/forum so big interest for traffic signs in general (81 messages talking about traffic signs), from the way of we are mapping it to the content we are mapping it.

@Minh_Nguyen

we’re wasting our time (myself particularly)

I don’t think so. Probably if I fail with this you will start other with all the information also you have searched to help me.

@Minh_Nguyen

back to the question of what to do with your widespread edits, which are in the minority.

My edits are not important (of course I don’t want to my job of three months would be deleted - because It was not incorrect-). But It is more important establishing a consistent way of mapping, to do 3D mapping, to can map all the traffic laws existing,to have more and more people mapping traffic signs (not only the effects - for me is like we are mapping the shadow of the tree or only the light of the street lamp), and the possibility of developing software to do that and to use that, as other topics we have in OSM, more than We have today.

[Minh_Nguyen (Minh Nguyễn)]

@yopaseopor

@Minh_Nguyen

give_way that only pertain to a limited number of signs

With +1 million and one of the traffic sign most mapped would you change for now something about that rather than add national id, position, direction and side?

In my view, even if the proposal were to deprecate traffic_sign=give_way with about 1,300 occurrences, it could avoid disruption by saying that the replacement for traffic_sign=give_way is to set traffic_sign=* to the relevant traffic sign code, with the usual admonition against bulk edits. No new tag would need to be proposed for yield signs. This would effectively reinforce the existing practice of gradually refining the keyword values into more specific sign codes as we identify the signs in street-level imagery or via a field survey.

That said, I’m not even suggesting to deprecate traffic_sign=give_way. I’m just saying you should ignore these values for now, in favor of one of the other ideas you’ve expressed in this proposal. You’re insisting that all these changes need to happen together, but I don’t see how they’re inextricably linked.

@yopaseopor

I think it’s better:

traffic_sign=maxspeed (exist)
maxspeed=x (exist)

Than

traffic_sign=regulatory (new)
regulatory=maxspeed (new)
maxspeed=x (exists)

but this is one thing we can talk about, only three big categories with three steps of twenty one categories with two steps?

traffic_sign=regulatory more or less already exists for miscellaneous regulatory signs that can’t be described by other values. But I still am not convinced that traffic_sign=ES:R-301 or traffic_sign=US:R2-1 really needs to be shunted over to a new key. Doing so would be more disruptive in my opinion. We’re talking about the 29% of all traffic_sign=* nodes globally that is most readily consumed by data consumers.

@yopaseopor

@Minh_Nguyen

By contrast, if they’ve already chosen a specific sign code visually using a preset, then they shouldn’t need to additionally provide the sign’s category.

If you give both possibilities then you will have double possibilities of success in mapping these traffic signs. Trees accept species and species in languages, why can’t do some similar? (possibility,not obligation, of be more technic or more “street level”.)

We’ve already discussed this previously. The only thing I’d add is that the scientific name in species=* is analogous to the sign codes that you want to relegate to traffic_sign:id=*, whereas the entirely optional common names in species:*=* are analogous to the human-readable keywords you want to rely on as the primary tag.

@yopaseopor

@Minh_Nguyen

By the way, this issue probably complicates your desire for :2 and :3.

No, it makes easier to see why we need these second or third position. I have identified more than 200 in Deutschland’s traffic law. Probably would not be 200 human readable values but then you have 200 national id’s without problem.

Here’s an example of the kind of complication I foresee when a single sign’s meaning depends on another sign:

Assembly	Meaning	Current tagging	Proposed tagging
	Pedestrian crossing	traffic_sign=US:W11-2	traffic_sign=hazard hazard=crossing traffic_sign:id=US:W11-2
	Pedestrian crossing	traffic_sign=US:W11-2,W16-7PL (or 2 nodes with layers)	traffic_sign=hazard hazard=crossing traffic_sign:id=US:W11-2 traffic_sign:2=complementary traffic_sign:2:id=W16-7PL traffic_sign:2=right
	Pedestrian crossing ahead	traffic_sign=US:W11-2,W16-9P (or 2 nodes with layers)	traffic_sign=hazard hazard=crossing_ahead traffic_sign:id=US:W11-2 traffic_sign:2=complementary traffic_sign:2:id=W16-9P
	Trail crossing	traffic_sign=US:W11-2,W11-15P (or 2 nodes with layers)	traffic_sign=hazard hazard=crossing traffic_sign:id=US:W11-2 traffic_sign:2=complementary traffic_sign:2:id=W11-15P
	Trail crossing in 500 feet	traffic_sign=US:W11-2,W11-15P,W16-2P distance=500' (or 3 nodes with layers)	traffic_sign=hazard hazard=crossing_ahead traffic_sign:id=US:W11-2 traffic_sign:2=complementary traffic_sign:2:id=W11-15P traffic_sign:3=complementary traffic_sign:3:id=W16-2P traffic_sign:3:distance=500'
	Pedestrians in road	traffic_sign=US:W11-2,W16-1P (or 2 nodes with layers)	traffic_sign=hazard hazard=pedestrians traffic_sign:id=US:W11-2 traffic_sign:2=complementary traffic_sign:2:id=W16-1P
	Pedestrians in street	traffic_sign=US:W11-2,W16-1aP (or 2 nodes with layers)	traffic_sign=hazard hazard=pedestrians traffic_sign:id=US:W11-2 traffic_sign:2=complementary traffic_sign:2:id=W16-1aP
	Pedestrians in street, 35 mph advised	traffic_sign=US:W11-2,W16-1aP,W13-1 maxspeed:advisory=35 mph (or 3 nodes with layers)	traffic_sign=hazard hazard=pedestrians traffic_sign:id=US:W11-2 traffic_sign:2=complementary traffic_sign:2:id=W16-1aP traffic_sign:3=complementary;maxspeed:advisory traffic_sign:3:id=W13-1 traffic_sign:3:maxspeed:advisory=35 mph

This is a lot of extra tagging that can make it very easy to miss the differences between each configuration. It isn’t possible to create a single preset to represent the very recognizable , because the tags can vary so much. Instead, some presets would have to represent sign assemblies and coexist with other signs on the same post. Yet I don’t see how these additional tags allow data consumers to more easily present, say, hazard warnings that visually match the real-life signs.

@yopaseopor

Well. That now exists, some countries prefer prohibitory traffic signs to avoid turn left and some others prefer mandatory to turn right or go through. Different national codes, different human readable values…but same action.

@yopaseopor

My concern is arrived to a point some mappers would decide which kind of mapping is superfluous and delete my work for example, translating all the national codes (40 different pics) of 40 countries to one readable and unique human readable value. Let’s coexist together. There is no obligation to map whatever you don’t know or you don’t want to, but let the others do.

If so, then what information does the current tagging fail to express that your proposal would express? hazard=*, highway=stop, etc. are already well-established tags that are being used every day. The same mappers who map traffic signs also map these things – but they don’t consider them to be the same feature, even if they happen to dual-tag them. It is your proposal that would conflate the two kinds of features, eliminating the “option” to map the sign without the effect at the location where the effect does not apply yet. (By the way, some hazard=* values like animal_crossing and pedestrians apply to a whole section of the roadway, not just a point along it.)

[mueschel]

@Minh_Nguyen

|
Trail crossing in 500 feet
traffic_sign=US:W11-2,W11-15P,W16-2P
distance=500'

If that was a European sign, the tag would be
traffic_sign=US:W11-2,US:W11-15P,US:W16-2P[500']
Signs with a variable part are added in brackets - all the information is available from one single key which makes reading and interpreting it very simple.

@Minh_Nguyen

This is a lot of extra tagging that can make it very easy to miss the differences between each configuration. It isn’t possible to create a single preset to represent the very recognizable , because the tags can vary so much. Instead, some presets would have to represent sign assemblies and coexist with other signs on the same post. Yet I don’t see how these additional tags allow data consumers to more easily present, say, hazard warnings that visually match the real-life signs.

I fully agree. The existing tagging is simple - just a list of signs one can select from a drop-down menu. And it contains all relevant information.

[Minh_Nguyen (Minh Nguyễn)]

@mueschel

If that was a European sign, the tag would be
traffic_sign=US:W11-2,US:W11-15P,US:W16-2P[500']
Signs with a variable part are added in brackets - all the information is available from one single key which makes reading and interpreting it very simple.

Simple is in the eye of the beholder. For editor developers, this is as simple as making the opening hours syntax user-friendly. On this point, I agree with @yopaseopor that the mini-language with brackets is too limiting. It’s how mappers end up making up their own key-value syntax just to stuff everything into one tag value. It only happens to work for most Vienna Convention signs by coincidence (other than destination signs). I would have had little to say except a big thumbs up if the proposal had been limited to more or less the the idea of favoring the secondary keys over the mini-language.

[mueschel]

@Minh_Nguyen

the mini-language with brackets is too limiting.

I love these text signs. It’s clear that the current syntax has problems with American style signs. For all the countries following the Vienna convention the current syntax is very well suited. There are almost no exceptions where it doesn’t work or the character limit for values kicks in.

I see that there is a need to cover complicated cases, but I think it must not rely on complicating the simple scheme that works in large parts of the world very well. We need to define an extension to the current scheme without invalidating it and without forcing people to use a (in their region) needlessly complicated scheme.

@Minh_Nguyen

mappers end up making up their own key-value syntax just to stuff everything into one tag value

Well, this should be covered by a simple scheme that says “for traffic_sign=destination” the text is given using the destination:* namespace" and a proper decision on how to map the direction of signs.

[yopaseopor]

@Minh_Nguyen

No new tag would need to be proposed for yield signs.

“Mine” yield has not the same picture as yours. Tell me how to map these two different pictures. With give_way is not a big problem to maintain the id in traffic sign…because uses highway. But tell me the others.

@Minh_Nguyen

You’re insisting that all these changes need to happen together

The only I want to happen together is the existence of traffic_sign:id (because traffic_sign=human_readable_value exists. This proposal establishes how to map physically and logically (the possibility of human-readable-values and the possibility of national code, whatever you do both or one.)

@Minh_Nguyen

traffic_sign=regulatory more or less already exists for miscellaneous regulatory signs that can’t be described by other values.

@Minh_Nguyen

But I still am not convinced that traffic_sign=ES:R-301 or traffic_sign=US:R2-1 really needs to be shunted over to a new key

Matching reference to 108 values ,do you say a tag with +140000 does not exist? My proposal gives the opportunity to have both information. Tell me , how I can map that is traffic_sign=maxspeed and the picture of this both at the same object?
It is not obligatory, if you want don’t change anything, but let the others that can map in this way.

@Minh_Nguyen

Here’s an example of the kind of complication I foresee when a single sign’s meaning depends on another sign:

1-Tell to a non-US how to map that based on street level imagery on the left.

@Minh_Nguyen

traffic_sign=hazard
hazard=crossing_ahead
traffic_sign:id=US:W11-2
traffic_sign:2=complementary
traffic_sign:2:id=W16-9P

2-that is not correct but I recognize probably the proposal have some lacks. That is why this discussion is very important. Should be

traffic_sign=hazard
hazard=crossing
traffic_sign:id=US:W11-2
traffic_sign:2=complementary
complementary:2=ahead
traffic_sign:2:id=W16-9P

traffic_sign=hazard
hazard=crossing
traffic_sign:id=US:W11-2
traffic_sign:2=complementary
traffic_sign:2:id=US:W11-15P
complementary:2=trail_crossing (or assimilable to crossing=trail_crossing, Why not, let’s discuss in a separate proposal)
traffic_sign:3=complementary
traffic_sign:3:id=US:W16-2P
distance=500’`(as you don’t have any value that occupied that key why do you have to use one supplementary? Talk about it. )

traffic_sign=hazard
hazard=pedestrians
traffic_sign:id=US:W11-2
traffic_sign:2=complementary
traffic_sign:2:id=US:W16-1P
complementary:2=in_road

or

traffic_sign=hazard
hazard=pedestrians
traffic_sign:id=US:W11-2
traffic_sign:2=complementary
traffic_sign:2:id=US:W16-1P
pedestrians=in_road

traffic_sign=hazard
hazard=pedestrians
traffic_sign:id=US:W11-2
traffic_sign:2=complementary
traffic_sign:2:id=US:W16-1aP
complementary:2=in_street

or

traffic_sign=hazard
hazard=pedestrians
traffic_sign:id=US:W11-2
traffic_sign:2=complementary
traffic_sign:2:id=US:W16-1aP
pedestrians=in_street

traffic_sign=hazard
hazard=pedestrians
pedestrians=in_street
traffic_sign:2=complementary
traffic_sign:3=maxspeed:advisory
maxspeed:advisory=35 mph
traffic_sign:id=US:W11-2
traffic_sign:2:id=US:W16-1aP
traffic_sign:3:id=US:W13-1

or

traffic_sign=hazard
hazard=pedestrians
complementary:2=in_street
traffic_sign:2=complementary
traffic_sign:3=maxspeed:advisory
maxspeed:advisory=35 mph
traffic_sign:id=US:W11-2
traffic_sign:2:id=US:W16-1aP
traffic_sign:3:id=US:W13-1

@Minh_Nguyen

hazard warnings that visually match the real-life signs.

They can use the first part of the tags or the second. They have human readable values and they have all the codes and the positions they need to represent it.

This kind of things you can do it with US preset in JOSM for almost 5 years…I think (not human readable values). And you have represent it to level 2 with the style. More data, with your part of layers, preset and style would represent this now. Not with the first multivalue solution.

@Minh_Nguyen

Yet I don’t see how these additional tags allow data consumers to more easily present, say, hazard warnings that visually match the real-life signs.

When you have a human readable value, if you want to put the national code you have to change the tag with traffic_sign. Tell me how to do it without change the tag or using traffic_sign:id

@Minh_Nguyen

then what information does the current tagging fail to express that your proposal would express?

When I want to use national code in a sign with the tag traffic_sign=human_readable_value

@Minh_Nguyen

but they don’t consider them to be the same feature

Well, they can consider whatever they want. If you see map features from 2006 or 2010 it is clear that highway=stop and highway=give_way are signs, traffic signs. Hazard is different but I can think that if you tag traffic_sign=hazard… it is a traffic sign.

[yopaseopor]

@mueschel

all the information is available from one single key which makes reading and interpreting it very simple.

In Spanish you can say “hacerse trampas al solitario” (you are just kidding yourself). What is the target of tagging in OSM: Tagging in one-only tag or tagging the best way and more exhaustive can do?

Here there are some possible one-only tag:

natural=tree,description [Arbres d’interès local de Barcelona. pl. de Catalunya],protected [yes],species [Quercus ilex ssp. ilex],species:ca [Alzina], website [https://www.barcelona.cat/ca/que-pots-fer-a-bcn/parcs-i-jardins/arbres-interes-local/arbre-d-interes-local-alzina-pl-de-catalunya_99400455045.html]

highway=traffic_signals, crossing [traffic_signals],tactile_paving [no],traffic_signals:sound [no], traffic_signals:vibration [no]

Well, in one tag you can have all the information.

@mueschel

The existing tagging is simple

Is the existing tagging complete?

@mueschel

And it contains all relevant information.

Tell me, how can I map the picture of a existing traffic_sign=maxspeed without changing this tag?