New Features in Alerts v4.0
Impact section:
Each Alert will communicate the impact of the reported incident or event to give a precise indication of the geographic areas and/or modes of transport that have been affected. The impact will be conveyed using standardised geographic locations, precise latitude and longitude and other important travel information, including origins, destinations, mode of travel and specific carriers involved.
Multiple precise locations:
Each Alert can have any number of precise locations to indicate incidents or events taking place in more than one area. Previous versions were limited to a single location (latitude, longitude and place name).
Radius:
For every precise location we will include an impact radius, which indicates the area where a traveller is potentially impacted by the incident or event.
Travel routes:
Within the Impact section, routes will communicate when travel is affected between specific origins and destinations. Routes are created from any named geographic location, which can include countries, regions, cities and specific airports.
Relations section:
Each Alert will have a list of all geographic locations included in the Alert, in the Impact section and all related higher level administrative divisions. This feature will allow clients to file, search for and display on a map Alerts as they see fit. For example, an Alert impacting only the city of "Paris" will also include in the relations data for region "Ile de France" and country "France".
Standardised geographic locations and travel:
Riskline will maintain databases for countries, territories, administrative regions, cities, airports and airlines. This standardised data will be used as a common reference of communication in the Alerts API and will be available for clients to sync.
How to use the new features
Users of the new features of Alerts v4.0 will be able to precisely target which travellers should receive an Alert; travellers that are unlikely to be impacted by an Alert will not.
Alerts v4.0 is very flexible, however, and can be adapted to suit different use cases. In general, the new features of Alerts v4.0 can be used in two different manners:
- Precise targeting of affected travellers: By matching a traveller's location and/or itinerary to information in the Alert's Impact section, only those travellers most likely to be affected by an incident or event will be notified. This method would be used for travellers who are only concerned with a narrow context of what's happening directly near them.
- Generally informing a wide group of travellers: By using the information in an Alert's Relations section, all travellers in certain geographic areas or using certain modes of transport will be notified about an incident or event that may affect them. This method would be used for travellers who like to know more about what's happening in a wider context.
How to: precisely target the right traveller with an Alert
Users can make use of new features in Alerts v4.0 to precisely target travellers with the information that is most likely to have a direct impact on them.
An Alert should be sent to a traveller when three conditions are met:
- The Alert is "active", meaning that the Impact described within is currently valid.
- The traveller is travelling between the Alert's Start and End dates (or is otherwise interested in receiving Alerts between specific dates).
- The traveller's location and/or itinerary match the information contained in the Alert's Impact section.
Active v Inactive Alerts
Alerts that are "Active" indicate that the Impact is valid.
Alerts that are "Inactive" indicate that the Impact is no longer valid. This can be because the Alert expired, i.e. the current date is past the End Date of the Alert. It can also mean that the incident or event has been cancelled, suspended, circumscribed, etc. An example of this could be when an overnight curfew was originally scheduled to last for one month, but authorities lifted the curfew after only one week. In this example, Riskline will maintain the original Alert indicating the month-long curfew in an inactive status and will publish an updated Alert, which will remain active through the end of the curfew period.
Alerts turn from "Active" to "Inactive" for one of two reasons:
- The current date is equal to or beyond an Alert's End Date
- Riskline changed an Alert's status to "Inactive" to indicate that the impact of the Alert is no longer in effect. The Alert will remain visible but because the impact is no longer in effect, Riskline recommends that the Alert should not be sent to travellers.
Technical note:
Riskline automatically inactivates Alerts on their End Date based on the locations selected:
- Asia-Pacific Alerts inactivated on End Date -1 at 19:00 GMT
- Europe, Middle East and Sub Saharan Africa on End Date at 00:00 GMT
- Americas on End Date at 07:00 GMT
For example, Alerts with an End Date of 4 July, would become inactive at:
- APAC, 3 July 19:00 GMT
- EMEA, 4 July 00:00 GMT
- AMER, 4 July 07:00 GMT
Alerts that involve multiple regions will remain active until the last region involved reaches the designated inactivation time.
Start and End Dates
Each Alert has a Start and an End date. The Start Date indicates the first day, in local time, that the incident or event takes place or is scheduled to take place. The End Date is the first full day after the incident or event ends or is scheduled to end.
For incidents that have already taken place, the Start Date is set as the day the event/incident took place and the End Date is set as the day after the event has stopped taking place.
Impact
The Impact data that now accompanies every Alert explains the specific geographic areas and/or modes of transport affected (or expected to be affected) by the incident or event described in an Alert.
The Impact data is first broken down into one of two types:
- "For All" meaning that the impact of the incident or event applies to everyone: travellers, commuters, shoppers, civilians, etc
- "For Travellers" meaning that the impact of the incident or event applies to only those engaged in travel. Riskline defines a traveller for the purpose of Alerts as individuals who booked a ticket between an origin and destination, typically via plane, long distance rail, intercity bus, interisland ferry, etc.
The remainder of the Impact data is broken down into:
Impacted Areas:
- Cities: major urban areas typically indicated by IATA code. Many, but not all, cities are included in Riskline's database.
- Regions: administrative level 1 geopolitical areas indicated by ISO 3166-2 codes.
- Countries and territories: administrative level 0 geopolitical areas indicated by ISO 3166 codes.
- Airports: civilian use airports indicated by IATA codes
- Specific locations: indicated by latitude, longitude and a place name
- Note 1: Users may request additions to these databases.
- Note 2: Riskline reserves the right to deviate from standardised codes in rare situations for operational reasons.
Travel Routes:
An origin and destination taken together to form a single route. Origins and destinations can be constructed from cities, regions, countries, territories or airports
Impacted Carriers Type:
The mode of transport affected
Impacted Carriers:
The specific carrier affected.
Note: Impact in a higher-level administrative area indicates an impact in constitutive lower level administrative areas. For example, an Alert impacting "Florida" indicates an impact on all the regions and cities within, such as "Miami", "Orlando", "Dade County", etc. Therefore when "Florida" is selected in an Alert's Impact section, these other areas of Florida will not appear in the section.
When all the elements of the Impact section are taken together, it can be read as a plain language explanation of the Alert's Impact. Some examples:
- This Alert impacts everyone located in Florida and Georgia.
- This Alert impacts everyone located within 500m of Trafalgar Square.
- This Alert impacts all travellers between Heathrow and Gatwick airports travelling by air on Ryanair.
- This Alert impacts all travellers in Italy travelling by rail.
Technical note:
The logical operators in Impact data function as follows:
- Impacted Area OR (Travel Route AND Carrier Type AND Carrier)
- Impacted Area OR ( ( Travel Route 1 OR Travel Route 2 ) AND Carrier Type AND Carrier)
An Alert for "Strike disrupts Ryanair flights at Heathrow and Gatwick Airports" would operate like:
( Heathrow Airport OR Gatwick Airport ) AND Aviation AND Ryanair
Or for "Flights cancelled from Heathrow to Paris CDG and Orly Airports" would be:
( Route LHR-CDG ) OR ( Route LHR-ORY ) AND Aviation
How to: generally target travellers with an Alert
Users of Alerts v4.0 can leverage the additional information contained in the Relations section to target travellers more generally.
There may be cases in which users may want to notify all travellers within an entire city, or even country, about what is happening around them. This is where the Relations section will be put to use. An example may clearly demonstrate this:
An Alert titled "Protesters block roads in Chicago's Loop area" would likely have a geographically limited Impact of a pin and radius within Chicago's Loop. Using that information only would result in travellers in central Chicago being notified about the Alert. However, the Alert's Relation section would also contain tags for the city of "Chicago", the region of "Illinois", and the country "United States of America". Users could then decide to notify travellers within any of these higher level geographic areas.
How to: use the Relations section for cataloguing, searching and displaying Alerts
The Relations section of each Alert can also be used to catalogue, search for and display Alerts in a user's system, portal, app, etc.
While the Impact section is narrowly focused, the Relations are more general, giving an indication of what the Alert is about. The Relations section format mirrors that of the Impact, with the addition of one type of relation:
- Related Alert: The title and unique ID of the "parent" Alert when there are one or more related Alerts. Typically this happens when an incident or event is updated, indicated by "- Update" in the title.
The remainder of the information in the Relations section is organised in the same format as the Impact section:
- Impacted Areas: Cities, regions (admin level 1), countries, territories and airport by name; one specific location by exact latitude and longitude
- Travel Routes: Origins and destinations that can include cities, regions, countries, territories and airport by name
- Impacted Carriers Type: The mode of transport affected
- Impacted Carriers: The specific carrier affected
Note: In the Relation section, only one specific location indicated by a single latitude and longitude will be given for each Alert. The purpose of this location is to allow the Alert to be pinned or displayed on a single location on a digital map.
Other Important Differences
There are other differences between the existing and new versions of the Alerts, besides those mentioned above. They include:
- Takes Place: Each Alert will now clearly indicate when the incident or event described takes place: past, now or future. This is selected in relation to the time of publication of the Alert. This replaces both "Is Notice?" and "Happening Now" fields in the existing Alerts.
- Offshore Areas: These include oceans, seas, gulfs, etc. When an incident or event happens offshore, and is not associated directly with a geographic location on land (country, city, etc) we will include the body of water in the Impact section.
- Real Effective Dates: Alerts will now reflect the actual start and end dates indicated in the text. Previous versions have truncated this time period because of legacy issues and to accommodate specific client systems. Events without a given end date, i.e. those seen as "indefinite", will receive an End Date one full day after the Start Date.