Skip to main content

UC 20: Recommend routing

Operation of the use case​

The aim of this use case is to offer the road user a high-quality navigation solution that takes into account a combination of recommended routes that are stimulated (e.g. diversion during road works, events or incidents) and locations to avoid or unwanted shortcuts that are discouraged.

A service provider will take into account the following parameters and resources when calculating a route advised by the government:

  • Live speed and travel time
  • Road classes (from OSM): use of roads with a lower road class (roadclass 1 = motorway, roadclass 8 = e.g. unpaved access road) is encouraged.
  • Active emergency routes: in the event of an emergency on the higher road network, a predefined 'emergency route' is stimulated as an alternative to the road with the emergency.
  • Locations to avoid:
    • School Environments
    • Bicycle streets
    • Hospitals and nursing homes
    • Manually entered locations
      • Major sporting and cultural events
      • Periodic markets

The locations to be avoided can be activated permanently or within certain time windows (based on a calendar). Service providers can also assign priority levels to the locations to avoid. The priority level determines how hard the route planner will try to avoid the location.

The purpose of the use case is to suggest the advised route as an alternative to the fastest/shortest/... route in navigation devices and apps. This gives the end user the opportunity to choose the recommended route or not. The users are briefly and powerfully informed about the policy rules that are applied to the route, so that they can make an informed choice.

To monitor the effectiveness of the use case, the use of the advised route will be objectified. The service providers will keep track of how often a user chooses the socially desirable route.
The route desired by the government is not automatically set or accepted, so there is a greater chance that the user's reported route choice will correspond to the actual route followed. This is because the end user must consciously choose the recommended route.

Vehicle Viewpoint

When choosing his route, the road user receives, in addition to the standard route information, also the socially desirable route (advised by the government).

Data sources​

Locations to avoid​

  • School Environments

    • A new dataset will be made of all roads with a speed of 30km/h (or lower) within a radius of 50m around a POI or 25m around a polygon of a school.
      • Source static speed limits: see UC1
      • Source point locations schools: https://www.vlaanderen.be/datavindplaats/catalogus/onderwijsaanbod-in-vlaanderen-en-brussel-via-poi-service
        • POI types: Special pre-primary education, Special primary education, Ordinary pre-primary education, Ordinary primary education, Special secondary education, Part-time vocational secondary education, Full-time mainstream secondary education
        • The following POI types are not included as locations to avoid: Colleges, Universities
      • Source: OSM(amenity= school, kintergarden, college)(building=school, kintergarden, college)
    • Active time window (nursery, primary and secondary education): weekdays 8am-9am, 11.45am-1.30pm and 3.30pm-6pm

  • Bicycle streets

  • Hospitals and nursing homes:

Locations to avoid - TREM​

Via the TREM application, authorized entities (initially only VVC) can manually draw routes to be avoided. Each road or route to be avoided is drawn as a line string and is given an event type (such as evacuation, fair, sports event, etc.) and a time window. Route recommendations in TREM must always be given an end date, periodic events can also be created on the basis of the calendar function.

The priority level of a route to be avoided is linked to the event type and is determined by the service provider. To avoid unpredictable behaviour of the route planner, an end user will not be given the opportunity to enter weights himself. The list below contains event types that can be expected in TREM, these are mainly large events, emergencies and weather phenomena with long-term local traffic impact. TREM is not intended to enter events that are already covered by other mobilidata use cases (such as traffic jams, road works, accidents, objects on the road, etc.).

ALERT-CMessageALERT-CMessageALERT-CMessage
900Flooding expected1456Bullfight1504Festival
904Storm damage1457Cricket Match1505Exhibition
907Flood1458Cycling race1506Fair
909Fast rising high tide1459Football match1507Market
910Chance of rapidly rising high tide1460Golf tournament1508Ceremony
911Avalanches1461Marathon1509State visit
912Avalanche danger1462Horse racing1510Parade
913Falling rock1463Rugby match1511Crowd of people
914Landslides1464Jumping1512Procession
915Earthquake damage1465Tennis tournament1513Demonstration
917Subsidence1466Water sports tournament1514Riots
921Fierce fire1467Winter sports tournament1515Safety measures
950Subsidence1468Fair1516Bomb threat
972Storm damage expected1469Fair1590Various events
974Flooding of the sewer system1470Procession1592Car Racing
975Curling ice1475Strike1593Baseball game
976Mudflow1476Security Incident1594Basketball Game
977Roadside fire1478Terrorist attack1595Boat race
1032Risk of explosion due to gas leak1479Gunfight on the road1596Concert
1450International sporting event1480State of emergency1597Hockey match
1451Contest1481Air Raid3091Danger
1452Tournament1494Evacuation3096Explosion
1453Athletics Tournament1501Event3097Fire
1454Baseball Game1502Sporting event3098Radiation hazard
1455Boxing Match substances1503Show3099Leakage of toxic

