[Tagging] Preventing traffic signs - Invitation to discussion

Ronnie Soak chaoschaos0909 at googlemail.com
Wed Mar 14 18:23:42 GMT 2012

I think most points are adressed on the proposal or talk pages, but here we

> 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.

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.
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.
Also tagging the hazard on the road will introduce new road splits and

> 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.

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.
Also the sign position serves as a kind of verification and source
reference for the hazard tag.

> If there are multiple signs on a single post, we will get (I assume)
> constructions like traffic_sign=sign1;sign2;**sign3. As we know
> multiple-valued tags are currently poorly supported by the available
> tooling (correct me if I'm wrong....)

I think there is no tooling yet which uses traffic signs at all.

> 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"?

Same goes for textual signs. No idea. There are schemes for opening hours
which also could apply to signs.

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.

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 ..

just my 2 cents

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120314/baa2ad1c/attachment-0001.html>

More information about the Tagging mailing list