UC 2: static road signs
Operation use case
The goal in this use case is to provide the road user with 'other' traffic signalization information. Here 'other' is the signaling that is not linked to speed limits, nor to lane signaling since these are dealt with in other use cases. The road user receives traffic signalization information relevant to him during his trip. When it is displayed, the information must appear in time and at the right location. To support this use case the public information provider will provide a static set of current traffic signs, taken from the TN-ITS source.
The use case also provides for road user feedback where service providers can provide positive and negative feedback on the signs being reported. The public information provider will then forward these to AWV using the same mechanism as in use case 1. AWV can then analyze these reports and add changes to the TN-ITS feed after which this change will be made available to the service providers.
The warning and prohibition signs below will be included in scope (subject to extension). It is up to the service provider which ones will be supported (see below).
| Sign code | Example | usecase |
|---|---|---|
| A14 |  | UC2 |
| A15 |  | UC2 |
| A21 |  | UC2 |
| A23 |  | UC2, UC23 |
| A25 |  | UC2 |
| A43 |  | UC2, UC23 |
| A45 |  | UC2 |
| A47 | | UC2 |
| B01 |  | UC2 |
| B05 |  | UC2 |
| B19 |  | UC2 |
| B21 |  | UC2 |
| B22 | | UC2 |
| C01 |  | UC2, UC23 |
| C03 |  | UC2, UC23 |
| C05 |  | UC2 |
| C07 |  | UC2 |
| C09 |  | UC2, UC23 |
| C11 |  | UC23 |
| C19 |  | UC23 |
| C21 |  | UC2 |
| C22 |  | UC2 |
| C23 |  | UC2 |
| C24a |  | UC2 |
| C24b |  | UC2 |
| C24c |  | UC2 |
| C25 |  | UC2 |
| C27 |  | UC2 |
| C29 |  | UC2 |
| C31a |  | UC2, UC23 |
| C31b |  | UC2, UC23 |
| C33 |  | UC2, UC23 |
| C35 |  | UC2 |
| C37 |  | UC2 |
| C39 |  | UC2 |
| C41 |  | UC2 |
| C46 |  | UC2 |
| D7 |  | UC23 |
| D9a |  | UC23 |
| D9b |  | UC23 |
| D10 |  | UC23 |
| F1a |  | UC2 |
| F1b |  | UC2 |
| F3a |  | UC2 |
| F3b |  | UC2 |
| F5 |  | UC2 |
| F7 |  | UC2 |
| F9 |  | UC2 |
| F11 |  | UC2 |
| F12a |  | UC2, UC23 |
| F12b |  | UC2, UC23 |
| F19 |  | UC2, UC23 |
| F45 |  | UC2, UC23 |
| F45b |  | UC2 |
Specification signs (e.g. M1 - M24 and GIII) will be published together with the main signs.
Position driver passenger vehicle:
A driver of a passenger vehicle approaches a stop sign (B05). The application displays the sign until when the vehicle has left the sign behind.
Based on an algorithm, the service provider can detect if a vehicle is driving in a ghost (sign C01) or entering a road that is not allowed to be driven in (C03).
Data sources
TN-ITS
Similar to UC1, the PIP will publish the TN-ITS feed with the traffic sign data on the static-data API. The RUF will be made available to the publishing entity through the AWV feedback API. Again, changes are intended to be coordinated by the owner of the data source and consequently implemented in the TN-ITS feed. The AWV TN-ITS is constantly improved with new signs and updated information.
Minimal requirements
- Correct insertion and heading of the sign (accurate to 5°)
- Correct relevance zone (validity zone) in the form of linestring coordinates or a multi-linestring
- Sign number
- Unique identifier per sign (needed for road user feedback)
- For lower signs (M09 and M10) we need to know at which upper sign they are present
Data processing (PIP)
1. Event creation
The role of the PIP is limited to merging than the TN-ITS stream with all updates into a complete set of the latest speeds and signs. Furthermore, the PIP forwards each RUF notification to AWV's "feedback API.
2. Follow up and unsubscribe event
The PIP follows up on the TN-ITS updates.
3. Quality Control
The PIP will perform a quality check on the incoming Road User Feedback messages before forwarding them to the AWV Feedback API.
- Are the protocols respected → If no, are they ignored
- Is all necessary info present? → Incomplete messages are filtered out.
- Is the format correct? Messages in incorrect format are not used.
- Is the forwarded feedback ID existing? -> If the id on which feedback is given no longer exists, the feedback is filtered out
RUF and sourcing
For this use case, there is ability to provide Road User Feedback, typically by selecting the sign on the map view and then providing feedback. This feedback can be given when the vehicle is stationary and viewing the signs via the map view. This feedback is then passed to the PIP via the Static Data API. This feedback is then matched to the unique identifiers in the TN-ITS data source and forwarded to AWV via the AWV Feedback API.
MI & Historical archive
The MI is not used for this use case. The static-data API conversion result is not stored in the historical archive. Historical data can be obtained at AWV.
Service provider implementation
The PIP will process the TN-ITS source every day and check for changes. These are then added/modified/removed in the static Data API on which SP can detect this change by periodically querying the API for changes. The SP service then makes the applicable traffic signs available to the end users. The SP can choose to implement this as advance notification and/or detection if a ge/verb is not followed.