Detect Incidents

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

1
2
3
4
//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

1
2
3
4
5
6
//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

1
2
3
4
//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

1
2
3
4
//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

1
2
3
4
//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

1
2
3
4
//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

1
2
3
4
//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

1
2
3
4
//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

1
2
3
4
//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:

1
2
3
4
5
6
{
  "extent": {extent},
  "processSR": {spatial reference},
  "outSR": {spatial reference},
  "dataStore": {data store}
}

f

The response format. The default response format is html .

Values: html | json | pjson

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.

1
{"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.

1
2
3
4
5
{
  "paramName": "output",
  "dataType": "GPRecordSet",
  "value":{"url": "<hosted featureservice layer url>"}
}

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