Proposal:Extended traffic signs tagging
| Extended traffic signs tagging | |
|---|---|
| Proposal status: | Rejected (inactive) |
| Proposed by: | yopaseopor |
| Tagging: | traffic_sign=* traffic_sign:id=* |
| Applies to: | 
|
| Definition: | An extended and advanced scheme to tag all kind of traffic signs |
| Draft started: | 2017-02-05 |
| RFC start: | 2024-02-17 |
| Vote start: | 2024-04-01 |
| Vote end: | 2024-04-15 |
Voting is cancelled
First of all, thank you for all the community who finally has decided to vote to approve or opposite and comment all the proposal and all the possible errors. Perhaps all the rounds of comments were not productive or positive (specially last week of RFC) but from my point of view the job was done (every message there had be answered, and some parts of the proposal were changed). It is sad to have to arrive to this moment but I try to see in a positive way and the part of "why not" is working. So thank you very much to the ideas for remaking the proposal. Tonight I will stop the vote for this proposal, due to it is complicated to be approved in that way , with that numbers. So, next days I will redo the proposal and start the RFC part. I will be clear: I want a consensus proposal to make possible the mapping of traffic signs with the major information in the easiest and massive way.
Rationale
Traffic signs are one of the most important kind of elements you can find... in the "road world". They are extended all over the world and there are so many kinds of them. But it was a minor tag in OSM (few elements, few tags related, few values...until now). It is important to structure a complete scheme which answers all the meanings of a traffic sign, not only the meaning for the road but also the element itself.
Present:Different approaches
By key
Highway.The classics
In 2006 we can find the first traffic sign tag, stop, with its main key, highway. From then there's an approximation with nodes with the same key: highway=give_way, highway=traffic_signals, and highway=stop.
| Value | Element | Sign | Comment | Additional tags on the way |
|---|---|---|---|---|
| highway=stop |
|
|
Stop sign. Usually tagged as highway=stop instead. Text of the wiki has changed so the proposal is based on this version | highway=stop (on a node) |
| highway=give_way |
|
|
Give way sign. Usually tagged as highway=give_way instead. | highway=give_way (on a node) |
| highway=traffic_signals |
|
Traffic signal. | highway=traffic_signals (on a node) |
Human-readable values
| Tags | Element | Sign | Comment | Tags for affected highways | |
|---|---|---|---|---|---|
| traffic_sign=city_limit +
name=* (name of city/village) |
|
|
|
City/village sign. By default it is assumed there is an end of city/village sign on the back for drivers in the opposite direction; add city_limit=begin if this is not the case. | source:maxspeed=DE:urban if not overridden by other speed limit source (or with other appropriate country code)
zone:traffic=DE:urban |
| traffic_sign=city_limit +
name=* (name of city/village) |
|
|
|
End of city/village sign. | source:maxspeed=DE:rural if not overridden by other speed limit source (or with other appropriate country code) |
| traffic_sign=maxspeed +
maxspeed=* (the speed limit) |
|
|
.svg)
|
Maximum speed sign. Like all traffic signs these should be tagged as a node. Usually not part of the highway, so the direction can be inferred. | maxspeed=* + source:maxspeed=sign |
| traffic_sign=maxspeed + |
|
|
|
End of maximum speed sign. | |
| traffic_sign=stop |
|
|
Stop sign. Usually tagged implicitly on a node of the highway with highway=stop instead. Text of the wiki has changed so the proposal is based on this version | highway=stop (on a node) | |
| traffic_sign=give_way |
|
|
Give way sign. Equivalent to the United States yield sign. Usually just highway=give_way is tagged instead. | highway=give_way (on a node) | |
| traffic_sign=variable_message |
|
|
Electronic Variable Message Sign, also known as Dynamic Message Signs. Remotely programmed to give traffic information such as expected travel times to destinations, temporary speed limits, incident warnings etc. Usually combined with man_made=gantry. (Example photo) | ||
| traffic_sign=overtaking + | 
|
|
|
No overtaking sign. | overtaking=no |
| traffic_sign=overtaking + |
|
|
|
End of no overtaking sign. | |
| traffic_sign=maxwidth |
|
|
Maximum width sign. | maxwidth=* | |
| traffic_sign=maxheight |
|
|
Maximum height sign. | maxheight=* | |
| traffic_sign=maxweight |
|
|
Maximum weight sign. | maxweight=* | |
| traffic_sign=stop_ahead |
|
|
|
Stop ahead sign. Can be a standard yield sign plus additional plate containing STOP and distance (as in most of Europe) or a red triangle or yellow diamond with an image of a stop sign elsewhere. | |
| traffic_sign=yield_ahead |
|
|
|
Yield/give way ahead sign. Can be a standard yield sign plus additional plate with distance (as in most of Europe) or a red triangle or yellow diamond with an image of a yield/give way sign elsewhere. | |
| traffic_sign=signal_ahead |
|
|
|
Signal ahead sign. | |
| traffic_sign=hazard |
|
|
|
A hazard to motorists. | Combined with hazard=* to indicate the type of hazard. |
Traffic signs by national ID
Signs specific to a particular country should be mapped by the country/region prefix followed by a colon and then the traffic sign.
- The country/region prefix should be the
ISO 3166-1 alpha-2 country code or ISO 3166-2 country subdivision code (always uppercase). This prefix is separated by a colon :from the sign. Additional colons can be included within the prefix to create a hierarchy of further custom subdivisions. - Traffic signs should be represented by their official ID (if such IDs are assigned).
- Multiple unrelated signs should be separated with a semicolon
;. If traffic signs are related, the additional sign IDs should be separated from the main sign by comma,. - Where the traffic sign requires a numeric or textual value, you can supply it after the ID using brackets
[value]. This can be repeated for signs that require multiple parameters. For numeric parameters, use a dot.as decimal separator and a minus-for negative values (if needed). - In case of multiple signs separated by commas or semicolons, the prefix should appear only once at the beginning (except if signs from different prefixes are combined).
Examples
|
traffic_sign=GB:956 |
 
|
traffic_sign=GB:616,954 |
|
traffic_sign=GB:523.1[-10] |
|
traffic_sign=BE:F4a |
 ,_StVO_1992.svg){kind=small} ;_StVO_1992.svg)
