Skip to main content

UC 14: iTLC Time-to-green information and speed advice

Operation use case​

The iTLCs transmit phase information in the form of SPaT messages. We use this information to inform users how long they will have to wait for the green light if the current status is red (time-to-green). This information is displayed in the app in a clear way. The information is displayed as soon as the end user is on the MAP topology, and shows the information of the signal groups associated with the ingress used on the MAP. The SP filters on the basis of modality so that only the signal group of information relevant to the end user is displayed, for example no tram/bus lights are shown to a 'normal' end user.

If there is a reason for waiting time and this information is passed on from the iTLC (e.g. priority for ambulance, closed railway crossing), this will be included as an additional element in the interface.

Road user's point of view

  • the road user A is not at the intersection topology:
    • road user A does not receive a notification
  • The user is at the crossroads topology:
    • road user B is at a green light: the service provider app shows a traffic light that is green
    • road user C is at a red light: the service provider app shows a traffic light that is red, with an indication of the time to green.

Data sources​

Road users affiliated with Service Providers

This use case applies to:

  • Any user who drives around with Flitsmeister or Karta GPS and is on the ingress of an iTLC
  • Any active iTLC registered in TLEX whose MAP topology and SPAT messages are sent over the Mobilidata Interchange
  • Timings when the signal groups are in red phase

Every position of a connected road user will be monitored and checked whether it is on the ingress of an active iTLC. If it is located on this and the current phase is red, the service provider will pass on the estimated time to green phase to the end users.

Crossroads topology

The iTLCs that are connected to the TLEX platform and are currently active must provide the intersection topology in the form of MAP messages. The minimum frequency at which this happens is defined in the IDD UDAP-FI specification v1.0.0. This topology should be a true representation of the topology on the street and should be updated as soon as the topology of the intersection changes and comply with the MAP [specification 3.0.0]](https://kennisbank.crow.nl/kennismodule/detail/112829#112828).

Timing information from the iTLCs

The iTLCs that are connected to the TLEX platform and are currently active must provide the real-time timing information on the MI in the form of SPAT messages. These messages must be completed in accordance with the SPAT v2.3.0 specifications, as laid down in the Mobilidata standards based on the Dutch Profiles. The frequency at which these are sent must also comply with the UDAP-FI v1.0.0 specifications as defined in the Mobilidata standards based on the Dutch Profiles.

By default, we use the 'likely time' from the SPaT message, which is optional in the spec. If this is not present, nothing will be shown. If the iTLC provides the likely time, it must continue to do so, except in exceptional circumstances.

Basic Requirements

  • topology in TLEX that gives a true picture of reality
  • iTLC with "likely time" in the SPaT message

Data processing​

The SPaT data from the traffic lights is placed on the MI without any additional processing.

RUF​

RUF does not apply.

MI & Historical Archive​

All SPaT and MAP messages will be available on the MI.

All SPaT and MAP are archived in the historical archive.

MI Headers​

MAPEM

{
  "messageType": "MAPEM",
  "originatingCountry": "BE",
  "protocolVersion": "MAPEM:1.3.1",
  "publisherId": "BE00004",
  "publicationId": "BE00004:MAPEM_02",
  "custom-mobilidata-dtapEnvironment": "production",
  "quadTree": [
  ]
}

SPAT

{
  "messageType": "SPATEM",
  "originatingCountry": "BE",
  "protocolVersion": "SPATEM:1.3.1",
  "publisherId": "BE00004",
  "publicationId": "BE00004:SPATEM_02",
  "custom-mobilidata-dtapEnvironment": "production",
  "quadTree": [
  ]
}

Service Provider Implementation​

The SP processes the MAP messages and takes into account the different vehicle types that belong to the signal group. The SP uses the MAP message to show the visual sequence of the signal groups and the associated lanes. Also, the lens templates should be derived, if desired, from the SPAT information (arrow / full lens). If the SPAT message contains a reason for the waiting time, it must also be filtered in terms of relevant signal group (reason waiting time only relevant for the signal groups that are red) and then whether or not it is forwarded to the end user.

Subsequently, the SP must match the positions of the end users on an approach and only select the signal groups that are relevant to the type of vehicle of the user.

Tags:
Last updated on by Wiggertsm