Add support for real-time road events that apply to all vehicles

[mraross]

This will require polling a road event notification service (e.g.,Open511) for real-time events and updating the live road network model appropriately and unobtrusively. The BC Ministry of Transportation provides an Open511 service and BC municipalities may also provide their own.

Real-time road events include unscheduled road repairs, spills, animal encounters, accidents, mudslides, wildfires, flooding, etc. and require restrictions such as road or lane closures, reduced speed limits, or travel direction reversals. The routing algorithm should take these restrictions into account when computing best route.

Only road events that apply to all vehicles are honoured. Road events that only apply to oversized vehicles are out of scope.

Road events will include an affected area that may be specified as a geographic point, line, or area. They may also have one or more road segment ids.

[cmhodgson]

Initial questions:

• where do we retrieve the open511 data, what mechanism to retrieve and load it
• similar to ferry scheduling problem

[mraross]

There is an open511 web service in production that provides road incidents on BC highways. For details, see https://catalogue.data.gov.bc.ca/dataset/open511-drivebc-api

This web service is hosted and administrated by MOTI

[cmhodgson]

The service is nice. We would need to query it regularly for updates and keep all current and future event info stored in the router app. Notable is that none of the current events listed actually include a '+delay' field, meaning that they would have no effect on the routing right now. Some past events do include this information, although the only value I saw was a relatively coarse '+30'. Certainly the service provides the information necessary to add delays where they are specified.

There is a lot of other information in the service, eg. textual descriptions of events, schedules for planned events, etc., would we do anything with that? How would this information be returned in the various output formats, and query types? Perhaps delay time should be a separate field, possibly ferry delay time should be separate from road event delay time? Do the events make an additional line of directions, or are they added to the existing lines?

We would probably want a parameter to specify whether or not to take this information into account. It also requires a date and time of travel, similarly to the ferry scheduling issue.

The application would need a separate thread to retrieve the data from the open511 service, and possibly a monitor thread to restart the data thread if it dies. CPF has more threads than this but it has a monitoring interface so you can see what is going on... I'm just worried that we need some kind of notification system to know when the app has failed to retrieve the open511 data for any reason, for too long.

[cmhodgson]

It doesn't look like Graphhopper supports time-of-day based routing. This means we may need an entirely different approach in order to support at least scheduled events. Realistically though the time-of-day support is pretty much necessary for open511 to make sense. At very least you are making the assumption that you are leaving "now".