Do Alerts always have an end date?
Yes, Alerts always have a start and end date. The end date is the first full day after the expected end of an event or incident. You can find more information about this on our How to use the Alert API page.
What is the average reporting time for Alerts? (time taken between an incident occurring and a notification being issued)
This depends on several things, such as how soon our systems pick up the incident or the nature of the incidents happening that day, which determines their priority. However, for ‘breaking’ incidents, which present an immediate threat to traveller safety, we aim to send our first Alert within ten minutes of our notification of the incident. For all other incidents or events, we aim to publish an Alert within 20 minutes of being notified if it is high priority.
How is the impact radius established?
The “impact radius” is an estimate our analyst makes when writing an Alert.
The radius is an area of probable impact. However, not all areas within the radius will be impacted in reality.
For instance, if the analysts have a great degree of uncertainty about exactly where the report incident took place, this may increase the impact radius.
Examples:
- If we know a shooting took place at X School, then we can use a smaller radius (maybe 500m only)
- If we only know that a shooting took place somewhere near X Town, we will use a larger radius to include most or all of X Town and some surrounding area
Why do some Alerts have no radius?
If an Alert has no impact radius, it is because the impact is city, region or country-wide, and we will indicate in the title which city, region or country is impacted. You can find more details about the latest version of our Alerts here
In "impacted_areas", when would you use coordinates o and when would you use other types of impacted_areas?
In impacted_areas there can be only cities, only points, only countries, etc. or there can be a city and a point, for example (see the Fields section). We use coordinates when specific locations are known. We use city in the impact when we need to designate a larger geographic area than just a single point. For instance "Bus drivers strike across London" would be an example where the city code would be a better description of the geographic impact than any single coordinate. If we report "Protests across Mexico City" we may include the city code for Mexico City, as well as specific known geographic locations of protest with coordinates. A country-wide example would be "Protests planned across Serbia on 8 February", where we would include Serbia/RS in impacted_areas, indicating that the event in the Alert impacts the whole country, i.e. should be communicated to travellers across the whole country. By indicating the country in impacted_areas, we also mean that the impact is valid for all regions within the country, and all cities within the country but we will not also include those code/names in the Alert body.
Under "relations", would your always include coordinates?
In Relations, there will always be coordinates (latitude and longitude), but here those coordinates are meant to "pin" the Alert on a digital map. The relations section of each Alert can be used for cataloging or searching for Alerts, but is not a good match for notifying travellers/users.
Are there any cases when we would not get a Country code under "impacted_areas"?
The only time we use a country code in the impact section of an Alert, is when we judge that the event/incident in the Alert affects the entire country. However, in the "relations" section you will find the country code. "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 allows 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".
Are Subcategories present in all Alerts?
Subcategories are not mandatory fields, therefore, they are not present in al Alerts
Which field/s of the Json payload should be used to target the right people with each Alert?
The impacted_areas field. You can find more information hon ow to precisely target the right traveller with an Alert here
When would you send a PUT request?
We would send a PUT request, for corrections to Alerts (fact correction, typo correction). Corrections can be made to: text, Risk Level, Category or sub-category, airport codes, or we can do a minor latitude/longitude adjustment. We will not change dates or the impacted country or city, such things are seen as major corrections and would warrant a DELETE and new POST.
What is the procedure followed when an Alert is published with incorrect dates or country/city?
- A new Alert is created with the correct information and published (POST request). This Alert is not connected to the Parent/incorrect Alert (so an Alert ID will not show in the relations sections).
- Another new Alert is created with a relation to the incorrect Alert (therefore, an Alert ID will show in the relations section) to indicate a change in the original Alert. The word "-Correction" will be added to this Alert title. The Alert will have the same incorrect dates or country/city as the original. This Risk Level will be set as "Low". This Alert will then be published (POST request).
- The analyst will then - in this order - delete the "-Correction" Alert and then delete the original incorrect Alert (DELETE request).
What is the procedure followed when there is a “cancelled upcoming event” Alert? Eg. when an Alert has been sent weeks/months in advance for an upcoming event (eg. a protest or strike) and it was later postponed or cancelled.
In those cases the procedure is to:
- Create a new Alert with a new id (linked to the parent id of the original one)
- Make the original Alert inactive - so you would receive a PUT request
How do you treat updates to alerts? Do you change the ID and reference the original alert, or do you have a common key that points back to the original alert?
When a situation updates or evolves we send a new alert with its own unique ID. For example, we will send an Alert for an upcoming protest in Paris. When the protest is underway or if violence has erupted and the situation has changed we will send a new Alert. We include the wording 'Update' in the title of the Alert. In the API for the new Alert we will reference the 'parent' (first) Alert and its ID so the client can link the two together.