Detect Incidents

DetectIncidents

The Detect Incidents task works with a time-enabled layer of points, lines, areas, or tables that represents an instant in time. Using sequentially ordered features, called tracks, this tool determines which features are incidents of interest. Incidents are determined by conditions that you specify. First, the tool determines which features belong to a track using one or more fields. Using the time at each feature, the tracks are ordered sequentially and the incident condition is applied. Features that meet the starting incident condition are marked as an incident. You can optionally apply an ending incident condition; when the end condition is true, the feature is no longer an incident. The results will be returned with the original features with new columns representing the incident name and indicate which feature meets the incident condition. You can return all original features, only the features that are incidents, or all of the features within tracks where at least one incident occurred.

For example, suppose you have GPS measurements of hurricanes every 10 minutes. Each GPS measurement records the hurricane's name, location, time of recording, and wind speed. Using these fields, you could create an incident where any measurement with a wind speed greater than 208 km/h is an incident titled Catastrophic. By not setting an end condition, the incident would end if the feature no longer meets the start condition (wind speed slows down to less than 208).

Using another example, suppose you were monitoring concentrations of a chemical in your local water supply using a field called contanimateLevel. You know that the recommended levels are less than 0.01 mg/L, and dangerous levels are above 0.03 mg/L. To detect incidents, where a value above 0.03mg/L is an incident, and remains an incident until contamination levels are back to normal, you create an incident using a start condition of contanimateLevel > 0.03 and an end condition of contanimateLevel < 0.01. This will mark any sequence where values exceed 0.03mg/L until they return to a value less than 0.01.

Request URL

http://<analysis url>/DetectIncidents/submitJob

Request parameters

Parameter

Description

inputLayer

(Required)

The table, point, line or polygon features containing potential incidents.

Syntax: As described in detail in the Feature input topic, this parameter can be one of the following:

  • A URL to a feature service layer with an optional filter to select specific features
  • A URL to a big data catalog service layer with an optional filter to select specific features
  • A feature collection

trackFields

(Required)

The fields used to identify distinct tracks. There can be multiple trackFields.

REST Web Examples:

  • Hurricane Name
  • BoatName, ConvoyID

REST Scripting Examples:

  • "trackFields" : "Hurricane Name"
  • "trackFields" : "BoatName, ConvoyID"

startConditionExpression

(Required)

The condition used to identify incidents. If there is no endConditionExpression specified, any feature that meets this condition is an incident. If there is an end condition, any feature that meets the startConditionExpression and does not meet the endConditionExpression is an incident. startConditionExpression uses Arcade expressions.

REST Web Examples:

  • $feature["wind_speed"] > 111
  • $feature["speed"] > 7820 && $feature["height"] < 1000

REST Scripting Examples:

  • "startConditionExpression" : "$feature["wind_speed"] > 111"
  • "startConditionExpression" : "$feature["speed"] > 7820 and $feature["height"] < 1000"

endConditionExpression

The condition used to identify incidents. If there is no endConditionExpression specified, any feature that meets this condition is an incident. If there is an end condition, any feature that meets the startConditionExpression and does not meet the endConditionExpression is an incident. endConditionExpression uses Arcade expressions.

REST Web Examples:

  • $feature["wind_speed"] < 209
  • $feature["speed"] > 7820 and $feature["height"] < 500

REST Scripting Examples:

  • "startConditionExpression" : "$feature["wind_speed"] > 209"
  • "startConditionExpression" : "$feature["speed"] > 7820 and $feature["height"] < 500"

outputMode

Determines which features are returned. Two modes are available:

  • AllFeatures—All of the input features are returned.
  • Incidents—Only features that were found to be incidents are returned.

REST Web Examples:

  • AllFeatures
  • Incidents

REST Scripting Examples:

  • "outputMode" : "AllFeatures"
  • "outputMode" : "Incidents"

outputName

(Required)

The task will create a feature service of the results. You define the name of the service.

Rest Web Example:

  • HurricaneIncidents

REST Scripting Example:

  • "outputName" : "HurricaneIncidents"

context

Context contains additional settings that affect task execution. For this task, there are three settings:

  • Extent (extent)—A bounding box that defines the analysis area. Only those features that intersect the bounding box will be analyzed.
  • Processing spatial reference (processSR)—The features will be projected into this coordinate system for analysis.
  • Output spatial reference (outSR)—The features will be projected into this coordinate system after the analysis to be saved. The output spatial reference for the spatiotemporal big data store is always WGS84.
  • Data store (dataStore)— Results will be saved to the specified data store. The default is the spatiotemporal big data store.

Syntax:
{
"extent" : {extent},
"processSR" : {spatial reference},
"outSR" : {spatial reference},
"dataStore":{data store}
}

f

The response format. The default response format is html.

Values: html | json

Response

When you submit a request, the service assigns a unique job ID for the transaction.

Syntax:
{
"jobId": "<unique job identifier>",
"jobStatus": "<job status>"
}

After the initial request is submitted, you can use jobId to periodically check the status of the job and messages as described in Checking job status. Once the job has successfully completed, use the jobId to retrieve the results. To track the status, you can make a request of the following form:

Accessing results

When the status of the job request is esriJobSucceeded, you can access the results of the analysis by making a request of the following form:

http://<analysis url>/DetectIncidents/jobs/<jobId>/results/output?token=<your token>&f=json

Parameter

Description

output

The output features will be the same type of feature as the input. Tables are tables, points are points, lines are lines, and polygons are polygons. There will be two new fields:

  • IncidentID—This is a unique ID for each incident.
  • IncidentStatus—This is the status of the incident. The status can be null if the feature is not an incident, Started when an incident begins, OnGoing while the incident condition is still being met, and Ended when the condition is no longer met. In a single track, there can be multiple strings of incidents.
Example:
{"url": 
"http://<analysis url>/DetectIncidents/jobs/<jobId>/results/output"}

The result has properties for parameter name, data type, and value. The contents of value depend on the outputName parameter provided in the initial request. The value contains the URL of the feature service layer.

{
"paramName":"output", 
"dataType":"GPRecordSet",
"value":{"url":"<hosted featureservice layer url>"}
}

See Feature output for more information about how the result layer is accessed.

9/13/2017