UC 23: Static road signs: Active road users (ARU)
Operation use case
Purpose
In this use case, a set of traffic signs that are relevant to the active road user is published on the Static Data API. This data offers a service provider the opportunity to inform or warn an active road user at the right location and time about the applicable traffic signs.
Please note: for this use case, only data is placed on the Static Data API, implementation of the use case in the ARU app is not foreseen. With the available data, a third party can fully realize this use case.
The signs below are part of the use case
| code | sign | code | sign | code | sign | code | sign |
|---|---|---|---|---|---|---|---|
| B01 |  | B05 |  | B22 |  | B23 |  |
| C01 |  | C03 |  | C09 |  | C11 |  |
| D7 |  | D9a |  | D9b |  | D10 |  |
| F99a |  | F99c |  | F111 |  | F12a | |
| F101a |  | F101c |  | F113 |  | F12b | |
| A23 |  | A43 |  | A45 |  | A47 |  |
| B03 | | B19 |  | B21 |  | B51 | |
| C13 | C15 | C17 | C19 |  | |||
| C31a |  | C31b |  | C33 |  | F19 |  |
| F45 |  | F45b |  | F99b | | F101b | |
| F103 |  | F105 |  |
The following underplates will be taken into account
| M01 | M02 | M03 | M04 | M05 |
|---|---|---|---|---|
| M06 | M07 | M08 | M09 | M10 |
| M11 | M12 | M13 | M14 | M15 |
| M16 | M17 | M18 | M19 | M20 |
| M21 | M22 | M23 | M24 |
Speed Limit Signs
No speed information for ARU (relevant to speed pedelecs) is included within this use case.
Data sources
TN-ITS (same as UC2)
Similar to UC2, the PIP will retrieve the above selection of road signs from the TN-ITS feed and publish them on the Static Data API. At the moment, not all boards are in the TN-ITS feed, this will be adjusted in the run-up to the implementation of the use case.
Minimum Requirements:
- Correct location and heading/orientation of the board (accurate to 5°)
- Correct relevance zone (validity zone) in the form of linestring coordinates or a multi-line string
- Board number
- Unique identifier per board (needed for road user feedback)
- For each bottom plate (M01 to M24) the top plate must be known
RUF (see below)
Data Processing (PIP)
Creating and updating ARU traffic sign dataset
The role of the PIP is limited to merging all updates in the TN-ITS feed into a complete up-to-date set of relevant ARU boards. The PIP publishes this set as a TN-ITS snapshot on the Static Data API.
Forwarding RUF notifications to AWV's feedback API
The PIP will perform a technical validation on the individual Road User Feedback messages, before forwarding them individually to the AWV Feedback API
- Are the protocols respected?→ If not, they will be ignored
- Is all the necessary information available? → Incomplete messages are filtered out.
- Is the format correct? Messages in incorrect format will not be used.
- Is the forwarded feedback ID existing? --> If the ID on which feedback is being provided no longer exists, the feedback will be filtered out
RUF
Road User Feedback (upvote or downvote, no sourcing) is forwarded from the service provider to the PIP via the static Data API. The RUF is made available to the publishing entity (AWV) for 3 days on the AWV feedback API, hosted by Be-Mobile. The owner of the resource (AWV) is supposed to retrieve the RUF (GET/road-signs-ARU), validate it, and correct the TN-ITS feed where necessary.
MI & Historical Archive
The following data streams are not archived:
- TN-ITS: Static Traffic Signs
- RUF: is individually forwarded to the AWV feedback API