|
traffic_sign=DE:260,1020-30;265[3.8] |
|
traffic_sign=US:CA:SW-59 |
_tweetalig_plaatsnaambord_cropped.JPG) 
|
traffic_sign=NL:H01d[Merum][Maerem][Roermond];A0150 |
Here it is a table with most of them Key:traffic sign#Lists of IDs per country
By way of mapping them
Also there are three ways of mapping them: as a separated node, as part of way or on a way. Numbers says except highway=stop and highway=give_way there are three methods of mapping. Each of them has its own numbers (more or less 50% - 50%) so there is not a majority method of doing that.
On a way or area
When tagged on a way or an area, the traffic_sign=* tag describes the traffic sign(s) that apply to that way or area. The tag is not meant to mark the actual position of the sign in this case, but the affected way or area instead. It should however be assumed that the physical location of the sign is at the beginning and / or the end of the affected section (but note that the affected section may be comprised of multiple ways within OSM). It would be difficult to know where is the traffic sign itself.
Separated node
Create a separate node beside the road at the position of the actual sign. This allows to map the exact physical position of the sign, but it is impossible to reliably deduce the affected road or travel direction in this case. Software algorithms which operate on ways will thus generally not be able to consider the traffic sign, but only the tags of the way instead. Probably you will need a relation to unite the way with the node like highway=speed_camera and the relations of enforcement.
You can use the direction=* tag to describe the facing orientation of the sign by using an angle or cardinal direction.
Note that the sign is facing against the direction of travel. So if you encounter a traffic sign when traveling north, then the sign is facing south. So you can add direction=180 or direction=S. Likewise, when traveling west, signs are facing east, so you tag them with direction=90 or direction=E.
Node in a way
As a part of the way you can use the direction=* with the values direction=forward, direction=backward, direction=90 direction=270 , to show the direction the same it is the way inside in. It is easy for renders to assume being part of the way traffic signs affect that way but it is difficult to assume the exact position of the traffic sign.
Conclusion: node in a way
There are two different keys and three ways of mapping traffic signs. It is complicated for a newbie mapper to know how to map the possible different values and their order. Every code has its place. And mapping direction is not easier, when you have a node alone you need to put the facing direction or the cardinal direction. This proposal is about node in a way because it is the method you can have better information with extended mapping with less complexity. It is true that when you have the node in a way you have to put forward or backward relative to the way it is. But others alone would need a relation with the way they are near to work entirely with all the information like speed camera (if you want the direction relative it is), and mapping properties in a way it is not to map "A clearly visible object, generally flat, bearing a short message in words or pictures".
Aim of this proposal
The aim of this new scheme for traffic_signs is to unite the different approaches for mapping traffic sign as it is. It uses the most complete parts of the existing schemes. It uses the "categories" you can find in traffic signs law from Europe or US, like hazard with a node per traffic sign and with a human readable value,using existing OSM tags to his when possible and marking the position with a numbered subtag :2 or :3...This avoid misinterpretation errors from the tags and also the multi-value problems. Also permits the correspondence between some tags each other. And to be more specific you can use the tag traffic_sign:id=* to specify the code of this traffic sign per country if you know the value. It uses the traffic ID national code you can find in the traffic sign law of each country to mark which traffic sign is and also gives the entire importance as states do in their laws (we know it because when you ask a government e.g. Spanish government, for the database of traffic signs in their roads each traffic sign has a unique ID with its position and code.) There are so convenience to not fit more than three traffic signs at the same pole to make easier the readability for human eye at the reality. This proposal does not deprecate any method but establishes a scheme how you can map a traffic sign in a more specific mapping method.
This proposal establishes:
- 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
- position
-Other existing things will not change (the tagging of highway=stop and highway=give_way is so massive and so controversial than it does not fit in this proposal).
How it works. How to map
The mapping method is a node part of the way using human-readable values (more of them used in OSM), the possibility of specify the national id for every traffic sign (to get the exact picture) , and explaining its direction and side relative to the way. Also it mention its position if there is more than one together.
- First you say the type of the traffic sign with human-readable categories and values. Here it is some examples of approximation of readable values and "subkeys" applied to the traffic_sign key (in this proposal we NOT propose any value or category, all of them will be proposed in others proposals, here I'm only propose the way of mapping traffic signs). : 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 (no changes for present situation, I mean).
- Then you apply the subkey for this type (as hazard).
- Do you know the id of the traffic sign in its country? Use traffic_sign:id=* (new). The country/region prefix should be the ISO 3166-1 alpha-2 country code or ISO 3166-2 country subdivision code (always uppercase). This prefix is separated by a colon
:from the sign. Additional colons can be included within the prefix to create a hierarchy of further custom subdivisions. Then it should be represented by their official ID (if such IDs are assigned).
Position
When there is a second traffic sign you use the subtag 2: to traffic_sign=* tag and/or traffic_sign:id=* so on
(e.g. traffic_sign:2=maxspeed and/or traffic_sign:2:id=DE:206).
Direction
The mapping method is a node , mainly part of the way, using the values explaining its direction relative to the way. Here there are the possible directions.
| Tag=value | Comment |
|---|---|
| direction=forward | Forward to the way. It is relative to the orientation you draw a way, as rivers |
| direction=backward | Backward to the way. It is relative to the orientation you draw a way, as rivers |
| direction=90 (clockwise) | 90º to the way. It is relative to the orientation you draw a way, as rivers |
| direction=270 (clockwise) | 270º to the way. It is relative to the orientation you draw a way, as rivers |
| direction=* (clockwise) | other directions relative to the way |
Side
It is completed with a tag side that marks the side of the way traffic sign is in if you use the direction you say it before.
| Tag=value | Comment |
|---|---|
| side=right | the right side of the way . It is relative to the orientation you draw a way, as rivers |
| side=left | the left side of the way. |
| side=both | the left and right sides at the same time. |
| side=up | all elevated traffic signs or traffic panels. |
| side=down | all traffic road marks. |
Final example
Here we have a final example. Let's remember the steps:
- 1- 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 (no changes for present situation, I mean).
- 2-Apply the subkey for this type (as hazard).
- 2B-If you know the national id for this traffic sign use traffic_sign:id=* (new)
- 3-Direction relative to the way: direction=forward, direction=backward, direction=90 direction=270 .
- 4-Side of the way the sign is located.
- 4B If there is a second traffic sign you might use the subtag 2: to traffic_sign tag and traffic_sign:id or whatever can exist conflict
e.g.:
See also
Examples of possible traffic signs human readable values
If this proposal is accepted, then there will be other specific proposals about the specific human-readable values and its categories (following national traffic laws and most OSM used values)
| Tag=value | Comment |
|---|---|
| highway=traffic_signals | Traffic signal. |
| highway=stop | Stop sign. Usually tagged implicitly on a node of the highway with highway=stop to unify all the human readable values for this. Left as present situation. This proposal does not touch this value. Text of the wiki has changed so the proposal is based on this version |
| highway=give_way | Give way sign. Usually tagged as highway=give_way to unify all the human readable values for this. Left as present situation. This proposal does not touch this value. |
| traffic_sign=hazard | A hazard is a potential source of damage to health, life, property, or any other interest of value (see Hazard). Hazards include natural features of the environment as well as those of human origin. |
| traffic_sign=maxspeed
traffic_sign=maxspeed:advisory traffic_sign=implicit (new) traffic_sign=access (new) traffic_sign=regulatory(new) traffic_sign=restriction(new) traffic_sign=mandatory (new) |
These signs marks the regulation. They can be prohibitive, mainly give a positive (mandatory) instruction ,mainly give a positive advisory instruction, can mark the end of that prohibition. And also here you have all the restrictions of max* or min*. |
| traffic_sign=information (new)
traffic_sign=lanes (new) traffic_sign=services (new) |
Here you have all the signs you can find about information instructions. |
| traffic_sign=complementary(new) | These are all the signs that accompany all the other traffic signs to clarify or adjust the meaning or the situation that applies the main traffic sign. |
| traffic_sign=destination (new)
traffic_sign=ref_id (new) traffic_sign=boundary(new) |
All the traffic signs about orientation, destination and confirmation. Not only the plate itself. |
| traffic_sign=* | All common values according to taginfo. |
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 (new)).
One category exists. A good start. Traffic_sign=hazard
Due to the approval of hazard in 2020 there were born the first category for traffic signs as it. Hazard (the initial version of this proposal was talking about warning traffic signs.As you can see in this table all Vienna convention and MUTCD has similar items to specify these situations. It is interesting to use existent tagging in OSM so probably would not have any big change rather than some new proposals of human readable values.
In this other table you will see image of the two main styles of pictures Worldwide accepted: Vienna convention and MUTCD. They can change a little by countries but they are similar. Then you have the national id for some traffic signs as an example.
| Key | Human readable value | Usage count | Element | Description | traffic_sign:id
Vienna |
traffic_sign:id
MUTCD |
|---|---|---|---|---|---|---|
| hazard | damaged_road |  
|
A section of damaged road where it is recommended to reduce speed | 
ES:P15 DE:112 |
CO:SP-24 | |
| hazard | traffic_signals |
|
A section of road approaching near traffic lights where it is recommended to reduce speed | 
ES:P3 DE:131 |
US:W3-3 CO:SP-23 | |
| hazard | animal_crossing |
|
A place where animals are known to appear unexpectedly, presenting a collision hazard to motorists. | 
ES:P24 DE:142-20 |
US:W11-3 (deer) US:W11-4 (cows) US:W11-16 (bears) US:W11-17 (sheep) US:W11-18 (bighorn sheep) US:W11-19 (donkeys) US:W11-20 (elk) US:W11-21 (moose) US:W11-22 (wild horses) | |
| hazard | bump |
|
A bump in the road which may be hazardous to motorists. | 
ES:P15a |
US:W8-1 CO:SP-25A | |
| hazard | crossroad |
|
Crossing of two roads. | 
ES:P2 DE:102 |
 
traffic_sign:id=US:R1-1 traffic_sign:2:id=US:W4-4P traffic_sign=US:R1-2 traffic_sign:2:id=US:W4-4P US:W2-11 CO:SP-11 | |
| hazard | children |
|
A place where children are known to play in the roadway, presenting a collision hazard to children and motorists. | 
ES:P21 DE:136-10 |
| |
| hazard | cyclist |
|
An area where cyclists share a roadway with motor vehicles | 
ES:P22 DE:138-10 |
 
traffic_sign:id=US:W11-1 traffic_sign:2:id=US:W16-1P traffic_sign:id=US:W11-1 traffic_sign:2:id=W16-1aP CO:SP-59 | |
| hazard | dangerous_junction |
|
A junction or intersection that has a high rate of traffic collisions. | 
US:W1-7 US:W1-10L US:W1-10R US:W1-10aL US:W1-10aR US:W1-10bL US:W1-10bR US:W1-10cL US:W1-10cR US:W1-10dL US:W1-10dR US:W1-10eL US:W1-10eR US:W2-1 US:W2-2L US:W2-2R US:W2-3L US:W2-3R US:W2-3aL US:W2-3aR US:W2-4 US:W2-5 US:W2-7L US:W2-7R US:W2-8L US:W2-8R US:W10-2L US:W10-2R US:W10-3L US:W10-3R US:W10-4L US:W10-4R | ||
| hazard | dip |
|
A dip in the road which may be hazardous to motorists. | 
ES:P15b |
US:W8-2 CO:SP-26 | |
| hazard | emergency_vehicles |
|
A section of road approaching near a intersection with road for emergency vehicles where it is recommended to reduce speed. | 
|
US:W11-8 CO:SP-72 | |
| hazard | falling_rocks |
|
An area in which rocks, dirt, or other natural materials may fall unexpectedly from cliffs above, or may have fallen, presenting a hazard. | 
ES:P26 DE:101-25 |
US:W8-14 CO:SP-42 | |
| hazard | fog |
|
An area where fog tends to form more frequently than surrounding areas. | 
ES:P33 |
US:W8-22 | |
| hazard | frail_pedestrians |
|
A place where frail or disabled pedestrians are likely to cross a road |
ES:P21b |
US:W11-9 | |
| hazard | frost_heave |
|
An area where the road is known to bulge because of ice underneath the roadway. |
|
||
| hazard | ground_clearance |
|
A place (usually a hill or incline) where vehicles with long wheelbases risk being grounded. |
|
 
US:W10-5 traffic_sign:id=US:W10-5 traffic_sign:2:id=US:W10-5P | |
| hazard | horse_riders |
|
An area where horse riders share a roadway with motor vehicles. |
DE:101-13 |
traffic_sign:id=US:W11-7 traffic_sign:2:id=US:W16-1P traffic_sign:id=US:W11-7 traffic_sign:2:id=US:W16-1aP | |
| hazard | ice |
|
An area where ice tends to form more frequently than surrounding areas. | 
ES:P34 DE:101-51 |
traffic_sign:id=US:W8-5 traffic_sign:2:id=US:W8-5aP
US:W8-13 (on bridges only) | |
| hazard | landslide |
|
An area where landslides, mudslides or rockslides are known to occur. |
ES:P26 DE:101-15 |
US:W8-14 CO:SP-42 | |
| hazard | loose_gravel |
|
An area along the road where rocks and stones may be present, presenting a hazard to motorists. | 
ES:P28 DE:101-52 |
US:W8-7 CO:SP-71 | |
| hazard | low_flying_aircraft |
|
An area where low flying aircraft are known to appear. | 
ES:P12 DE:101-20 |
||
| hazard | pedestrians |
|
An area where pedestrians share a roadway with motor vehicles | 
ES:P20 DE:133-10 |
 
traffic_sign:id=US:W11-2 traffic_sign:2:id=W16-1P traffic_sign:id=US:W11-2 traffic_sign:2:id=W16-1aP CO:SP-46 | |
| hazard | queues_likely |
|
An area which frequently experiences a queue of cars backed up on the roadway | 
ES:P31 DE:124 |
US:W3-4 (due to traffic signals) US:W3-6 (due to drawbridge) US:W26-1 | |
| hazard | road_narrows |
|
A place where the road narrows immediately following the sign. | 
ES:P17 DE:120 |
US:W5-1 CO:SP-28 | |
| hazard | roundabout |
|
A section of road approaching near a roundabout where it is recommended to reduce speed. | 
ES:P4 |
US:W2-6 CO:SP-20 | |
| hazard | school_zone |
|
An area near a school where special traffic laws apply. |
ES:P21 DE:136-10 |
US:S1-1 CO:SP-47 | |
| hazard | side_winds |
|
An area which frequently receives high winds that present a danger to people. | 
ES:P29 DE:117-20 |
US:W8-21 CO:SP-73 | |
| hazard | slippery |
|
An area or stretch of roadway which is slippery, or slippery under certain conditions, presenting a hazard to motorists | 
ES:P19 DE:114 |
US:W8-5 CO:SP-44 | |
| hazard | curve |
|
A section of road which presents a risk to motorists due to a single curve. | 
ES:P13a DE:103-20 |
US:W1-2L US:W1-2R US:W1-8L US:W1-8R US:W1-10 US:W1-10aL US:W1-10aR US:W1-10bL US:W1-10bR US:W1-10cL US:W1-10cR US:W1-11L US:W1-11R US:W1-15 CO:SP-03 | |
| hazard | curves |
|
A section of road which presents a risk to motorists due to multiple curves. | 
ES:P14a DE:105-20 |
US:W1-4L US:W1-4R US:W1-4bL (2 lanes) US:W1-4bR (2 lanes) US:W1-4cL (3 lanes) US:W1-4cR (3 lanes) US:W1-5L US:W1-5R US:W1-10dL US:W1-10dR US:W1-10eL US:W1-10eR US:W24-1L US:W24-1R US:W24-1aL US:W24-1aR US:W24-1bL US:W24-1bR CO:SP-10 | |
| hazard | turn |
|
A section of road that turns sharply |
ES:P13a DE:103-20 |
US:W1-1L US:W1-1R US:W1-6L US:W1-6R US:W13-10 US:W13-11 CO:SP-02 | |
| hazard | turns |
|
A section of road that turns sharply two times, in opposite directions |
ES:P14a DE:105-20 |
US:W1-3L US:W1-3R CO:SP-05 |
Stop and give_way
| Key | Human readable value | Usage count | Element | Description | traffic_sign:id
Vienna |
traffic_sign:id
MUTCD |
|---|---|---|---|---|---|---|
| highway | stop |
|
A sign of stop. Text of the wiki has changed so the proposal is based on this version | 
ES:R2 DE:206 |
US:R1-1
US:R1-5bL US:R1-5bR US:R1-5cL US:R1-5cR US:R1-5eL US:R1-5eR US:R1-6a US:R1-6c US:R1-6e US:R1-9a US:R1-9c CO:SR-01 | |
| highway | give_way |
|
A sign of give_way / yield | 
ES:R2 DE:205 |
US:R1-2
US:R1-5L US:R1-5R US:R1-5aL US:R1-5aR US:R1-5dL US:R1-5dR US:R1-6 US:R1-6b US:R1-6d US:R1-7 US:R1-7a US:R1-9 US:R1-9b CO:SR-02 |
traffic_sign=max* ,min or advisory
| Key | Human readable value | Usage count | Element | Description | traffic_sign:id
Vienna |
traffic_sign:id
MUTCD |
|---|---|---|---|---|---|---|
| maxspeed |
|
A sign of maxspeed. Specifies the maximum legal speed limit on a road, railway or waterway. | 
ES:R301 CO:SR-30 DE:274 |
US:R2-1 US:R2-4a | ||
| maxspeed:advisory |
|
A sign of advisory maxspeed. Specifies the recomended speed limit on a road, railway or waterway. | 
ES:S7 |
US:W13-1P US:W13-1aP US:W13-2 US:W13-3 US:W13-6 US:W13-7 US:W13-8 US:W13-9 US:W13-10 US:W13-11 US:W13-12 US:W13-13 | ||
| minspeed |
|
A sign of minspeed. Specifies the minimum legal speed limit on a road, railway or waterway. | 
ES:R411 DE:275 |
US:R2-4P US:R2-4a | ||
| maxheight |
|
The legal maximum height | 
ES:R205 CO:SR-32 DE:265 |
US:W12-2 (ahead) US:W12-2a (overhead) | ||
| maxwidth |
|
The legal maximum width | 
ES:R204 CO:SR-33 DE:264 |
|||
| maxweight |
|
The legal maximum weight | 
ES:R204 CO:SR-31 DE:262 |
US:R12-1 US:R12-4 US:R12-5 US:R12-6 | ||
| maxaxleload |
|
The legal maximum axleload weight | 
ES:R202 DE:263 |
US:R12-2 US:R12-4 | ||
| maxlength |
|
The legal maximum length | 
ES:R203 DE:266 |
|||
| overtaking | no |
|
A sign of no overtaking | 
ES:R305 CO:SR-26 DE:276 |
US:R4-1
US:W14-3 | |
| overtaking:hgv | no |
|
A sign of no overtaking for HGV. | 
ES:R305 CO:SR-17 DE:277 |
Voting
- Log in to the wiki if you are not already logged in.
- Scroll down to voting and click 'Edit source'. Copy and paste the appropriate code from this table on its own line at the bottom of the text area:
| To get this output | you type | Description |
|---|---|---|
|
{{vote|yes}} --~~~~
|
Feel free to also explain why you support proposal. |
|
{{vote|no}} reason --~~~~
|
Replace reason with your reason(s) for voting no. |
|
{{vote|abstain}} comments --~~~~
|
If you don't want to vote but have comments. Replace comments with your comments. |
~~~~ automatically inserts your name and the current date.For full template documentation see Template:Vote. See also how vote outcome is processed.
I approve this proposal. --Davileci (talk) 00:36, 1 April 2024 (UTC)
I oppose this proposal. censored --SekeRob (talk) 05:33, 1 April 2024 (UTC)Doesn't add anything what can't be tagged already with ease in fact only complicates.
- When voting no, you must give a reason. --Westnordost (talk) 11:37, 1 April 2024 (UTC)
- I oppose this proposal. currently the proposal is lacking any concise documentation of what it actually changes (not to mention examples of changed tagging) making it impossible to determine what is being voted on. It might make sense, it might not, but there is no way to determine that. --SimonPoole (talk) 07:08, 1 April 2024 (UTC)
- I oppose this proposal. On the idea, I'm fine with traffic_sign:id=* , but not traffic_sign:#=* number suffix. On the execution, you have butch of "(new)" in Proposal:Extended_traffic_signs_tagging#Examples_of_possible_traffic_signs_human_readable_values that's confusing on whether you are proposing them, and there's a lack of actual examples showing why number suffix is needed. You didn't explain your consideration of alternatives, and justification of using number suffix in the proposal. —— Kovposch (talk) 07:34, 1 April 2024 (UTC)
- I oppose this proposal. The whole proposal is huge and doesn't describe well what needs to be changed. Most reasons given are assumptions that have been challenged in the discussions. --Mueschel (talk) 09:16, 1 April 2024 (UTC)
- I approve this proposal. This is an excellent and well documented proposal. It is clear that there has been lots of work and effort to make this right. --Iagocasabiell (talk) 09:25, 1 April 2024 (UTC)
- I oppose this proposal. I agree with Simon P, the proposal is not clear, IMHO it is far too long. I also don’t think indexing keys (1,2,3) is a good solution to tagging several signs together. An excellent proposal is concise. Having a dedicated key for sign ids vs verbose values would be ok, although I don’t think it is actually needed. —-Dieterdreist (talk) 09:56, 1 April 2024 (UTC)
- I approve this proposal. --5R-MFT (talk) 10:08, 1 April 2024 (UTC)
- I oppose this proposal. The proposal points to issues in traffic sign mapping, namely better documentation and perhaps more need for standardization. However, it is difficult for me to see any contribution in the proposal to provide more clarity here. Instead, it promotes one of three variants as an "ideal", although in my opinion all three variants are appropriate, depending on mapping context, and do not exclude each other.
- The proposal has (apparently intentionally) many open ends, which means that it does not answer any questions, but only leaves new ones. The human-readable categories for traffic signs remain completely vague and imho aren't evaluable at all in this form. The number-suffix notation (traffic_sign:2 etc.) is unnecessary and has already proven to be useless in other contexts (street parking conditions). The proposal floods me with information that does not seem essential for understanding it, while the actual aim remains unclear. In the end, the presented tagging suggestion seems more complicated to me than the current way(s) of mapping - for example, it seems much easier to me to read a country code from an image table than to think my way into the chaos of human readable values. (Yes, there are regions where these codes do not exist or aren't usable, but then the aim should be to provide a category system that is as clear as possible).
- All in all, it seems to me that the proposal would like to enforce a specific mapping style that most other mappers don't understand. I have tried again and again to understand the proposal process, but I have never succeeded. The main reason for this was the way the discussion was conducted and, in my perception, a lack of willingness to compromise by the proposal author. I'm really sorry for all the work and discussion you put into this proposal, but I can't agree with it in it's current form. Although I can see that things have moved in a better direction between the beginning and the end of the proposal. So a failed proposal should not be the end of the discussion, even if I think the discussion needs to be conducted in a different way. --Supaplex030 (talk) 10:19, 1 April 2024 (UTC)
I have comments but abstain from voting on this proposal. Not having engaged in the discussion before, I have issues with understanding what this proposal actually proposes versus what is a description of current tagging. Looking at the previous votes, I seem to not be alone, although at this point I would just say that I am unable to form an opinion (-> abstain), Also, I am missing information on the actual reason for (apparently) the key points this approval wants to change. E.g.: Why tag traffic signs as vertices on roads, what's the advantage? (Because this requirement(?) comes with a cost as it seems to make lots of extra complexity necessary, such as specifying of traffic sign direction, side, and this :<num>: namespace). Also, what use is e.g. traffic_sign=mandatory? mandatory-what? It seems to be just half-a-sign. --Westnordost (talk) 11:35, 1 April 2024 (UTC)- I approve this proposal. --Hugoren Martinako (talk) 15:42, 1 April 2024 (UTC)
- I oppose this proposal. I can't believe I'm about to type these words, but I agree with the assessment of SimonPoole. This proposal in insufficiently developed and does not clearly communicate the problem, solution, and rationale. --ZeLonewolf (talk) 17:17, 1 April 2024 (UTC)
- I approve this proposal. --Msevilla00 (talk) 17:38, 1 April 2024 (UTC)
- I oppose this proposal. -- I do not see the much value for human readable traffic signals, if you have the id of the traffic_sign it could be automatically generated from that. I also do not like that the proposed usage of traffic_sign and traffic_sign:id basically adds overlapping information, if mappers want to add a description instead of the code that is fine with the note that ideally it should be updated to the id of the traffic_sign.
- Making something human "readable" is a job of the editor or whoever is using the data. Josm has already nice Map Paint Styles that will show the graph of the sign, what would be good is to add support to easier find/add the the id of the sign. -- Emvee (talk) 18:05, 1 April 2024 (UTC)
- I approve this proposal. --Cafeconleche (talk) 19:38, 1 April 2024 (UTC)
- I approve this proposal. I agree with the proposal although I think there is needed to complete and explain some things as other users comment. --Kapazao (talk) 19:45, 1 April 2024 (UTC)
- I oppose this proposal. The currently existing tagging with (concatenated) IDs is ultimately much easier to use than what is proposed here. --JeroenvanderGun (talk) 21:06, 1 April 2024 (UTC)
- I oppose this proposal. I see value for human readable traffic signals, this allows tagging them with much lighter editor support or none at all and used some in ATYL style. But this page fails to convincingly argue that large scale deprecation makes sense here. And yes there is "This proposal does not deprecate any method" fig leaf but we went through it before. Proposal claims something like this and people, sometimes author(s) of proposal immediately go into deprecating other "not approved" versions. Sometimes with bot edits, sometimes manually, sometimes with misleading claims in QA tools (some people still think that highway=bus_stop got deprecated). Also, traffic_sign=restriction makes no sense. That is a class of traffic signs, not a specific traffic sign. Maybe splitting proposal into parts is feasible? And for "when you have a node alone you need to put the facing direction or the cardinal direction" - how that puts preference onto node embedded in a way? In such case it is also needed anyway. "But others alone would need a relation" no, they would not need. It is fine to map traffic sign as a node - it is anyway only addition to restriction/implications mapped on routable way so it is enough so it is human-processed and machine-readable matching to road is not needed. Sorry for not commenting on or reviewing this proposal before due to lack of time. I hoped that someone else will mention issues and they will be fixed. Mateusz Konieczny (talk) 02:49, 2 April 2024 (UTC)
- I oppose this proposal. I see no advantage in adding traffic_sign:2. The proposal is not clearly worked out. --Brummelwuff (talk) 10:49, 2 April 2024 (UTC)
- I oppose this proposal. :2 should be avoided at all costs. We had this mess with :1, :2, etc. in the previous parking tagging. I also don't really see a problem with the current tagging, but I do support moving country-specific tagging to traffic_sign:id or similar. The proposal itself is quite hard to read though, I couldn't really figure out what is changing and what stays the same. --Riiga (talk) 11:38, 2 April 2024 (UTC)
- I oppose this proposal. I see no need to replace traffic_sign ( > 1 mio usage count) with traffic_sign:id --chris66 (talk) 11:47, 2 April 2024 (UTC)
- I oppose this proposal. In Europe, this would mostly result in a mass rename from traffic_sign=* to traffic_sign:id=*, which seems like a huge change and mostly unnecessary. But the no-go is the numbered suffixes. Traffic signs often relate to each other (for example hgv forbidden, with a sign below that, that excepts locals) and spreading stuff that needs to be interpreted together over several keys seems very stupid. --Jonathan Haas (talk) 12:48, 2 April 2024 (UTC)
- I have comments but abstain from voting on this proposal. The main challenge here is that there are quite a bit of signs to "correct", though I don't oppose the idea per-se, especially because the information of human readable values (e.g. maxheight=* or maxspeed=*) can be carried over to the way (traffic_sign:forward=* and traffic_sign:backward=*) if tagged there. On top of that, I prefer comma-separated values over numbered subtags like some previous commentors noted even if it kills readability for humans a bit (this is particularly for backwards compatibility reasons). --ManuelB701 (talk) 16:02, 2 April 2024 (UTC)
- I oppose this proposal. A justification for a rejection is not mandatory. See https://wiki.openstreetmap.org/wiki/Proposal_process#Voting I do it anyway: Tagging with :2 or similar is the worst thing you can do to the OSM dataset. Furthermore, it is not clear whether existing tagging will be replaced or not. --streckenkundler (talk) 20:45, 2 April 2024 (UTC)
- I oppose this proposal. While I appreciate the effort to improve traffic sign tagging, this is far too unclear a presentation, and does not seem to be going in the right direction. JesseFW (talk) 00:30, 3 April 2024 (UTC)
- I oppose this proposal. See reasons given above. In addition, I did not understand the proposal after reading it once. You should keep things simpler. --Nakaner (talk) 09:09, 3 April 2024 (UTC)
- I oppose this proposal. I did not understand the proposal after reading it once. You should keep things simpler and reduce it to the essential. The idea of using traffic_sign:id for cryptic codes in addition to a human readable text in traffic_sign is a good idea. --Fx99 (talk) 08:29, 4 April 2024 (UTC)
- I oppose this proposal. Too much stuff with no concise explanation. Opposing mostly converting traffic_sign=* into traffic_sign:id=* - why is this necessary? If we want more human-readable sign values like traffic_sign=maxweight, then those can be proposed and established to phase out non-readable versions. But everything like hazard=* or maxweight=* are not for traffic signs, but a parallel tagging appropriate for specific elements like roads. You can still add traffic signs to those where they exist. Real-world hardly has consistent signage to assume you can deduce stuff from signs alone. HellMap (talk) 18:43, 6 April 2024 (UTC)
- I oppose this proposal. This would be significantly more cluttered for my country of interest (Norway) --Sbre (talk) 13:25, 7 April 2024 (UTC)
- I oppose this proposal. As above. Also please don't confuse the physical highway=traffic_signals with a traffic sign that announces/warns for traffic signals --Famlam (talk) 21:46, 7 April 2024 (UTC)
- I oppose this proposal. --Tordans (talk) 04:43, 8 April 2024 (UTC)
- I have comments but abstain from voting on this proposal. I don't really know what this vote is about? The whole page or a very specific part of the tags? Not enough information. --GanderPL (talk) 06:58, 8 April 2024 (UTC)
- I have comments but abstain from voting on this proposal. I do really like some parts of this proposal (namely the distinction between traffic_sign and traffic_sign:id, which many people here reject) and it is a good idea to finally unify traffic sign tagging, but there are a lot of controversial parts, which are not sufficiently justified. For example: Why should this tagging apply only to nodes on ways? Why not tag it on the actual position of the sign? Why not tag the whole way were the sign applies?
- I approve this proposal. I'll admin - I didn't read the proposal as carefully as I should. Now I have changed my mind - the only thing that I disagree with is that the tag traffic_sign:id would be in many cases redundant and therefore shouldn't be always encouraged, but this seems to be a more-or-less a minor issue. A lot of people have a problem with making a lot of tags deprecated, but at least from my perspective this doesn't seem to be that big of an issue (at least form my perspective) when you look at how OSM is used and how tagging here works. --comfyquiettree (talk) 14:12, 8 April 2024 (UTC)
- I oppose this proposal. Needs more clarity and concensus before such a massive change is approved and other methods are considered deprecated. --Coehill (talk) 10:48, 8 April 2024 (UTC)
- I oppose this proposal. Not a clear proposal. E.g. direction is not clear and may be ambiguous (direction is defined as the direction an object is facing to). The concept of side seems to be the second best solution as it requires the evaluation of the way's details/direction first instead of having all attributes clear on the object. --Peilscheibe (talk) 16:54, 8 April 2024 (UTC)
- I oppose this proposal. Following Simon's comment, it may make sense to rationalize Vienna and MUTCD IDs, the idea behind the proposal may be fine, however adding stuff like traffic_sign=implicit - which make little sense except if you mean that's the default. But default for what? Speed? Then current mapping is more... explicit traffic_sign=maxspeed + maxspeed=implicit - and the usual convention would to have a notraffic_signal=yes as we have noname=yes . ~~--Nospam2005 (talk) 18:45, 8 April 2024 (UTC)
- I oppose this proposal. Clarity needed. --scai (talk) 10:16, 10 April 2024 (UTC)
Answers to negative votes
I will answer it 1 by 1.
1-"Doesn't add anything what can't be tagged already with ease in fact only complicates." > Well, more tags give to the map more information. Consider a specific place without relation (let's talk about that later),knowing only the traffic_sign itself, the position avoiding multivalues, (let's talk about that later also), the direction and the side (taken from the same way of the node), to unite meanings of what are you mapping. And the possibility to map human readable values and international codes both. Also I think it is not the most large tag system for one item inside OSM. Think about anything with names in other languages. Nobody said "only complicates".
2-"Currently the proposal is lacking any concise documentation of what it actually changes (not to mention examples of changed tagging) making it impossible to determine what is being voted on. It might make sense, it might not, but there is no way to determine that. > In the Aim of this proposal you can read "The aim of this new scheme for traffic_signs is to unite the different approaches for mapping traffic sign as it is. It uses the most complete parts of the existing schemes. It uses the "categories" you can find in traffic signs law from Europe or US, like hazard with a node per traffic sign and with a human readable value,using existing OSM tags to this when possible and marking the position with a numbered subtag :2 or :3...This avoid misinterpretation errors from the tags and also the multi-value problems. Also allows the correspondence between some tags each other. And to be more specific you can use the tag traffic_sign:id=* to specify the code of this traffic sign per country if you know the value. It uses the traffic ID national code you can find in the traffic sign law of each country to mark which traffic sign is and also gives the entire importance as states do in their laws (we know it because when you ask a government e.g. Spanish government, for the database of traffic signs in their roads each traffic sign has a unique ID with its position and code.) There are so convenience to not fit more than three traffic signs at the same pole to make easier the readability for human eye at the reality. This proposal does not deprecate any method but establishes a scheme how you can map a traffic sign in a more specific mapping method.
This proposal establishes:
- 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
- position
-Other existing things will not change (the tagging of highway=stop and highway=give_way is so massive and so controversial than it does not fit in this proposal). "
Think about it, have the other systems some tag to map both the international code and the human readable value in the same node ? Is it any category to map the other traffic signs rather than hazard? Is not clear the reluctance to avoid multivalues in tagging? Is traffic:id existing officially, with proposal ? Things that don't change: "This proposal does not deprecate any method but establishes a scheme how you can map a traffic sign in a more specific mapping method" Is it not clear enough?
3-On the idea, I'm fine with traffic_sign:id=* , but not traffic_sign:#=* number suffix. On the execution, you have butch of "(new)" in Proposal:Extended_traffic_signs_tagging#Examples_of_possible_traffic_signs_human_readable_values that's confusing on whether you are proposing them, and there's a lack of actual examples showing why number suffix is needed. You didn't explain your consideration of alternatives, and justification of using number suffix in the proposal. > About the bunch of (new) values they are in the Example part (you are not voting nothing about that). You can read "If this proposal is accepted, then there will be other specific proposals about the specific human-readable values and its categories (following national traffic laws and most OSM used values) so does not affect this proposal." I don't know where is the confusion. These were here due to a petition in the thread discussion . https://community.openstreetmap.org/t/large-scale-change-of-traffic-sign-to-traffic-sign-id/107508/74 Is it bad to answer other people? About the numbered suffix question. A fast answer would send you to https://wiki.openstreetmap.org/wiki/Finland/Traffic_signs and ask to the Finnish community (I did not write this wiki article). A more extended answer can explain you the fact that every traffic sign should be mapped. In OSM there are some main ideas. One of them is "https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element". When there are two traffic signs you should map the two of them as a unique elements, not a list of it. Tag is traffic_sign=* , not traffic_signs=* . Well, if the position on the node is the same then you will indicate that with a suffix, like Finnish community does. I don't know a traffic sign with two codes or with two meanings. You can map together, in the same node, but you cannot apply different values in the same tag (if you want to respect One feature,One OSM element) so suffix would be a good solution.
4- The whole proposal is huge and doesn't describe well what needs to be changed. Most reasons given are assumptions that have been challenged in the discussions. > The whole proposal is huge because traffic signs are a huge thing. Instead in OSM there are little number of them , in the reality you have...millions so mapping have to be open, and complete. Nowadays there are three methods and only one has a scheme accepted (without voting, from 2009) and other is being rejected...now. This proposal had many changes from the start to take care about the topics in discussion (and the proposer has answered all the questions done in talk and the thread. The structure of the proposal would summarize all the proposal:
Rationale-1.1 Present:Different approaches -1.1.1 By key-1.1.1.1 Highway.The classics-1.1.1.2 Human-readable values-1.1.1.3 Traffic signs by national ID-1.1.1.3.1 Examples- 1.1.2 By way of mapping them-1.1.2.1 On a way or area-1.1.2.2 Separated node-1.1.2.3 Node in a way-1.2 Conclusion: node in a way- 2 Aim of this proposal-3 How it works. How to map-3.1 Position-3.2 Direction-3.3 Side-3.4 Final example-
5-the proposal is not clear, IMHO it is far too long (answered in 3rd). I also don’t think indexing keys (1,2,3) is a good solution to tagging several signs together (answered in 3rd). An excellent proposal is concise. Having a dedicated key for sign ids vs verbose values would be ok, although I don’t think it is actually needed. Well, some topics are answered in 3rd and 4th. But how about the need of human readable values? So...why the hazard proposal, with almost 30 values was approved? How about all the other main 20 "verbose values" we have inside OSM? Should any newbie mapper know all the international codes for traffic signs?
6-The proposal points to issues in traffic sign mapping, namely better documentation and perhaps more need for standardization. However, it is difficult for me to see any contribution in the proposal to provide more clarity here. Instead, it promotes one of three variants as an "ideal", although in my opinion all three variants are appropriate, depending on mapping context, and do not exclude each other. The proposal has (apparently intentionally) many open ends, which means that it does not answer any questions, but only leaves new ones. The human-readable categories for traffic signs remain completely vague and imho aren't evaluable at all in this form. The number-suffix notation (traffic_sign:2 etc.) is unnecessary and has already proven to be useless in other contexts (street parking conditions). The proposal floods me with information that does not seem essential for understanding it, while the actual aim remains unclear. In the end, the presented tagging suggestion seems more complicated to me than the current way(s) of mapping - for example, it seems much easier to me to read a country code from an image table than to think my way into the chaos of human readable values. (Yes, there are regions where these codes do not exist or aren't usable, but then the aim should be to provide a category system that is as clear as possible). All in all, it seems to me that the proposal would like to enforce a specific mapping style that most other mappers don't understand. I have tried again and again to understand the proposal process, but I have never succeeded. The main reason for this was the way the discussion was conducted and, in my perception, a lack of willingness to compromise by the proposal author. I'm really sorry for all the work and discussion you put into this proposal, but I can't agree with it in it's current form. Although I can see that things have moved in a better direction between the beginning and the end of the proposal. So a failed proposal should not be the end of the discussion, even if I think the discussion needs to be conducted in a different way. > Well, it is not the best proposal ever. But it has minimum requirements of a proposal (https://wiki.openstreetmap.org/wiki/Proposal_process) Let's start to answer it. Citting proposal process article in wiki. 2 Before creating a proposal 2.1 Does it already exist? Some people say in thread of the community I have to do a proposal to map in this way, so I assume that does not exists. > https://community.openstreetmap.org/t/large-scale-change-of-traffic-sign-to-traffic-sign-id/107508 2.2 Significance > There is no approved method yet to map with all the possible information a traffic sign. Compatibility with established practices > The tagging system would be able to be adopted for other ways of mapping if someone makes a proposal and vote it. Verifiability: You can see if traffic sign exists or not in the ground. One feature, one OSM element > Each traffic sign has its own code so has to be mapped individually with one tag, also you can map other with the same node with a suffix, to assure the correspondence with other information mapped in the node. Syntactic conventions for new tags > This proposal uses some values are in use in OSM, so there are not new. Due diligence: Research: about ten years , 40 presets, 5 styles working and some messages in tagging list (https://lists.openstreetmap.org/pipermail/tagging/2018-September/039481.html) I have done enough research to assure a proposal that can work. Private comments: I have done about 10 private messages asking about all of that. British English : although my bad English some people help me to fix the writting errors I had in the proposal. Similar tagging schemes: I have talk about the other options of mapping traffic signs in Rationale Section. Explanation: The proposal is clear and it is ordered in a good way to be readable. Potential benefits: I have talking about the mapping for newbie people and experienced people in the proposal. Also I express the errors have the other mapping system that this proposal fixes. 3 Creating a proposal > I have done all these timings until the votation. 4.2 Solicit responses > Four messages in three languages 4.3 Respond. After a talking page with more than 20 sections and a thread in the community with more than 130 messages I consider I have accomplished this part. Also I will answer all the opposite votes, you are reading these answers.
7-The proposal has (apparently intentionally) many open ends, which means that it does not answer any questions, but only leaves new ones. > As you can read in the talk section ,votes and in the thread some people is inviting me to make smaller the proposal and part it. This is what I have done. All open ends are parts of future proposals community has to do in the future. But if the first step is not approved how can do this other proposals? It makes nonsense. The human-readable categories for traffic signs remain completely vague and imho aren't evaluable at all in this form > they are all out of this proposal. They are in the part of examples. The number-suffix notation (traffic_sign:2 etc.) is unnecessary and has already proven to be useless in other contexts > well, it was an option that it is not mine, but it is used and it works (see taginfo). I know it is not the only option but tell me how to follow one feature, one OSM element without saying relative position of two items. the actual aim remains unclear (answered in 4th). It seems much easier to me to read a country code from an image table than to think my way into the chaos of human readable values > You can do this, but in other tag. Should a newbie, in the middle of a street know what value (or searching it by a major searcher) is in Germany for maxspeed traffic sign, and in Spain?, and in Portugal? and in China? The aim should be to provide a category system that is as clear as possible > well, in other proposal, first we have to know how to map the item itself then the other information of that item. specific mapping style that most other mappers don't understand (answered in 6th) The main reason for this was the way the discussion was conducted and, in my perception, a lack of willingness to compromise by the proposal author > Well, these are personal perceptions and you are free of voting whatever you want. I have changed many times the proposals to fit ideas of other people from the threads, I have accepted the corrections done for other community people, and I haven't left any message to be answered about this proposal, even negative votes. I have not get any comment for last week RFC in any three languages I have threads. And I have to read something like https://community.openstreetmap.org/t/voting-zu-traffic-sign-id-lauft/111272 and accept it. Probably I have to retire this votation. But this will not be last time you will hear about this proposal or in relation to this proposal.
8-I have issues with understanding what this proposal actually proposes versus what is a description of current tagging .I am missing information on the actual reason for (apparently) the key points this approval wants to change. E.g.: Why tag traffic signs as vertices on roads, what's the advantage? (Because this requirement(?) comes with a cost as it seems to make lots of extra complexity necessary, such as specifying of traffic sign direction, side, and this :<num>: namespace). Also, what use is e.g. traffic_sign=mandatory? mandatory-what? It seems to be just half-a-sign > In the thread you can read some people talk about a draft proposal. The object of all this process is to be an accepted proposal due the other system has a defacto proposal from 2009, with some issues this new proposal would fix. With a vertice on road you will unite the traffic sign to the way it affects (there is no traffic sign that has no effect at some point) , making relative position possible with two tags. If you put the traffic sign in the real position you would need a relation to point the way where affects or a compass to say the cardinal direction it is faced (or located?) If you put the traffic sign as a property of the way you are mapping the effects of the traffic sign...but not the traffic sign itself...and what can you do to mark the end if there is no traffic sign about that? About the position, if you want to be clever with One feature, One OSM element how to do this without semicolon values? You can map two nodes one up to the other or map with two different tags, with suffix, for example, the proposition of Finnish community made 10 years before. What would be mandatory category? About the "half" category topic...we have approved in OSM traffic_sign=hazard hazard=* and I think nobody said it is just a half-a-sign.
9-This proposal in insufficiently developed and does not clearly communicate the problem, solution, and rationale (answered in 4th)
10- I do not see the much value for human readable traffic signals, if you have the id of the traffic_sign it could be automatically generated from that > but...if not? Do you know all the codes about all the countries? Should a newbie mapper now at all? Why did we approve hazard proposal if then we don't accept the human readable values? What can we do with the other 20 values we have with use in OSM?
11-The currently existing tagging with (concatenated) IDs is ultimately much easier to use than what is proposed here > but it is wrong because this style of tagging does not use one feature, one OSM element.
12- "But this page fails to convincingly argue that large scale deprecation makes sense here. And yes there is "This proposal does not deprecate any method" fig leaf but we went through it before. Proposal claims something like this and people, sometimes author(s) of proposal immediately go into deprecating other "not approved" versions. > I don't want to be rude but I don't know how to tell this. So...should I have to swear by the God I believe that I will not change any traffic sign mapped before? Does Proposal system go in that way? In map we trust? Also, traffic_sign=restriction makes no sense. That is a class of traffic signs, not a specific traffic sign. Maybe splitting proposal into parts is feasible? > This proposal is NOT about categories, you can read it in the proposal. This was already splitted out of the proposal. How that puts preference onto node embedded in a way? In such case it is also needed anyway. "But others alone would need a relation" no, they would not need > It is true ,it is not necessary but...how can you make a relation between traffic sign and the point where acts it? Why in other items like enforcement do we need a relation? And how to map without a compass? It is anyway only addition to restriction/implications mapped on routable way so it is enough so it is human-processed and machine-readable matching to road is not needed > I'm not a big expert about that but I don't understand why a traffic sign does not affect "itself" the object. Also I don't know what software can do that and when, because some approved tags are not considered by main software. Is it a official parameter for "not to map" some kind of objects?
13- I see no advantage in adding traffic_sign:2. The proposal is not clearly worked out. (answered in 3rd )
14-:2 should be avoided at all costs (answered) The proposal itself is quite hard to read though, I couldn't really figure out what is changing and what stays the same (answered in 3rd and 4th)
15- I see no need to replace traffic_sign ( > 1 mio usage count) with traffic_sign:id > Please how to map the exact picture of a Spanish traffic sign of maxspeed or hazard.
16- In Europe, this would mostly result in a mass rename from traffic_sign=* to traffic_sign:id=*, which seems like a huge change and mostly unnecessary > The proposal says specifically "This proposal does not deprecate any method" so there's no need to change anything already mapped. But the no-go is the numbered suffixes. Traffic signs often relate to each other (for example hgv forbidden, with a sign below that, that excepts locals) and spreading stuff that needs to be interpreted together over several keys seems very stupid > With a sign below there are two traffic signs so it is important to have the two traffic signs well mapped and yes , you can have it in the same object perhaps but you will need several tags, that can be readed independent but in coordination.
17-On top of that, I prefer comma-separated values over numbered subtags like some previous commentors noted even if it kills readability for humans a bit (this is particularly for backwards compatibility reasons) > (answered in 8th)
18- A justification for a rejection is not mandatory. See https://wiki.openstreetmap.org/wiki/Proposal_process#Voting > If you have reasons to reject the proposal why you can write it? Tagging with :2 or similar is the worst thing you can do to the OSM dataset. Furthermore, it is not clear whether existing tagging will be replaced or not > I don't know if is the worst thing you can do it to OSM , probably don't tag correctly and avoid the One feature, One OSM element , one of the pillars of OSM would be more bad, isn't it?
19- this is far too unclear a presentation, and does not seem to be going in the right direction > Excuse, please write how can it be to be clearer, smarter and going...forward or backward (it's a joke, it's about direction, not side ;)
20- I did not understand the proposal after reading it once. You should keep things simpler and reduce it to the essential > (answered in 4th)
21-Too much stuff with no concise explanation > (answered in 4th) Opposing mostly converting traffic_sign=* into traffic_sign:id=* - why is this necessary? > Why is necessary to tell the species of a tree? Why is necessary to map the signs of the railways? Why is necessary the international codes that makes a traffic sign a unique design? But everything like hazard=* or maxweight=* are not for traffic signs, but a parallel tagging appropriate for specific elements like roads > Sorry but in the case of hazard the proposal talked about traffic signs. And yes, of course, traffic signs are a specific element of a road so it needs to be mapped in a unique way. Real-world hardly has consistent signage to assume you can deduce stuff from signs alone > Traffic signs are from real world and are invented to sign this real world (by law also, not everybody can invent a traffic sign and can put it there) in a topic, traffic.
22-This would be significantly more cluttered for my country of interest (Norway) > Sorry, but I don't understand why. Your country follows Vienna convention and does not use any complicated color. The nomenclature from your traffic law is clear so in traffic_sign: you would not have any problem to use it. And for the human readable values there are not any difficulties to follow too. Please, tell me the complication. We can fix it.
23-Also please don't confuse the physical highway=traffic_signals with a traffic sign that announces/warns for traffic signals > I don't know what can be the error between highway=traffic_signals and traffic_sign=hazard hazard=traffic_signals. They don't use the same key...
24-Please make your comments, it is difficult to make it better if I don't know where have to start. You can talk about any talked aspect if you want.
25- I don't really know what this vote is about? The whole page or a very specific part of the tags? Not enough information > (answered in 4th)
26-Needs more clarity and concensus before such a massive change is approved and other methods are considered deprecated > (answered in 3rd and 4th)
27-Not a clear proposal. E.g. direction is not clear and may be ambiguous (direction is defined as the direction an object is facing to). The concept of side seems to be the second best solution as it requires the evaluation of the way's details/direction first instead of having all attributes clear on the object. > direction has to be the same as the way it goes. Correct, side refers to the side of the way, it dependes on the direction of the way. Because traffic signs are in a way. Better would be to put in the real place but direction would be the cardinal point to refers, so imagine: you will need a compass to map traffic signs in a road with curves. Better have the info inside OSM itself. And although is a answer here telling that I don't think so it can be so easy to put nodes next to a road and the road itself together without a relation in OSM, depending of a third software.
28-however adding stuff like traffic_sign=implicit - which make little sense except if you mean that's the default. But default for what? Speed? Then current mapping is more... explicit traffic_sign=maxspeed + maxspeed=implicit - and the usual convention would to have a notraffic_signal=yes as we have noname=yes > Remember categories are not in this proposal.
29-Clarity needed > (answered in 4th)
- replied at https://community.openstreetmap.org/t/rfc-traffic-signs-national-id-and-human-readable-values-traffic-sign-and-traffic-sign-id/109456/4 where it was also posted Mateusz Konieczny (talk) 07:06, 11 April 2024 (UTC)