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.

NoteNote:

Detect Incidents was introduced in ArcGIS Enterprise 10.6.

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 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 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 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 && $feature["height"] < 1000"

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

REST web examples:

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

REST scripting examples:

  • "startConditionExpression" : "$feature["wind_speed"] > 209"
  • "startConditionExpression" : "$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 features that were found to be incidents are returned.

REST web examples:

  • AllFeatures
  • Incidents

REST scripting examples:

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

timeBoundarySplit

(Optional)

A time boundary allows your to analyze values within a defined time span. For example, if you use a time boundary of 1 day, starting on January 1st, 1980 tracks will be analyzed 1 day at a time. The time boundary parameter was introduced in ArcGIS Enterprise 10.7.

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.

Learn

REST scripting example: "timeBoundarySplit" : 1

REST web example: 2

timeBoundarySplitUnit

(Optional)

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

REST scripting example: "timeBoundarySplitUnit" : "Days"

REST web example: 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 scripting example: "timeBoundaryReference" : 946684800000

REST web example: 9466835800000

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

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

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 jobId to retrieve the results. To track the status, you can make a request of the following form:

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

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.

Copyright © 1995-2019 Esri. All rights reserved.