<div class="gmail_quote">I think most points are adressed on the proposal or talk pages, but here we go:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Putting lots of traffic signs on nodes on the way would result in a lot of new nodes on the ways, which will need optimising out by routers/mkgmap etc. </blockquote><div><br></div><div>The node count will increase anyway, the tools need to scale accordingly. Probably mapping one smooth corner adds about as much complexity as all the signs on that road.</div>
<div>You could put the nodes for the signs beside the road, where they are located in reality. But then the connection with the road needs to be established by other means, possibly a relation. This also adds complexity. And this kind is hard on the mapper, not just on some script.</div>
<div>Also tagging the hazard on the road will introduce new road splits and nodes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The sign is not really an attribute of the road. Putting a tag on the road segment to which the warning applies would seem to me a more logical way of indicating these semantics, and a whole lot more usable for the routers. An indicative node for the sign itself (so then we are mapping "street furniture" i.e. the post itself with the signs attached to it, not the characteristics of the road) would be fine IMHO although I do wonder if this level of micromapping would be productive in the long run.<br>
</blockquote><div><br></div><div>That's what I proposed some mails ago: tagging the hazard on the road segment or node where it belongs, then  adding the sign as a node on its physical location. Will it carry any useful information? Well, I also think the hazard is more important than the sign itself, but who knows what use it may be to some people. I myself once needed to know the locations of all city limit signs of one town. The answer was one XAPI call away.</div>
<div>Also the sign position serves as a kind of verification and source reference for the hazard tag.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
If there are multiple signs on a single post, we will get (I assume) constructions like traffic_sign=sign1;sign2;<u></u>sign3. As we know multiple-valued tags are currently poorly supported by the available tooling (correct me if I'm wrong....)<br>
</blockquote><div><br></div><div>I think there is no tooling yet which uses traffic signs at all. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Signs often have "sub-signs" qualifying the main sign, e.g. slippery road "when wet". This will need a place in the tagging as well. How would we handle multiple signs on a post, each with its own "sub-sign"?<br>
</blockquote><div><br></div><div>Same goes for textual signs. No idea. There are schemes for opening hours which also could apply to signs. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The "extent" of the hazard has already been mentioned (e.g. sharp bends "for 5km"). Often a warning sign gives advance notice of the hazard (e.g. low bridge "in 2 km") so the sign's location differs from the location of the hazard it is indicating.</blockquote>
<div><br></div><div>Most of those information is already contained in the hazard tagging of the road segment. Both the position and the extend of the hazard are given there. For tagging the sign itself (for the sake of completeness alone), see above: no idea so far ..</div>
<div><br></div><div>just my 2 cents</div><div><br></div><div>Chaos99</div></div>