Proposal talk:Extended traffic signs tagging

From OpenStreetMap Wiki
Jump to navigation Jump to search

Before you go too much further have a look what was done in Helsinki: they map actual traffic signs (say a speedlimit sign) and the meaning of the sign (maxspeed on a highway. Doing this they found both errors in the OSM tagging and errors in the signage placed by the city council. It's documented somewhere on the wiki. The reality is that most of the time we are interpreting the meaning of the sign and encoding that using tags, mapping the actual sign is quite rare. SK53 (talk) 11:16, 19 February 2017 (UTC)

Mapping the actual sign as a source of information

I know a red circle with two numbers is meaningless. The key is the meaning we give to that set of things all together.But I think we part of an erronial misinterpretation of the reality. Traffic signs mark the start or the end of some condition of the way...or give you some information about the circumstances of the way in a concret point, then you can retain this information (like distances or recommendations). Yes, we can extract that information and "explain it" in every track or we can map an actual sign and the system would determine that in that point start this information (as real drivers do). Traffic signs are so important "by itselfs". Every country has its own, also. Talk to your government to give you a list of every section with every property you can imagine. Our government made it simple: list of traffic signs with all these values we are talking about.

Computers can do all this work lonely, but I don't know why big car fish as Toyota or Hyunday or Google are worried about recognition of traffic signs as they are not important by itself.

Also I don't understand why exists the key traffic_sign . I would erradicate all of them ;)

Sorry...but you are late. I went too further. I don't know if it is so important or not a traffic sign. 29 presets are done (also they can map sections). Style shows you more of 8000 different traffic signs of 29 different countries. And with Kendzi3D plug-in in JOSM you can watch these generic traffic signs in 3D.

I know micromapping will be a hard work...but as all the things in OSM let the people decide if this is useful or not. If all of that is meaningless and unuseful nobody will use it, and this proposal will die by itself. If something is harvestable , good one, can use all or part of this new scheme for tagging a real and a massive element as a traffic sign is.

PD: Think about railways...They also have traffic signs...and are also start to mapping it... ;) yopaseopor (talk) 00:30, 20 February 2017 (UTC)

should to be compatible with both trends (exact sign localisation or not)

The proposal is interesting but the key side should be improved. It would be useful to be compatible with both trends: - locate one or more nodes where sign(s) are located. a relation ? - summarize the location of panel(s) with a word as you describe with the side key. The side word is also maybenot the better. maybe localisation is better The Traffic_signs_XX preset for josm is usefull but it lacks the ability to set more than a location. For example down+right is common for stop and giveway signs. Marc CH (talk) 20:19, 16 June 2017 (UTC)

Clarification questions