A TREM user can be given three different permission levels: read-only, edit, and edit+publish. Only when a route is published will it be added to the dataset of routes to avoid on the Static Data API. Organizing the governance with regard to login details and authorization levels is part of MOW.

The responsibility for the correct use and drawing of routes in the TREM tool lies with the creator of each event. No technical validation of new events is done by the PIP or route planner.

Note that we also want to use the TREM application for the requirements linked to the emergency button. The interpretation of this topic will be examined and dealt with separately later.

Emergency and diversion routes​

The emergency routes are obtained from the VVC: https://metadata.vlaanderen.be/srv/dut/catalog.search#/metadata/82ca43d6-b671-4cc8-b588-6ad1696846c6

  • A static data source with redirect routes.

  • Diversion routes are dynamically activated by VVC, via DATEX II feed.

  • A diversion route is activated if the motorway is blocked or closed for a number of hours, for example in the event of a serious accident. As soon as an emergency route becomes active, the VVC will communicate via the dynamic signs above the road and the DATEX II feed which diversion route is recommended. The diversion route will be signposted with yellow signs with a route letter. The diversion routes follow the most suitable regional roads from the exit to the next slip road, where the motorway is back to traffic jams.

  • Codes are used to specify the type of diversion route:

    • OLA: Long Distance Diversion Route
    • OKL: Node Loop Redirection
    • ORA: Diversion Antwerp ring road
    • ORB: Brussels ring road diversion
    • OSB: Diversion of the city of Brussels
    • ANT-xxx, OVL-xxx, WVL-xxx, VLB-xxx, LIM-xxx: local redirects

Point of attention: conflicting routes​

It is important to make sure that there are no conflicting routes to avoid and routes to recommend. The control of the combination of all entered routes is out-of-scope.

Data Processing (PIP)​

1. Creating input data​

The emergency routes and the locations to be avoided are bundled by the PIP into 1 static dataset that is published on the Static Data API.

2. Dynamic activation of emergency routes​

As soon as an emergency route is activated by the VVC, the active route is published in DATEX-II format on the MI. This allows the service provider to charge for all active calamity routes in the routing algorithm.

3. Monitoring user behavior​

The service provider registers how often a user does or does not choose the socially desirable route. The percentage share over a certain period (e.g. a day) is sent to the PIP after that period, via the feedback channel on the Mobilidata Interchange. If the socially desirable route is the same as the fastest route, this is seen as 1 route and included in the count.

The PIP will make these percentages available per service provider on the AWV feedback API, for 3 days. Monitoring and evaluation of these results is the responsibility of MOW.

The service providers only report the choice made by the road user in the navigation app. It is not checked whether the selected route corresponds to the actual route followed. In the future (not in scope) the GPS positions could be checked via the SDK (with permission) to check which route was followed by the user.

RUF​

The user cannot give feedback on the proposed or followed route.

The feedback channel (for RUF) is used by the service provider to send the statistic (% how often end users, whether or not to select the recommended route) to the PIP.

MI & Historical Archive​

The following data streams run over the Static Data API​

  • Emergency routes
  • Locations to avoid

The following data streams run over the MI​

  • Activated emergency routes
  • Statistic: "% of the number of times a user has chosen the socially relevant route"

MI Header​

{
  "messageType": "DATEX2",
  "originatingCountry": "BE",
  "protocolVersion": "DATEX2:3.4",
  "publisherId": "BE00004",
  "publicationId": "BE00004:DATEX2_ADVISED_ROUTE_01",
  "custom-mobilidata-publisherType": "PIP",
  "baselineVersion": "1_0",
  "custom-mobilidata-dtapEnvironment": "production",
  "custom-mobilidata-publisherName": "AWV",
  "custom-mobilidata-publicationType": "SituationPublication",
  "custom-mobilidata-useCase": [20],
  "quadTree": [
  ]
}

Historical archive​

No historical archiving is foreseen.

Service Provider Implementation​

The service provider integrates the activated emergency routes and the locations to be avoided into the existing navigation system. The service provider calculates the possible routes, including the recommended route, and suggests these route options to the road user. The order in which different route options are proposed is to be determined by the service provider. Usually, the fastest route will be proposed as the first option and only then the recommended route. The recommended route of social importance will be presented with additional information that explains the public interest.

If an emergency route is activated during the trip, the service provider can (optionally) propose an updated recommended route to the end user. The user must explicitly indicate whether he/she wants to follow this new route, otherwise the current set route will be retained.

The service provider will track and report user behavior.

Tags:
Last updated on by Wiggertsm