Talk:Key:traffic sign

From OpenStreetMap Wiki
Jump to: navigation, search

Original discussion

See Talk:Proposed_features/Traffic_sign for the discussion on the original proposal.

Neither is worse

I've removed this bit from the signs as separate nodes section:

As this causes major implications on algorithmic processability, it is recommended to tag traffic signs on nodes which are part of a way instead.

If one is mapping them as separate nodes at their exact position, one can and should also tag the signs' effect on the ways they concern. Most probably mappers don't enter the signs thinking routers would pick them up (without also tagging the ways), but for quality control, and - well - maps of signs. Alv (talk) 11:27, 1 September 2013 (UTC)

Yes, mappers should of course also tag the concerned way with corresponding tags (e.g. by using maxspeed=* if there's a speed limit sign). The problem however is that many signs don't have any corresponding tags which could be applied to the way. While this probably isn't an issue for routing itself, traffic signs tagged on the way could for example still be used for enhanced text-to-speech instructions for the driver (e.g. "Caution: falling rocks"). This isn't (easily) possible if the traffic sign is tagged as a separate node. --Emkey08 (talk) 15:48, 1 September 2013 (UTC)
The tag can always be made up, there's even a limited amount of signs in use. (For hazards: hazard=falling_rocks + source:hazard=traffic_sign. I've tagged several hazard=children sections, and long stretches of hazard=moose. :) It's only a problem when there are two identically tagged nodes, one on the way and one next to it; even though there's just one sign. (Signs can be above the road, too, so an accurately placed node might happen on the way, too. Probably should be unconnected, then, though, and with layer=.) Alv (talk) 16:15, 1 September 2013 (UTC)
Hm... but then we potentially need several new well documented tags, as there are hundreds of different traffic signs around the world. People would always have to map both the sign itself as well as the sign's effect on the way, which seems not ideal to me, at least for some traffic signs. It may also simply not always be possible to adequately tag the sign's effect on a way because it actually affects a node or an area instead (examples may include traffic_sign=city_limit, stop signs, give way signs, and others).
Both methods have their pros and cons, but IMO the con of harder algorithmic processability matters more than the con of an approximated vs. exact physical position, which is actually only a rendering issue. Rendering can even be more accurate if the sign is tagged on the road itself because the direction of affected travel can be specified in this case, allowing navigation software to only display traffic signs if they apply to the current direction of travel. --Emkey08 (talk) 06:40, 2 September 2013 (UTC)
The sentence is now better. Nice. Alv (talk) 12:31, 2 September 2013 (UTC)

Always as separate node + effect on the way

I'm a micromapper, so mapping signs which are next to the road, as a node which is part of a way, is not an option for me. The direction tag may seem like a good idea, but as soon as the next mapper splits the way on that node, this becomes meaningless. Maybe the editor software should start warning about this. But will iD ever become so intrusive in people's workflow? It's hard to imagine a world where the developers of iD might even consider that as an option.

Of course, I'll also map the effect the sign has on the way, although I can imagine this will involve a lot of semicolons on certain ways... Especially when parking signs come into play.--Polyglot (talk) 12:38, 30 January 2015 (UTC)

Relevant discussion on the tagging mailing list

This tag was also discussed here: [1] --Dieterdreist (talk) 10:13, 4 November 2015 (UTC)

value of the traffic_sign in []

like for incline value or maxheigh, we can use traffic_sign=city_limit[Paris] for the entrance and trafic_sign=city_limit[-Paris-] for the exit. -Yod4z (talk) 11:59, 3 August 2016 (UTC)