UC 25: Road works warning - active road user (ARU)

Operation use case

Purpose

In this use case, a set of roadworks that are relevant to the active road user is published on the MI. This dataset offers a service provider the possibility to inform or warn an active road user at the right location and time about roadworks on their route.

Please note: for this use case, only data is placed on the Mobilidata Interchange, 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 figure below shows a reference implementation by a service provider.

Data sources

• GIPOD - Generic Information Platform Public Domain: the primary data source for this use case.
• Event sourcing from RUF: new notification of road works by connected active road users.

The DATEX II feed (VVC) cannot be used as a source in this use case because the DATEX II feed does not include ARU-specific nuisance classes (focus on primary road network). The roadworks from the DATEX II feed all fall under UC 12 'Road Works Warning'.

Data Processing (PIP)

1. Create an event

The information from the above-mentioned sources is collected and validated in the PIP. Only the roadworks that also indicate the impact on active road users are published as "ARU roadworks" events on the MI as DENM messages.

GIPOD

Roadworks in GIPOD are drawn as polygons. However, DENM does not offer the possibility to use multi-line strings or polygons according to ETSI standards. Therefore, the PIP will transform the GIPOD polygons into multiple individual DENM roadworks events. The PIP will create an individual DENM roadworks event for each road within the GIPOD polygon in each direction of movement. The polygons are mapped in both directions on all relevant road types (including separate cycle paths) from OSM.

To reduce false positives, GIPOD events in the PIP are filtered before they are published (same filtering as for UC12 Roadworks Warning). Only GIPOD events that meet the following characteristics will be retained:

• Status: "validated"
• GIPOD hindrance type where active road users are definitely hindered:
  • 'No passage for pedestrians',
  • 'Restricted passage for pedestrians',
  • 'No passage for cyclists',
  • 'Limited passage for cyclists'
• Duration: max 31 days
• GIPOD polygon: from which up to 6 roadworks events are created. Large polygons covering a large number of roads are often inaccurate in the GIPOD source and therefore do not give a qualitative indication of the location.

Event sourcing (RUF)

In the apps connected to the Mobilidata ecosystem, users are given the opportunity to report road works. Ideally, the reports from users are validated by the service providers. Only if there are enough reliable reports from users who indicate road works, an event will be created in the PIP, see RUF.

2. Follow-up and cancellation of the event

The PIP updates the various data sources and keeps track of a set of validated events.

An event can be cancelled for the following reasons:

• An update at the source,
• The expiry of the time to live (only for events that have entered the PIP via event sourcing): 24 hours after the last RUF upvote
• Log-out by users via RUF.

3. Quality Control

The PIP will perform a quality check on the DENM messages, before publishing them on the MI (same as for UC12 Road Works Warning). The following checks will be implemented:

• Technical validation
  • Are the protocols respected? Incorrect messages are filtered out.
  • Are all required fields filled in according to C-roads standard? Incomplete DENM messages are filtered out.
  • Is the format correct? Messages in incorrect format will not be used.
  • Isn't the message too old? Outdated messages are filtered out. Several checks are done in the PIP to check that a message sent to the MI is not outdated. For example, if a newer update is already in the PIP before the previous message has been sent to the MI (e.g. due to a delay in the PIP). It is not possible to put an exact time on 'outdated messages', as this time will be use case and source dependent.
• Merge & Decide
  • Check whether a similar event (road works) is already known in the PIP at a limited distance from the new event.
    If it does, the events will be merged and the notification will be updated as needed.
    If not, a completely new event will be reported.
  • More detail in blueprint Merge & Decide

RUF

Validation of road works

In the apps connected to the Mobilidata ecosystem, users are given the opportunity to give feedback (upvote/downvote) on the ARU roadworks events. When there are sufficient/reliable reports from users that there are no more road works, the message must disappear.

Reporting of road works (event sourcing)

In the apps connected to the Mobilidata ecosystem, users are given the opportunity to report road works.

The notifications from the Service Providers must contain at least the following optional fields in the DENM messages:

• Restriction (= modality)
• EventHistory of EventPositionHeading

MI & Historical Archive

DENM informatio

The following data streams run over the MI and are archived after conversion:

• Implementation as described in RWW-LC/RWW-RC in C-ROADS TF2
  • causeCode 3 (roadworks)
• Optional restriction DF in RoadWorksContainerExtended DE in DENM 1.3.1 is hereby filled in to indicate type ARU users for the roadworks. Restrictions will include the following station types:
  • pedestrian (1)
  • cyclists (2)
  • Moped (= moped) (3)

MI Headers

Capability descriptor:

{
  "messageType": "DENM",
  "originatingCountry": "BE",
  "protocolVersion": "DENM:1.3.1",
  "publisherId": "BE00004",
  "publicationId": "BE00004:DENM_ROADWORKS_01",
  "custom-mobilidata-publisherType": "PIP",
  "custom-mobilidata-dtapEnvironment": "production",
  "custom-mobilidata-useCase": [12, 25],
  "quadTree": [
  ]
}

Historical archive

As well the original messages as the RUF messages ar stored in the historial database.