Traffic multi-sign notation

Mapping multi traffic_sign nodes came across the traffic_sign wiki which gives samples.

What I’m trying to understand is, when to use a comma separator such as on the no entry sign with bus exception and when to use a semicolon as on the city limit sign combined with a maxspeed, noting that in that example I’m guessing that A0150 is the specific sign for maxspeed 50 where here the traffic sign maxspeed has to specify out what the maxspeed is i.e. it would be traffic_sign=IT:II.50[50].

The only guess I’ve had was that the semicolon is needed because additional qualifiers are given with the city limit sign i.e. [Marum][Maerum][Roermond] and the semicolon serving as an explicit, end of previous sign, new sign start but then a line in the referenced wiki says:

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

Think city limit sign and maxspeed 50 are quite related too, though now I’m reading Amsterdam is essentially going max 30.

At least the country code does not need repetition in a set and suspecting the comma indicating relation of 2 signs can be done with semicolon too, but then would that throw a spanner in a data consumer wheel?

The relation of the signs is important. If both signs stand for their own the semi-colon is the common separator but for additional signs in relation to the upper sign comma is the separator.

1 Like

OK, so here goes, we have sub signs (related to the top sign" in form of texts that don’t exist in the official Italian traffic sign list e.g. “Ponte Basso” (low bridge)

A extreme example here, courtesy google maps, a reason to cycle with helmet in case not ducking low enough, to top it off, buses and special transports advised to think twice.

Read it somewhere long time ago, one could capture the sign text by enclosing it in quotes. Take it from this that it would become the maxheight sign traffic_sign=IT:II.66[3.5 m], “Ponte Basso” , albeit should we use the 3.5 with comma in units of measure or decimal point and the renderer taking care of the translation?

Unfortunately, I don’t have a simple answer to this question. The documented traffic_sign=* minilanguage is too rigid for the U.S. and other countries with similar sign systems, so I don’t use it at all.

For starters, this syntax assumes a very simple design in which a sign can have at most one slot for freeform text. The MUTCD and its regional variants define hundreds of signs with more complex layouts. For example, this is a single sign with ten variables:

This is a single sign that allows a variable number of rows:

This is a sign that contains another sign (the 3 state route marker) and is read nonlinearly:

These slots are unordered and can certainly contain punctuation like ,'":;()[] that breaks the syntax. Instead, I pair a simple sign code with the alternative syntax that relies on secondary keys for iterative refinement. For example, here’s a standard street name sign (which can come in one of a few standard colors):

name=Patterson Road
operator=Franklin County

I appreciate how this approach reuses existing OSM tagging conventions instead of inventing one specific to traffic signs. But each sign requires different tags. That same street name sign is likely mounted on the same post as a sign for a different street maintained by a different agency, even pointing in a different direction. The vast majority of traffic sign posts in the U.S. hold a stop sign and two “blade” signs pointing in different directions:

To prevent mixups between the various signs’ tags, I map each sign as a separate node in the same location with differing layer=* tags, placing only a single sign code in traffic_sign=*. I don’t have a good answer for how to indicate that the signs are mounted on the same support=post/street_lamp/tree, other than performing a spatial query to determine that they’re less than a few centimeters apart.

When I proposed formalizing this approach on the wiki talk page, @Kovoschiz pointed out that separate nodes make it more difficult to determine that a plaque modifies the sign above it. This is true, but I think we should encode the effect of such relationships on the usual roadway tags, for example with except=* on a turn restriction relation. In my view, traffic_sign=* tagging is mostly for presentational purposes, such as plotting signs on a map or displaying them in a car’s heads-up display. If it matters, we could come up with a more explicit tag to indicate that the sign modifies a sign represented by a different node. (In the MUTCD, the sign code for a plaque almost always has a P suffix, but I wouldn’t want data consumers to rely on that detail.)

I would use the comma only so-called additional plates, i.e. signs modifying the meaning of other signs which are meaningless without that other sign.

Note that in the Netherlands, city limit signs and speed limit signs work independently. They do not interact like in e.g. France where the city limit sign extends the scope of the speed limit sign. This is e.g. used by the city of Paris for its 30 km/h limit, and hence the city limit sign is repeated when exiting the Boulevard Périphérique even though the Boulevard Périphérique is already inside the city limits. Amsterdam will instead use a combination of zonal and regular 30 km/h signs; the remaining 50 km/h roads will not be signed.

1 Like