In a given road, there could potentially be multiple traffic signs at the same physical location (consider a sign gantry with directional signage above the road, and other signage (speed limit, etc.) to the side on the vertical post supporting the gantry.

A single 'side' tag on the node would be unable to capture this complexity.

Instead, consider making 'side' also a subtag of traffic_sign, as in:

traffic_sign:side=right|left|...

Then it is clear exactly to which 'sign' the 'side' value relates. I.e. for my gantry example the tags could be:

traffic_sign=maxspeed

traffic_sign:side=right

traffic_sign:2=stay_in_lane

traffic_sign:2:side=up

A similar argument applies for other 'sub-tags' (i.e. category, maxspeed, etc.) Placing them all as explicit subkeys under the top "traffic_sign" allows for mapping explicitly each of plural signs at a single point in the real world effectively and accurately.


Regarding the 'side' tag, are 'up'/'down' already defined elsewhere? If not, consider "above" and "pavement" as possible alternatives, and possibly more descriptive, values.

The 'both' value for the side key is ambiguous by itself. And when defined to mean "left and right" it leaves no way to mark a 'both' for "up and down" simultaneously. Instead maybe allow plural values? This would also allow for any possible combination of all four cardinal directions to be mapped if need be (for those instances where there are multiple occurrences of the same 'sign' at the same location):

traffic_sign:side=left;right

traffic_sign:side=above;pavement

traffic_sign:side=above;right


Re. multi-sign markings. Consider defining explicitly where the numeric sub-tag should appear. The present definition leaves open these two possibilities as both simultaneously being valid:

traffic_sign:2:direction=backward

traffic_sign:direction:2=backward

It would seem to be better to explicitly define one (I prefer the first: traffic_sign:2:direction) as the valid tagging.

Good apreciation

Road marks are the same traffic sign or a different traffic sign with its code (some countries road marks has its own code)?

Because if it is I think it would be difficult to have a traffic sign with road mark code in other place than pavement (I like the above, pavement solution). The same thing I say for the gantry traffic signs. It is so difficult the same traffic sign is placed at the gantry (above) and in the left or the right (it could be the same pic or very similar, but a different traffic sign - with other code).

For this reason codes in the traffic signs are so important. Because there is a lot of similar traffic signs but little different, and they have their placement.

Also it is difficult to see different traffic signs in the left and in the right (if the way is not splitted) because this could get the driver to a mistake. Here in Spain we repeat the traffic signs at the sides to reforce the meaning of it. But I have to say the new format of a subkey side would be interesting (traffic_sign:side)

For the generic messages I bet to a new "category" key with the category you can get on the traffic laws and OSM (maxspeed,complementary,warning,regulatory,compulsory)

The format of the traffic_sign:direction tag would be like your proposal, to explicit to which traffic sign is refering. So it is better traffic_sign:2:direction=backward as you proposed

Thanks for your opinion --Yopaseopor (talk) 16:57, 9 October 2018 (UTC)

Road marks are the same traffic sign or a different traffic sign with its code

I was specifically thinking of different signs (i.e., a gantry with a "stay in lane" sign above and a "max speed XYZ" to the side on the vertical support pole for the gantry). Both signs 'exit' at the same geographic location, one 'above' one to the 'side' (right or left depending). But I suspect if someone looked long enough they could find an instance of the exact same signage positioned 'above', to the 'right' and on the 'pavement' at the same geographic location. The 'real world' often does illogical things.

Also it is difficult to see different traffic signs in the left and in the right (if the way is not splitted)

I can think of one possibility. A "no left turn" sign on the left side of the road, with a "max speed" sign on the right side of the road.

I've found two examples of different traffic signs at 'same location':

[1]

In the photo above, the "directional" signs on the gantry are almost (to the extent I can tell from the photo) in the same geographic location (only positioned 'above' the road) as the "keep right" sign in the median below the gantry.

[2]

In the photo above, there is a "left turn only" sign on the left side of the road, and a "through only" sign on the right, in the same geographic position relative to the road, and the road is not split where these two signs exist. This photo is also an example of physical signage duplicating pavement markings, as the two signs duplicate the turn control markings on the roadbed itself.

In the US I've also seen many examples of maxspeed signs being placed at the same location on both sides of the road. I.e., see [3]. So a need to also specify 'same on both (sides)' is also present in the real world.

Example of signs above road on a gantry and a different sign on the gantry support pillar: [4]. The signs on the gantry are navigational signs, the sign on the gantry support pillar is an advisory maxspeed sign.

:direction

On a node beside the way it is facing direction of the sign. wiki: You can use the direction=* tag to describe the facing orientation of the sign by using an angle or cardinal direction. On a node in the middle of a way, when used direction it is also facing direction, not as you want the direction of operation of the traffic_sign, for that there is no special key name, beside the use of traffic_sign:forward ( drawing direction OSM way). I am against the use of traffic-sign:direction=* on a node of a way. ! It is confusing.! The opposite. On a node beside the road, there it is, what we see, what we map. The base. With facing direction as traffis_sign:direction. (Could be on a highway=streetlamp pole) On a way, setting traffic_sign is first-degree derived from the traffic_sign. Then there is second-degree derived, these are the access tags for all kind of transportation. The most difficult translation of traffic signs to OSM tags taking into account other traffic regulations regulated by law. This often goes wrong because one does not know the rules, consciously or unconsciously, partially tagged. Although the law is clear by law. We need first_degree tagging to check, second degree if the tags are right, for example moped mofa on a cycleway. Even we can check the barrier in the way, cycleway is not the default for moped mofa. For better quality in Openstreetmap. Manual set, traffic_sign:forward on a way, maybe is should be a beter keycombination for it source:traffic_sign:forward=* meaning the direction of operation of the trafficsign. Actually the traffic_sign is not there, maybe on a portal above the road. If one mapper change the road in the other direction, forward must be changed by the program in backward. --AllroadsNL (talk) 18:03, 9 October 2018 (UTC)

:direction answers

The cardinal direction is not a good idea: roads and streets are not so straight then direction would change in every curve, every kilometer. Imagine at the mountain : direction=SW and 100 meter later direction=N . It is not confusing, drawn way has a direction (this direction would be the same about the pk's, or the order of housenumbers.

It is not true that ALWAYS you see the direction because of the placement of the traffic sign. There are traffic signs forward and backward in all the sides by thousands.

The street lamps don't have direction, because the streetlamps gets you light wherever they are, not only forward or backward.So it would be interesting to have separate the key direction with traffic_sign:direction

Traffic signs are not only but also for access tags (warning signs talk about access? information traffic signs talk about access? Program changes the word backward and forward when you change the direction of the way so it would not be a problem. It is interesting your proposal about the source of the traffic sign. It would be interesting to develope it. --Yopaseopor (talk) 19:59, 9 October 2018 (UTC)

cardinal direction, I do not write, use it on roads, only on the node beside the road. The real traffic_sign position. That is correct! Facing direction of sign. You do not understand: The use of direction in combination with traffic_sign, on node and node on way, :direction must have the same meaning. Facing direction. This can not be used on the roadline. Because you give :direction a different meaning. That's why I wrote: I am against the use of traffic-sign:direction=* on a node of a way. ! It is confusing.!--AllroadsNL (talk) 22:16, 9 October 2018 (UTC)
On road: traffic_sign:forward=NL:C6 is enough, but because the real trafficsign is not there it is a derived tag, first-degree derived source:traffic_sign:forward=NL:C6, with a relation you can connect it to the real traffic_node. Here is used location_hint Example: Ekris Mapillary This is also a kind of tagging. On the other side of the road there is not a sign. You can drive till this back of the sign turn and drive back, legally, so it is more a no_entry restriction, a point access from one side. People do not like making relation, if they not need to they use the :forward construction.--AllroadsNL (talk) 22:50, 9 October 2018 (UTC)

more answers for :direction topic

-I explained myself not clear as I want .I want to say that the road have change their cardinal direction due its curves and straight lines so the nodes beside them changes also the direction as the way does also .Example: one node with direction=SW and 100 meter later direction=N in a mountain road. For this reason it's better to use the direction of the way: forward or backward along kilometers if you need so.

-:direction suffix is used with traffic signals. As nodes does not have direction by itself they took the direction of the way, as other keys do like maxspeed or overtaking.

-I'm agree make a relation in every traffic sign is time loosed.

-For the example you said I see three traffic signs (I consider complimentary as a traffic sign with its code). I think we don't have to understand the traffic sign and "translate" the meaning. I think we can put the information as it is. And consider the traffic_sign:2 information to exact consider the target of the information.

Dynamic electronic message board signs

Here we see an electronic sign board that can display a changeable message ("Road closed 30 km, ahead.", "Drinking and driving: Fine $5000", whatever.) How to tag? Also it extends halfway across the road. How to map? Jidanni (talk) 09:26, 6 August 2019 (UTC)

It can be easy. In Spain electronic panels have their own traffic sign code, traffic_sign:forward=ES:S800e. As they have their own traffic sign code you can specify which side of the road the pole is (side=right) because the sign with that code is always a vertical panel above the road. Mapillary also recognizes it. --Yopaseopor (talk) 09:46, 6 August 2019 (UTC)

Key:information

I like your proposal but I would nbot like to see the values of information=* extended so much, because it is already an under-tag of tourism=information. Maybe there could be another name for the new key, under-key of category=information. --Lukas458 (talk) 14:41, 10 May 2020 (UTC)

I agree, we already have too many Homonymous_keys, not sure if traffic_sign:information=* / traffic_sign:restriction=* / traffic_sign:lanes=* a.s.o. would work instead? --MalgiK (talk) 12:18, 3 March 2024 (UTC)

Traffic control

You misunderstood highway=stop and highway=give_way which are the functional position where vehicles should stop. They should not be used for the linearly referenced sign itself, which can be positioned upstream or downstream of the stopping line. There are also advance signs for them. That's my main criticism in the last post.
—— Kovposch (talk) 08:31, 17 February 2024 (UTC)

As you can read today on highway's OSM wiki page stop and give way talks about a "sign". Being one of the oldest items of highway=* key and with millions items in OSM mapped around the world it is not clear that really highway=stop and give_way are "functional position" rather than "traffic sign". It is a big discussion. This proposal will not change that, for the moment.--Yopaseopor (talk) 09:42, 17 February 2024 (UTC)
Oh come on. "Sign" is how they are referred to colloquially. The position is where the vehicles should stop. This is the same as highway=traffic_signals . Besides, you thinking doesn't apply to the crude method where they are added to the intersecting point in the first place.
—— Kovposch (talk) 14:30, 17 February 2024 (UTC)
Sign is sign, specificly we are talking about a "traffic" sign. As I have said before this proposal does not change the nowadays situation whatever it is. In a future would be able to be other and future proposals. If you don't like that present expression in the wiki please change highway's wiki article.--Yopaseopor (talk) 19:20, 17 February 2024 (UTC)
@Yopaseopor: You are being pedantic. The article makes abundantly clear that it applies to the stopping position indicated by the sign. The reason it says "stop sign" is because laypeople do not have a more precise word for it in English. As requested, I clarified the documentation. If your proposal suggests to apply highway=stop to the physical sign, I'm pretty certain it will not be successful. – Minh Nguyễn 💬 22:51, 18 February 2024 (UTC)
I don't know if changing the wiki during a proposal process is the best way to assure the reasons you are writing here. Why I can't think when the wiki says "stop sign" is a "stop traffic sign" ? But it is not a problem. This proposal does not change anything about stops and give_ways, so these should not affect this proposal. --Yopaseopor (talk) 22:59, 18 February 2024 (UTC)

I changed the wording but not the meaning of the page. I believe that my edits to the page are uncontroversial, but you can ask for a second opinion on the forum or elsewhere if you disagree.

I did not say that a stop sign is not a traffic sign. But I did say that English speakers often refer to "a stop sign" when they really mean "the stopping point indicated by a stop sign", because unlike some other languages, English doesn't have a more convenient term for that concept. You would have to badly misread the page in order to think it refers to the physical sign, but I agree that the beginning of the article was written too vaguely before.

 – Minh Nguyễn 💬 23:14, 18 February 2024 (UTC)

@Kovposch: Indeed, the difference between the functional stopping point and the linearly referenced sign position can be the difference between stopping for a pedestrian at a crosswalk and running them over. – Minh Nguyễn 💬 23:21, 18 February 2024 (UTC)

English very much does have a generic term for the place where vehicles actually stop: stop line. Same for give way line or yield line if you prefer.

Incidentally the term "traffic sign" as a matter of UK law applies to both signs on poles and painted road markings. Hence a give way sign on a pole is optional for a junction and is used where extra visibility and emphasis is needed. It is the combination of double dashed line transverse to the direction of travel and the triangle set a little back from that line which impose the requirement to give way.

Don't know whether that concept of road markings also being traffic signs extends to other jurisdictions but it certainly is long established in the UK. Davidpnewton (talk) 11:38, 25 February 2024 (UTC)

Stop line may be understood as the line marking. The sign or marking may exist on its own at some locations.
—— Kovposch (talk) 05:40, 26 February 2024 (UTC)
In some countries road marks have its own code so to map it would not be a problem. Also remember this proposal does not change anything about highway=stop and highway=give_way rather than can use the traffic_sign:id in each country with. Probably a future proposal will be. --Yopaseopor (talk) 22:33, 26 February 2024 (UTC)

Number suffix unbalanced rationale and usefulness

You have a lengthy description of different methods. But did not explain why the numbered suffix should be used.
The meaning of different signs has already been distributed to the functional tags. It will be acceptable to use semicolon multival in traffic_sign:id=* .
—— Kovposch (talk) 08:35, 17 February 2024 (UTC)

Using multivalues is not a good idea, because when you have some other information about that specific second traffic sign it is better to have a subkey rather than mantain the same order of the semicolon, for the other information, also it is easier for a human mapper to link this information.--Yopaseopor (talk) 10:06, 17 February 2024 (UTC)
What "other information"? You don't have any examples of this besides traffic_sign:id=* , that's another problem with the proposal format.
—— Kovposch (talk) 14:31, 17 February 2024 (UTC)
You can have two speed limits with different conditions. What condition should prevail? . Other example : two city-limits together (one from start and other for the end),in the same place, what is one and what is the other if you use the same tag to the name of a city? With subkey numbers you will not have any doubt about that. --Yopaseopor (talk) 19:26, 17 February 2024 (UTC)
  1. This does not need to be handled in traffic_sign=* . It's traffic_sign=maxspeed + maxspeed:*=* / maxspeed:conditional=* . traffic_sign:id=* is a separate problem.
But it easily can be handled by the current scheme using commas and semicolons (in pseudo code, imagine proper codes here): MS[70],condition_wet;MS[90],condition[22:00-06:00] --Mueschel (talk) 10:07, 22 February 2024 (UTC)
Put all together in one key=value (separate with colons and semi-colons, as a sentence) is not a "scheme" as is, although is the present situation. Interpret the correct key to the correct value for every bracket is complicated. Perhaps other keys and values should help to make it more processable.--Yopaseopor (talk) 23:10, 23 February 2024 (UTC)
A well defined scheme is exactly what it is: A syntax that defines several characters to structure and organize defined codes. That's how many tagging schemes work e.g. opening_hours or conditional tags. And exactly like traffic_sign they are very useful and can cover the vast majority of cases without being too complicated. --Mueschel (talk) 13:44, 25 February 2024 (UTC)
The particular problem with this is text-heavy signs, especially for exceeding 255char. Separating into eg destination:*=* is more manageable and organized.
It's not "easy" to handle. The sign number is a must for using it. Can't preserve both the number and human-reading meaning reliably.
—— Kovposch (talk) 08:55, 26 February 2024 (UTC)
There are lots of scalable schemes in OSM. Trees? Recycling? Crossings? I don't know why traffic sign can't be one.
This proposal gives the opportunity to map both, if you have some information about that (newbie mapper, from the street mapping with a web editor... ) you can use one key (traffic_sign, scalable scheme) and if you have all the other information (national id for the traffic sign, etc.) you can use the other (traffic_sign:id) --Yopaseopor (talk) 22:40, 26 February 2024 (UTC)
  1. If you mean they face the same side, how is the name=* supposed to be added on it anyway? You can't use name:1=* + name:2=* for that.

—— Kovposch (talk) 23:48, 18 February 2024 (UTC)
About traffic_sign=maxspeed + maxspeed:*=* / maxspeed:conditional=*
1- Here when you have two traffic signs is because first prevails or marks the application distance of the second. If you want to map the traffic signs itself best way is mapping it as it. Finnish community had mapped combination with more than 3 traffic signs, you can see it in taginfo. There is no problem about position.
2-Well, if you have two names and each name are located in a combined traffic sign probably you will need name:2 or name:below or whatever proposal for these kind of traffic signs be written. In this proposal you will have traffic_sign=city_limit and traffic_sign:2=city_limit --Yopaseopor (talk) 22:35, 21 February 2024 (UTC)
1. You didn't explain why a number suffix is preferrable. As is, it can be traffic_sign:id=XX:R123,XX:S456;XX:R123,XX:S456 . You don't necessarily need to break it down. If there are many supplementary plates, adding traffic_sign:2:*=* to traffic_sign:#:*=* including this # many repeating traffic_sign:*=supplementary is cumbersome.
2. No, you can't use number suffix for names. That's also ambiguous as to whether there are different names for the same thing which is discouraged in general. Other name:*=* still won't work. This shows the functional tags can't be matched successfully with number suffix for multiple signage from the same attribute. Further to 1 above, you can't show what maxspeed:conditional=* each combination of signs is showing, nor the opposite question of what combination of signs a maxspeed:conditional=* clause is signposted as.
—— Kovposch (talk) 06:19, 26 February 2024 (UTC)
I have explained so clear in this discussion. You can't have the information related based only in the order of a multivalues separated by semicolons and commas.
If there are many supplementary plates each has its own identity so you if you want to attach it a human readable value you will have to specify each one, instead the key would be the same.
It is not using a suffix for names because this thing has two names, it is related to the position of the traffic sign.
About the conditional, of course I can show all the values, but as probably there will be complementary traffic signs with its national code and its human-readable values I have to map it as it. --Yopaseopor (talk) 23:30, 26 February 2024 (UTC)
I fully agree that several tags are not useful here: Signs mounted together have a logical connection with each other, one complementing another. This can't be reduced to a pure list of values. The current scheme has the very useful distinction between commas and semicolons for this. --Mueschel (talk) 10:07, 22 February 2024 (UTC)
The current "scheme" is to put all together keys and values. It is not so structured. Of course with this present "scheme" you can map anything, only you have to describe it and put the values inside brackets. Imagine taginfo with big multivalues like DE:274.1[10];265[3.5];262[7.5] or PL:C-16;PL:T-Dopuszczony␣ruch␣rowerowy , DE:257-51;DE:"Dies␣gilt␣auch␣für␣das␣Führen␣von␣Reittieren" , FR:B14[80],M4f[3.5␣t];FR:B14[90],M9z[Rappel]. How many DE:265 do we have if all are mapped in this way? --Yopaseopor (talk) 23:10, 23 February 2024 (UTC)
We don't map for tools giving statistics like Taginfo. If you want to get this information, you can still write a database query for it. And no, brackets are not there to just put any value you like, they are for variable values on defined signs. Free text would be added in quotation marks.--Mueschel (talk) 13:44, 25 February 2024 (UTC)
We don't map for the render, but is it a big problem to use a scheme that works and simplify majority of software?
We map to have an easy to use database of the world. The curerent scheme provides this. --Mueschel (talk) 11:49, 3 March 2024 (UTC)
Also tell us, before this proposal, how to map an human-readable value that uses traffic_sign key and the national id itself? --Yopaseopor (talk) 23:02, 26 February 2024 (UTC)
There is no need to do this. Abstraction like conversion between values and human readable text is a main feature of editors, but is never done in the database. It's exactly the same what every translation layer does: The Italian user clicks on "casa" and "building=house" is added. There is no need to have "casa" in the database. --Mueschel (talk) 11:49, 3 March 2024 (UTC)
I agree that semicolons alone won't completely solve this problem, because traffic signs can be combined in all sorts of configurations that make parallel keys quite error-prone, like this cluster of what appear to be two double-sided street name signs but which, on closer inspection, indicate a county boundary at which the road name changes. There's a greater need for this flexibility when mapping a physical sign assembly than when annotating a roadway with information indicated by the same signs. When mapping the physical signs, it becomes possible to map the signs individually, but this isn't very feasible when annotating a roadway. – Minh Nguyễn 💬 23:08, 18 February 2024 (UTC)
My question would be 2 above. Does number suffix help with adding name=Edwardville Road + ref=CR 196 ? Then it's not a complete solution.
—— Kovposch (talk) 00:07, 19 February 2024 (UTC)

Yes, it would be

  • traffic_sign=confirmation/destination/whatever the proposal about destination sign approach,
  • name=Edwardville Road
  • traffic_sign:2=ref_id
  • ref=CR 196
  • traffic_sign:id=US:xxx
  • traffic_sign:2:id=US:xxx

--Yopaseopor (talk) 22:42, 21 February 2024 (UTC)

@Kovposch: I agree. The solution I linked above is to map multiple nodes. Then there's no need for either numeric suffixes or semicolons. – Minh Nguyễn 💬 02:47, 19 February 2024 (UTC)
The reality is that multivalues exists for multiples traffic_signs when there are more than one. Tell me, how to handle this? With no semicolon, please. And no multinodes because you have only one pole to attach the traffic sign. Also here in Spain the validity of a traffic sign when there are more than one is for the traffic sign above, how to map this? Subkey with the order relations the properties with each one. --Yopaseopor (talk) 19:30, 19 February 2024 (UTC)
As I said, you need to give some examples to show why number suffix is necessary and preferrable. The pole is only a matter of convenience. Physically, the sign plates are precisely at different positions. There's no lack of basis in reality for this method.
What about different signs above each lane? Different sign diagrams can span over multiple different lanes. Number suffix doesn't scale, and won't mix well.
—— Kovposch (talk) 10:51, 20 February 2024 (UTC)
Probably there would be different sign diagrams over different lanes...but you have only one road. You can use it as the traffic signs were located from left to right to up to down in a right-drive country.--Yopaseopor (talk) 22:45, 21 February 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

  • Left to right, top to bottom? 🤔
  • North, North, West, I-87, New York Thruway, I-287, Through, Through, Through, West, North, To, East, NY 59, CR 35A, New Jersey Parkway, NY 59, Left, Left, Through, Right, To, To, To, South, South, East, I-87, New York Thruway, I-287, Right, Right, Right

    North, North, West, I-87, New York Thruway, I-287, Through, Through, Through, West, North, To, East, NY 59, CR 35A, New Jersey Parkway, NY 59, Left, Left, Through, Right, To, To, To, South, South, East, I-87, New York Thruway, I-287, Right, Right, Right

  • 13'-3", 11'-5" right, 11'-5" left, object marker right, object marker left

    13'-3", 11'-5" right, 11'-5" left, object marker right, object marker left

  • 21'-0", 13'-7", 14'-4", No Parking, object marker right, object marker left

    21'-0", 13'-7", 14'-4", No Parking, object marker right, object marker left

  • GlasscockFarm County461 LineRoad, Burn Ban in Effect

    GlasscockFarm County461 LineRoad, Burn Ban in Effect

 – Minh Nguyễn 💬 23:18, 21 February 2024 (UTC)

Remember this proposal is to talk about traffic_sign for scalable categories (I only talk about possible examples, all of them have to be covered by a proposal), and this for the human-readable values, traffic_sign:id for the national id of the traffic sign, direction for the traffic sign , side for the traffic sign and position for the traffic sign. Other information you will see here is about possible examples about how to map it with all the complete scheme.

First:

I like so much that. If this proposal and others easier go on it is probably I can adapt and present once for destination signs (there are the traffic signs with most information) . In urban environments there will be more than three traffic signs in the same pole (one of the recommendations of Vienna Convention - no more than three to fix the attention of the driver) To make it possible I would map four nodes, one for each direction and then one last to go to the parkway. All are direction=forward and side=right PD: For me is so interesting the conversation about that you have in the Community Forum , this proposal would be the start of mapping all that ideas. Remember to know the direction you have to see what is the direction of the mapped way in OSM. If it is the same, direction=forward and side=right, if it is the opposite direction=backward and side=left.

Second:

three nodes one next to the other in the road.

  • traffic_sign=maxheight
  • traffic_sign:id=US:xxx
  • maxheight=11'5
  • traffic_sign:2=beacon
  • traffic_sign:2:id=US:xxx
  • side=left
  • direction=forward


  • traffic_sign=maxheight
  • traffic_sign:id=US:xxx
  • maxheight=13'3
  • side=up
  • direction=forward


  • traffic_sign=maxheight
  • traffic_sign:id=US:xxx
  • maxheight=11'5
  • traffic_sign:2=beacon
  • traffic_sign:2:id=US:xxx
  • side=right
  • direction=forward


And then just before the bridge the arrow of the curve like

  • traffic_sign=hazard
  • traffic_sign:id=US:xxx
  • hazard=beacon_curve
  • side=right
  • direction=backward


Third:

three nodes

  • traffic_sign=maxheight
  • traffic_sign:id=US:xxx
  • maxheight=13'7
  • traffic_sign:2=beacon
  • traffic_sign:2:id=US:xxx
  • side=left
  • direction=forward


  • traffic_sign=maxheight
  • traffic_sign:id=US:xxx
  • maxheight=21'
  • side=up
  • direction=forward


  • traffic_sign=maxheight
  • traffic_sign:id=US:xxx
  • maxheight=14'4
  • traffic_sign:2=beacon
  • traffic_sign:2:id=US:xxx
  • side=right
  • direction=forward


(Probably No parking is from other road next to the tunnel)

Fourth:

Two nodes in the road, one just before the other, without no big distance

  • traffic_sign=ref_id
  • traffic_sign:2=prohibitory
  • prohibitory=burn_ban
  • text=Burn ban in effect (or something like that)
  • traffic_sign:id=US:xxx
  • traffic_sign:2:id=US:xxx
  • side=right
  • direction=forward


And the other

  • traffic_sign=boundary
  • boundary=county
  • name=Glasscock
  • side=right
  • direction=forward
  • traffic_sign:id=US:xxx


2,3. Why do the striped Type 3 Object Markers for edges need to be number-suffixed? They aren't directly related to the sign above alone, but show the whole situation together or independently. That's not a good solution for solving 3D vertical positioning cf type=node , and no better than semicolon multival, or separate points. At the tunnel arc in 3, they are at different positions precisely.
—— Kovposch (talk) 06:02, 26 February 2024 (UTC)
Probably in your country is not necessary. In mine's and others it is and you can find it also in the inventory of Traffic signs in roads that depends by the Spanish Government, so it is important to think about it. And we map the positions of the signs precisely too. If you want to draw the tunnel and specify the maxheight, perfect, go on, but here we are talking about traffic signs, and this marks its position clearly. --Yopaseopor (talk) 23:12, 26 February 2024 (UTC)

4.1. It's inscription=* . Why is a random prohibitory=* needed? While it may be defined as a regulatory sign, it may be argued as not for road traffic, thus not exactly traffic_sign=prohibitory . —— Kovposch (talk) 06:02, 26 February 2024 (UTC)

Random? Well other proposals will do, but, tell how to describe a Burn Ban. Also I'm not agree. In my country it is. It is traffic_sign:id=ES:S900 , you can find it in the Spanish traffic law. --Yopaseopor (talk) 23:09, 22 February 2024 (UTC)


4.2. There's no boundary=county . It's boundary=administrative .
—— Kovposch (talk) 06:02, 26 February 2024 (UTC)

Remember there are examples that would be really covered by others proposals, so it is not the moment to make exist or not exist a way of map a boundary traffic sign. It is clear that is not a city_limit so we will have to find a solution for that in human-readable value. --Yopaseopor (talk) 23:09, 22 February 2024 (UTC)

I guess the meaning behind my gallery above wasn’t clear enough. These are all examples in which every physical sign corresponds to a separate sign code (except for the “Burn Ban” one). The route shields and arrow plaques have codes too, in the Marker category. Moreover, either the sign configuration doesn’t have a clear reading direction, or it has a clear reading direction that is not from left to right and top to bottom (as in the first example). This information is lost when attempting to map anything other than the physical locations of the signs. My assumption is that data consumers can usually perform linear referencing on their own based on the physical locations, and maybe we can come up with a tagging scheme to aid that process in ambiguous cases, similar to the idea behind is_sidepath=*. – Minh Nguyễn 💬 14:51, 1 April 2024 (UTC)

New vals lacking explanation

There is no detail and justification on the "new" traffic_sign=* . Many are not clear.


—— Kovposch (talk) 08:56, 17 February 2024 (UTC)

Well, as you can read in the community forum, when we have started the discussion to make possible a proposal I had to cut the aims of that. As we have one working group (hazard), other groups and proposals would come after that. Vocabulary is not important, but you can distinguish main groups (the same you are finding in traffic signs laws + some very used in OSM.)
Implicit. Because it is a category you can find in the traffic law of different countries. Traffic implicit signs (or end of restriction/prohibition signs) have different colors or a red line crossing all the traffic sign, and major number are in different part in the traffic laws of the countries. (Germany 278 to 282) (Spain R500 to R506) (Italy II.70 to IT_II.73)
Regulatory and restriction not appropiate. I don't know if they are not appropriate. In MUTCD index of Chapter 2B you can find the regulatory and restriction parts...with this specific name. Should we change the name of that because we are not capable of understand the difference between a node with traffic_sign than a relation type called in OSM restriction?
In the Highway code (UK) we can read "Signs giving orders". In the explanation you can find "Signs with red circles are mostly prohibitive" , not "are totally prohibitive", so we have to make sure we can cover all the "less non prohibitive" regulatory signs.
But it is not a big problem. As I have said in the forum discussion further proposals will develop all these human readable traffic signs new values. Then we will discuss if it should be regulatory, mandatory, restriction, reglamentation, exactly... Vocabulary is not the main aim for this proposal. This is only a start to be able to do so as now traffic_sign= can cover national id's. The idea is traffic_sign for human readable values (with main categories whatever name they have and traffic_sign:id=* for national id of every traffic sign as national traffic law specifies it.)
traffic_signs=lanes can be misunderstood. No. This is exactly what it means: traffic signs about lanes . Destination is one thing it works so well in OSM. And number of lanes , or turn lanes too so it is a good option to name it as is. Traffic signs about the lanes. In France you will find almost 20 different traffic signs about that.
Services. As you will find in this same page one of the worries is with information topic. Well, services would be one good alternative because you would find all the "information" for services you will find in a road, also cultural, natural...
Complementary. Sorry for my bad English. I don't know what is the exact word but I'm sure taginfo and the other mappers will find it. A new proposal can be developed. Hazard vs warning? You have in OSM an approved proposal calling warning traffic signs as hazard traffic signs. It is not my fault.
Too specific, too vague... So it is perfect because if it is too specific but also too vague is in the middle, isn't it? I have choosen ref_id because route can have other meanings in collision with destination, etc. These traffic signs covers all the IDentification of every road, the plaques with the ref, etc.
Boundary. To be unclear you have mentioned one of the uses you can afford with that so you have understood its possibilities. Here in Spain we are in the implementation of this. Also you can include inside this all the traffic signs specifying you are entering or exiting from a place, natural reserve. We can discuss if the boundaries of a city would enter here, but like the give way and stop, city_limit accomplishes very well it's mission. But what about the county? the comarque? the province? Or is it better make something like traffic_sign=city_limit city_limit=province ? --Yopaseopor (talk) 21:50, 17 February 2024 (UTC)
What I want to say foremost is you should explain all these in the proposal, not only here. Not every one will read every topic. Even a few words is better than nothing.

—— Kovposch (talk) 23:35, 18 February 2024 (UTC)
  • Few words is better than nothing. I have wrote some words about the main categories. The proposal does not deal with each category you can need and invent. There are the most mentioned in traffic laws around the World and then there are the most used in OSM (consulting taginfo). Each category should be "unfolded" by a proposal as hazard did. Implicit is a category in Spain, Germany and Italy, for example. The colors and the pictures are similar. Should we don't consider that?
  • I don't understand what you are reading. Well you can't understand it...but you can read it in MUTCD 2B chapter. Find it (restriction 29 times, I think) (regulatory 53) (prohibitory 1). MUTCD talks about it with this words. As the case with warning/hazard you can develop a proposal with traffic_sign=prohibitory without any problem (I have mentioned it also). Proposal does not close the use of other categories in the future. Why can't use traffic_sign=regulatory with MUTCD ?
  • What are you proposing for turn restrictions? This proposal does not talk about the values INSIDE the categories for human readable values. This should be done in other proposal as hazard did. But if you asking me, the idea is using an scalable scheme so you have traffic_sign=restriction restriction=values used in OSM for restriction in turn restriction relations. The aim of this proposal is using existing values in OSM. There will be not error as one is a relation and other is a node with the tag traffic_sign=* inside it.
  • Informatory. Informatory does not exist in taginfo. Information exists with one million items. The intention is to use the existing keys and values and vocabulary in OSM. So there are some values that does not have the same type of word because they are used in OSM like information o restriction.
  • traffic_sign=lanes : In some countries there are traffic signs about turn: lanes, yes but also in France or Czech Republic preferably in motorways you have indications about what number of lanes or what lane it is merging with it? Think about it , in OSM we have some tags with lanes that covers these situations. This category covers the traffic signs are using these cases.
  • traffic_sign=services .Because it is not a destination. When you refer a destination:symbol probably you are thinking of a destination panel with some signs. I'm not referring that. You will have a lot of traffic signs with some services (amenities we call it in OSM) The services are ahead, next to the road with no other destination that the service itself. (example DK's M category)
  • traffic_sign=ref_id : No, if you are in xxx ref you are not going to a specific destination, you are in the road with this ref. It is the ref itself...so to avoid confusion with the id reference can have a traffic sign for other administrations or the people who make traffic signs (or the national id, aim of this proposal too) I have named ref_id.
--Yopaseopor (talk) 23:24, 19 February 2024 (UTC)
If you won't explain them, and don't plan to deal with them, why are you mentioning them? They don't need to be part of the proposals then.
  • Are you serious, reasoning based on a find count? If you have actually read it, "restriction" is only used as an explanation, except "Section 2B.49 Emergency Restriction Signs (R8-4, R8-7, R8-8)". It's not a sign category.
    • traffic_sign=regulatory : The question is why shouldn't they be categorized by OSM. This doesn't explain what the sign means, only the legal power.
    • traffic_sign=restriction : You are already mixing both categories and each function for other signs. Even if you aren't deciding what to use for turning movements, you need to consider the implication of using traffic_sign=restriction as a category, which is how it will cause complication on turn restrictions.
  • traffic_sign=information : You are conflating information=* and informatory signs. There are only 59 TagInfo traffic_sign=information . tourism=information isn't directly related to traffic_sign=* on roads. It should not be used as the category, as they are different. Again, this is something you should explain in the proposal. "New" doesn't make people understand whether you created it now, or it has already been used somehow. They have no responsibility to check this. Same with TagInfo traffic_sign=regulatory , while there's only a hundred.
  • traffic_sign=lanes  : lanes=* is about the number of lanes. Merging layout can still be traffic_sign=turn , because it is the same as the turn:lanes=* downstream on the merging section. If you use traffic_sign=lanes for turn:lanes=* , this also risks confusion with destination:lanes=* for what to use, and different access:*:lanes=* modal lane use.
  • traffic_sign=services : They are still destination:symbol=* ? Do you know it's used?
  • traffic_sign=ref_id : My question is what collision exist for traffic_sign=route ? "Id" is still meaningless. Furthermore, traffic_sign=route can express more than exactly the ref=* alone . A ref=* may be a number without showing even CR Country Route or SR State Route, but the shield or text shows what state or county it is.

—— Kovposch (talk) 10:34, 20 February 2024 (UTC)
This proposal surges because of one discussion about tagging many years ago. After 7 years "hibernated" all the controversy about the necessity of human readable values makes obligatory explain how to map before elaborate more than 200 new key=values (with hazard you can find 30 in only one accepted proposal). In some messages the idea it was making a proposal with ALL the human-readable values. Impossible. Then they demand me some examples and I have done that.
It is clear that after this proposal would be accepted other proposals should develop all the scheme for categories and human-readable values. Without the first it has nonsense the second for me because probably we have what to map but not how to map it. --Yopaseopor (talk) 23:00, 21 February 2024 (UTC)

Regulatory vs advisory

traffic_sign=maxspeed:advisory mixes poorly in this system. I assume traffic_sign=mandatory etc are unspecified fallbacks. But what about access=discouraged , is it traffic_sign=access or traffic_sign=access:advisory ??? There would be more traffic_sign=*:advisory needed, eg maxheight:advisory=* for overhead lines at train or tram at-grade crossings in UK. I don't find it scalable.
—— Kovposch (talk) 09:19, 17 February 2024 (UTC)

We have traffic_sign=maxspeed, also we have traffic_sign=minspeed. So why we can't have traffic_sign=maxspeed:advisory if these traffic signs exists? Should we tag traffic_sign=maxspeed maxspeed=minspeed with the minspeed value on maxspeed??
About access=discouraged as it's key identifies it is for access. I know in some countries would be advisory or mandatory... so should we tag traffic_sign=mandatory mandatory=advisory advisory=access access=discouraged or we can tag with only one category, the same you have tagged in OSM (access) ?
A maxheight is not advisory, is prohibitory because if you pass with more than the maxheight you will have some problems. Remember https://11foot8.com ?
Maxspeed is one, maxspeed:advisory is other, preferibly slower.--Yopaseopor (talk) 22:05, 17 February 2024 (UTC)
@Kovposch and Yopaseopor: In the U.S., Low Clearance Ahead and Low Clearance Overhead are considered warning signs, because ignoring the restriction inherently causes the can-opener effect you refer to, and an associated fine for destruction of property; there's no need for separate regulatory enforcement. It's the same reason a Dead End sign doesn't need to be a regulatory sign. On the other hand, some other jurisdictions like Mexico and Australia consider them to be regulatory signs. The Netherlands has both prohibitory and informational signs about vertical clearance. – Minh Nguyễn 💬 22:31, 18 February 2024 (UTC)
The definition of the category should be chosen for the traffic law in every country if there is a conflict with that. When you read the law it specifies if it is warning (hazard in OSM) or regulatory or informational.--Yopaseopor (talk) 22:37, 18 February 2024 (UTC)
What comparison is this? Actually I retract that. If *:advisory=* always appear with hazard=* , then it doesn't need a traffic_sign=* . traffic_sign=hazard + hazard=* + *:advisory=* is sufficient. Continue in Number suffix unbalanced rationale and usefulness for this problem.
—— Kovposch (talk) 23:44, 18 February 2024 (UTC)

Commenecement vs repeater vs end, zones, sectional

Further to traffic_sign=implicit vs traffic_sign=maxspeed + maxspeed=implicit , there is a need to distinguish start of eg a speed limit, a speed limit being repeated, and the end of a speed limit with commencement of the national speed limit. Other use case include overtaking, route, road class (highway=motorway , motorroad=* ) or pedestrian priority signs (for highway=living_street / living_street=yes .
This is besides zones. There are also sectional sign for a specified distance, for no u-turn, and warning signs, on a length of road. Parking and stopping restrictions too.
An interfacing problem is the end can either be specified on one sign, or be shown on a supplementary plate.
—— Kovposch (talk) 09:24, 17 February 2024 (UTC)

If you have a category called implicit it is easy to distinguish the end of a speed limit and the start of the speed limit. With a second plaque called complementary you have a traffic sign that reminds (RAPPEL / RECUERDE) you this speed limit.
With overtaking you have the same.
All the sectional signs have their category, some are maxspeed, some are mandatory, some are hazard...
Supplementary plates... are traffic signs itselves so you need the second or third position traffic_sign:2/3 and traffic_sign:2/3:id --Yopaseopor (talk) 22:42, 17 February 2024 (UTC)
UK repeaters do not have an equivalent of the Rappel plate. They are physically smaller than the signs marking changes of speed limit. Davidpnewton (talk) 12:08, 25 February 2024 (UTC)
Probably you don't have a complementary traffic sign called Remember...but you have much others, so it is necessary to mark each position of each traffic sign if you map it all together. --Yopaseopor (talk) 23:38, 26 February 2024 (UTC)

Mode and suffixes

traffic_sign=overtaking:hgv should not be used simply because it looks different. It's still traffic_sign=overtaking + overtaking:hgv=no . The assembly is already expressed by traffic_sign:id=* . traffic_sign=* doesn't need to be visually the same. This is the same logic as traffic_sign=access .
—— Kovposch (talk) 14:36, 17 February 2024 (UTC)

Probably you have reason in overtaking:hgv case and I can think about that. For access I see it different because as the access key does not cover all the keys you use (one for "type of vehicle") it is complicated to make it scalable without this specification.--Yopaseopor (talk) 22:16, 17 February 2024 (UTC)

Top grey Infobox content

I would propose to add all to new key/tag inventions of the proposal to the top grey infobox of ({{Proposal Page}}). The parameter "tagging" allows more then one key/tag, e.g. see example: |tagging={{Tag|amenity|charging_station}}<br>{{Tag|man_made|charge_point}} on: Proposal:EV_Charging_Station_Mapping --MalgiK (talk) 22:14, 28 February 2024 (UTC)

I added traffic_sign:id to the proposal infobox. Other tags nowadays exists, it is not a big change, other category tags are examples to see how it works. Each category should be sustained by a proposal. --Yopaseopor (talk) 23:22, 28 February 2024 (UTC)
Thank you--MalgiK (talk) 11:35, 3 March 2024 (UTC)

Proposal target

Do i read the proposal correct? It only effects to updating tags of one of the three current mapping ways. So changes only take place for 1.1.2.2 Node in a way items? --MalgiK (talk) 22:22, 28 February 2024 (UTC)

Well, some parts of this proposal are only applicable to a node on a way (so I focus in that because I think is the most complete, other methods are not in this proposal). If you map as a way does not have any sense to define the "side",but the location of the traffic sign itself is not very exact and the partitions of ways will be complicated if you want all the traffic signs. If you map as node in real place, outside the way, you don't need side too (but probably you will need a relation to mark in what point has effect this traffic sign in that way (other possible proposal I'm not in-) . However you can use traffic_sign to categories and human_readable values and traffic_sign:id for the national id of every traffic sign and the relative position of that can be used by every method of mapping traffic signs, not only node on a way. --Yopaseopor (talk) 23:18, 28 February 2024 (UTC)

maxspeed:forward (node/way) definition

When looking to the current database status, it seems maxspeed:forward=* has a kind of "de facto" status for way elements. In your proposal I can find maxspeed:forward=* only under Proposal:Extended_traffic_signs_tagging#Final_example final example which then would apply for nodes?--MalgiK (talk) 11:59, 3 March 2024 (UTC)

As I have written above "Each category should be sustained by a proposal", so all you can have here are examples that should be discussed after a proposal if this is approved. But I have changed the example to avoid this discussion. Remember this proposal is about traffic_sign:id for the specific picture with the national id of the traffic_sign, traffic_sign for categories, categories for human-readable values , with a scalable scheme (not which categories and which human-readable values), direction, side and position. Thank you for your advices. PD: having direction in the same item would not be big problem to use maxspeed only, without subkey, you will have the same information. --Yopaseopor (talk) 21:08, 6 March 2024 (UTC)

As a navigation aid for the visual impaired

It is simple and effective to determine the position of various key points of interest such as intersections or possibly as an anchor to find other related amenities nearby to use your probing cane to locate the post of traffic signs (advertising boards, street lamps, etc). This can be especially useful when the map clearly indicates that two such poles are within arm's reach within each other as a combination, or if certain properties are micromapped on each post (such as: surface finish, diameter, material, profile - circular, square or rectangular). To make this work properly, each sign should be added to the precise position it occurs at, not in the middle of the road or even shifted slightly to align with markings painted on the road! Maybe this is not the proposal to fix this, but I highly recommend someone in this sphere give it a go. Bkil (talk) 10:25, 1 April 2024 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Extended_traffic_signs_tagging&oldid=2740026"