Talk:Proposed features/Extended traffic signs tagging

From OpenStreetMap Wiki
Jump to: navigation, 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:


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





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):




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:



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':


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.


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.


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.