Finland/Traffic signs

Traffic sign mapping in Finland

MapCSS and Presets for JOSM

MapCSS and Presets for JOSM are available from here: [1]

Installation

In JOSM, open "Edit" => "Preferences" => "Map Settings" => select "Tagging Presets". Add new (+) preset.

Requirements

• New enough JOSM (r5620+), old ones fail in MapCSS grammar parsing due to use of [] in the traffic_signs.
• Starting with JOSM r5875, the zip file should work for the MapCSS style, too. For older versions, .zip needs to be used as is for the presets (point to .zip in JOSM preferences) and unpacked for the MapCSS style (point preferences to .mapcss, unfortunately it's not clear how the zip could be used for both functions directly).

Usage hints

• For easier use, one might want to add traffic_sign preset submenu as a button to toolbar

How to Map

traffic_sign=FI:x for the topmost sign, use man_made=beam if necessary to separate signs from walls (or poles if appropriate).

traffic_sign:2=FI:x for the second sign from the top

traffic_sign=FI:x;FI:y for the topmost sign, the signs are for different direction (usually opposing but could have different angles mainly with destination signs).

traffic_sign=yes/triangle/round/circle/square/rectangle can be used to indicate that there's a sign but the content is not yet surveyed (e.g., only backside visible in a photo or too far away to see clearly)

use [] marking for changing content in the sign, e.g., traffic_sign=FI:361[60] , traffic_sign=FI:363[40] , traffic_sign=FI:343[10 m]

Related item that is easy to collect along traffic_sign, are the physical positions of the traffic_signals (they often even share a pole with some of the traffic_signs). Use traffic_signals=signal+traffic_signals:foot/motor_vehicle/tram/bicycle=yes and traffic_signals:button=yes. Presets in this package already include traffic_signals. Currently, there is no MapCSS support to visualize traffic_signals but one is on TODO list.

Some early phase traffic_sign mapping was conducted directly into highway nodes, these should be moved into real position once more accurate survey has been done (mainly pedestrian/bicycle related signs are in highway=cycleway/footway nodes, ie., FI:421-FI:425 ). However, highway=yield/stop tags from the nodes of a highway should not be removed even though they are rendered by default by JOSM similar to traffic_sign MapCSS (FI:863 or it's typo FI:683 can also appear in those nodes and should be moved below FI:231 ).

Brief History/Rationale

Some years back someone from Liikenneturva opened Pandora's box by explaining that there's difference in the traffic rules depending on whether motor vehicles disallowed (traffic_sign=FI:312 ) and designated cycleway (traffic_sign=FI:422-425 ) is posted. The differences include non-taggable differences in pedestrian positioning (which side) and possibly yielding rules in cases where such way is used by a bicycle (unclear). Besides those, we already knew that taggable foot=yes/designated and horse=yes/no also depend on those signs. However, through earlier experience we knew there would be huge number of inconsistencies and lacking signs which are hard to map into the ways themselves using conventional tags, and covering all entrypoints of a large area at once is challenging, and one-by-one solution would be preferred. Therefore traffic_sign mapping commenced. When the collecting started, only pedestrian/bicycle signs were covered with very limited attention to other signs (city_limits FI:571 and FI:572 being one exception, where also actual positions of the signs were mapped here and there, but they're quite rare to begin with). Very trivial MapCSS rendering for those signs in JOSM was made.

Secondly, it was determined that solving the challenge of maxspeed=* zones (traffic_sign=FI:363 /FI:364 ) and no parking zones (traffic_sign=FI:373 /FI:374 ) would also significantly benefit from mapping individual signs. Unsurprisingly, also mapping them revealed some inconsistencies (some are already fixed by the city :-)), and more importantly lead to discovering more than handful of incorrect maxspeed=* data in OSM, either due to more recent changes of the actual maxspeed or invalid data right from the beginning. With the traffic_signs mapped, it is now much more obvious to the next mapper how the maxspeed value was determined, a significant improvement. A more complex MapCSS ruleset was tried, however, it quickly became overly complex to extend.

In a sudden rush of few weeks, highway=yield tags were added (to the highways at that stage) either through local knowledge or survey. highway:yield=yes was quickly decided to be the hack for solving the semicolon issues with traffic_signals (easy to change later if we want to, as the hard work is already done, ie., the data is collected/surveyed). Due to lacking cycleway signs also traffic_sign=FI:863 was deemed interesting, in order to determine if the crossing was supposed to have a cycleway even if not signed properly (ie., bugs that should be fixed by the city). Initially FI:863 were placed into the highway node, but data gathering for the actual position of the FI:231 and FI:863 is already underway and rest should be eventually migrated into the real position.

While mapping the zone signs, the other signs in the same pole where covered too occassionally. As the number for different kind of sign we were collecting was constantly increasing, a more complete solution for the rendering that was whole the time behind the new additions was needed. More complex MapCSS implementation was attemped. However, there are significant limitations in MapCSS, or at least in how JOSM implements it. The limitations essentially forced us to use traffic_sign=*, traffic_sign:2=*, traffic_sign:n=* style mapping, which is not entirely compatible with the use traffic_sign=*. However, it seems compatible enough that both can peacefully coexists ATM. Please note that it was not done entirely due to rendering though as in a single pole there can be signs facing for the opposing directions which the earlier traffic_sign=...;...;...;... approach fails to describe with sufficient detail as only vertical position is covered. traffic_sign=x;y was selected to describe the situation where the signs are for the opposing directions. With the improved tagging style, MapCSS rendering was finally possible (after fixing a limitation for [] in JOSM MapCSS grammar). Although some positioning still has to be done outside of JOSM's MapCSS engine because image offset are not possible.

Another long dreamed thing seemed to be finally possible. That is, to get maxlength (FI:343 ) and hazmat restrictions (FI:318 , FI:848 , FI:849 ) fully checked and correctly mapped as in practice they are often unidirectionally posted. Only if all entrypoints have the restriction, it can be applied for all of the ways in the zone using conventional bidirectional tags.

As one might guess, the visual feedback from full MapCSS implementation encouraged us to start mapping all traffic_signs, and that is what were are doing now. It might seem ridiculous to some but after we've found quite many errors from OSM data, the effort seems quite worthwhile just from the quality assurance point of view (although some might argue that not all signs are that useful from QA PoV).

Methods

So far, the main mappers have used video or series shooting with cameras. This enables large scale mapping more easily. Individual shots are most useful if the mapper is only interested in a very limited set of targets (e.g., zone signs only).

For frequently used/surveyed routes, also memorizing signs is possible approach, albeit slightly slow in progress.

Inconsistencies

• traffic_sign:bug=*, traffic_sign:bug:missing=* and traffic_sign:missing=* can be used to make "notes" about flaws so that they are easier to locate afterwards. You may use traffic_sign:bug:should-be=* to indicate correct sign (e.g. traffic_sign:bug=FI:812[left] + traffic_sign:bug:should-be=FI:826[left]), the good thing in this approach is that the correct sign is then in a machine readable format.
  • Examples of bugs:
    • maxspeed is not consistent
    • cycleway endpoints disagree segregated=yes/no (FI:423 vs FI:424 / FI:425 )
    • Pre-warning of FI:231 has FI:814[x m] instead of correct FI:815[x m] below it, or it has inconsistent distance to the effective sign
    • wrong one of FI:424 / FI:425 used (please consider that the sign might have changed direction after installation)
    • leaking zones
  • Examples of missing:
    • Missing cycleway sign
    • Missing FI:871[Sallittu mopoille]
    • Missing FI:511 although painting on ground

Nanomapping opportunities

• FI:231[old] (obsoleted give_way sign with a narrower red rim) was discovered from some newspaper "should be fixed" series as a candidate for collection, and quickly some were located (we are yet to submit these to the city as it seems somewhat pointless to enforce replacement to few cm wider red rim). Currently mapped ones using Overpass API: [2].

Some screenshots

Links

Tieliikenneasetus (in Finnish)

Liikennemerkit suomessa (wikipedia)