Skip To Content
ArcGIS Developer
Dashboard

Detect Incidents

Description

DetectIncidents

The DetectIncidents task works with a time-enabled layer of points, lines, areas, or tables that represent 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 features that are incidents, or all of the feature 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 great than 209 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 speeds 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 containmentLevel. 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.03 mg/L is an incident, and remains an incident until contamination levels are back to normal, you create an incident using a start condition of containmateLevel > 0.03 and an end condition of containementLevel < 0.01. This will mark any sequence where values exceed 0.03mg/L until they return to a value less than 0.01.

Request parameters

ParameterDetails
inputLayer

(Required)

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

Syntax: As described in Feature input, 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

REST Examples

//REST web example
{"url": "https://myportal.domain.com/server/rest/services/Hosted/hurricaneTrack/FeatureServer/0", "filter":"Month = 'September'"}

//REST scripting example
"inputLayer":{"url": "https://myportal.domain.com/server/rest/services/Hosted/hurricaneTrack/FeatureServer/0", "filter":"Month = 'September'"}
trackFields

(Required)

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

REST Examples

//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. The startConditionExpression parameter uses Arcade expressions.

REST Examples

//REST web example
$feature["wind_speed"] > 111

//REST scripting example
"startConditionExpression": "$feature["wind_speed"] > 111"
endConditionExpression

(Optional)

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. The endConditionExpression parameter uses Arcade expressions.

REST Examples

//REST web example
$feature["speed"] > 7820 && $feature["height"] < 500

//REST scripting example
"endConditionExpression": "$feature["speed"] > 7820 && $feature["height"] < 500"
outputMode

(Optional)

Determines which features are returned. Two modes are available:

  • AllFeatures—All of the input features are returned. This is the default.
  • Incidents—Only feature that were found to be incident are returned.

REST Examples

//REST web example
AllFeatures

//REST scripting example
"outputMode": "AllFeatures"
timeBoundarySplit

(Optional)

A time boundary allows you to analyze values within a defined time span. For example, if you use a time boundary of 1 day, starting on January 1, 1980, tracks will be analyzed one day at a time.

The timeBoundarySplit parameter defines the scale of the time boundary. In the case above, this would be 1. See the portal documentation for this tool to learn more.

REST Examples

//REST web example
2

//REST scripting example
"timeBoundarySplit": 2
timeBoundarySplitUnit

(Optional)

The unit applied to the time boundary. timeBoundarySplitUnit is required if a timeBoundarySplit is provided.

Values: Milliseconds | Seconds | Minutes | Hours | Days | Weeks| Months | Years

REST Examples

//REST web example
Weeks

//REST scripting example
"timeBoundarySplitUnit": "Weeks"
timeBoundaryReference

(Optional)

A date that specifies the reference time to align the time boundary to, represented in milliseconds from epoch. The default is January 1, 1970, at 12:00 a.m. (epoch time stamp 0). This option is only available if the timeBoundarySplit and timeBoundarySplitUnit are set.

REST Examples

//REST web example
9466835800000

//REST scripting example
"timeBoundaryReference": 946684800000
outputName

(Required)

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

REST Examples

//REST web example
HurricaneIncidents

//REST scripting example
"outputName": "HurricaneIncidents"
context

(Optional)

The context parameter contains additional settings that affect task execution. For this task, there are four 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

Example usage

Below is a sample request URL for DetectIncidents:

https://webadaptor.domain.com/server/rest/services/System/GeoAnalyticsTools/GPServer/DescribeDataset/submitJob?inputLayer={"url":"https://webadaptor.domain.com/server/rest/services/Hurricane/hurricaneTrack/0"}&trackFields=Hurricane Name&startConditionExpression=$feature["wind_speed"] > 111&endConditionExpression=$feature["speed"] > 7820 && $feature["height"] < 500&outputMode=Incidents&timeBoundarySplit=2&timeBoundarySplitUnit=Hours&timeBoundaryReference=946684800000&outputName=myOutput&context={"extent":{"xmin":-122.68,"ymin":45.53,"xmax":-122.45,"ymax":45.6,"spatialReference":{"wkid":4326}}}&f=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 Check job status. Once the job has successfully completed, use jobId to retrieve the results. To track the status, you can make a request of the following form:

https://<analysis url>/DetectIncidents/jobs/<jobId>

Access 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:

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

ResponseDescription
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.
{"url": "https://<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.