Support 'Emergency' Requirements Class

[skyNacho]

This issue arises from the experience in SCIRA pilot. In OGC API - Routes consider support for specifying 'Emergency' type of route in requests.

If a route is requested for emergency vehicles, the routing engine can apply non-standard rules to the route calculation, such as ignore specific turning restrictions, make use of restricted lanes, increase speed limits, ignore specific closed streets, and so on.

In addition, routes can be requested for evacuation purposes. If an evacuation route is requested, the routing engine can apply non-standard rules to the route calculation, or randomly return one route among all possible routes.

Copy-pasted from SCIRA ER:

New parameter "context", with three possible values:

• "standard": default value. It generates a standard route, without additional rules
• "emergency": It generates a route for an emergency vehicle, taking into consideration road segments and maneuvers only allowed for emergency vehicles
• "evacuation": It generates a series of possible routes from A to B and randomly selects one

[jeffharrison]

A 'context' parameter with the values listed seems like a very rational and useful addition to OGC API - Routes.

Also seems like a straightforward addition to the API.

[skyNacho]

The 'context' parameter is useful for APIs that offer different rules to calculate routes. For example, emergency routes use different rules than standard routes (forbidden maneuvres, speed limits, usage of tram lanes, obstacles that do not apply to emergency vehicles, ...). However, we need to take into account that an API that only offers emergency routes would not need this parameter (all the routes will be calculated using the same rules). It is important to assess whether the use case is important enough to add an additional parameter to the standard (core or extension).

I can see three options on how to add the 'context' parameter to the standard:

1. To specify a list of values in the standard and expect them to cover all the possible use cases.
2. To let each API specify a list of accepted values for the 'context' parameter and provide information on how to use them.
3. Not to have any 'context' parameter and force the deployment of different APIs for each context

[ghobona]

I think a context parameter would be useful.

However, I would suggest that the parameter accepts URIs as values instead of free text. This would enable OGC to maintain a register of contexts.

For example, the MetOcean DWG might register a series of contexts for different types of weather. The D&I DWG might register a series contexts relating to types of emergencies or the permissiveness of the environment.

I would also suggest that the multiplicity is zero-to-many.

Core could just specify the parameter and not need to provide a code list. The DWGs would then register contexts.

Cc: @rob-metalinkage @chris-little

[chris-little]

This seems a sensible idea. But in terms of weather, I am not sure that a series of contexts for different types of weather would be easy or worthwhile to establish, because of the great variablity on all scales including very local.

Impact of the weather is a better context. For example, 4mm of rain in one hour may not matter in many places, but if there is already flooding, 4mm maybe enough to overtop flood barriers with disastrous consequences.

We are establishing some profiles/contexts/classes with API-Records for data, such as: in-situ, satellite imagery, radar, ship or aircraft based, etc)

[jeffharrison]

The Routes SWG discussed this on 8 June 2021. The Group recognizes the need for this type of Extension.

Observation: This might be integrated into the 'Mode' parameter that we just added (?)

SWG discussed and this will be advanced as an Extension to Core (perhaps a Parameter).