- URL:https://<geoanalytics-url>/SnapTracks
- Version Introduced:11.0
Description
The SnapTracks task matches track points to polylines and requires the following input layers:
- pointLayer—The input point layer must be time-enabled observations that represent an instant in time. Track observations that do not have a valid time stamp will be excluded from analysis.
- polylineLayer—The input polyline layer must contain fields with the following
connectivity information and must be specified in the
connectivityFieldMatching
parameter:
- polylineID—The unique identifier for the polyline
- fromNodeID—The node where a polyline begins
- toNodeID—The node where a polyline ends
The spatial reference of the inputPoints must be the same as the spatial reference of the inputLines. If the datasets have different spatial references, specify an output coordinate system or project for the datasets prior to analysis.
SnapTracks determines which point features belong to a track using an identifier. Using the time at each location, the tracks are ordered sequentially and analyzed to find the polyline feature they match.
For example, you have GPS measurements of delivery vehicles every 30 seconds. Each GPS measurement records the vehicle ID, location, and time. You can match the GPS points to polylines to more accurately determine which areas delivery trucks are servicing and which locations could have more delivery resources allocated.
The following table outlines terminology used in the SnapTracks task:
Term | Description |
---|---|
Track | A sequence of features that are time-enabled with time type instant. Features are determined to be in sequence using a track identifier field and their order in time. For example, a city could have a fleet of snow plow trucks that record their location every 30 seconds. The vehicle ID could represent the distinct tracks. |
Observation | A point in a track. |
Node | The end vertices of polyline features used to indicate the direction of the polyline. The start of the polyline is the from node and the end of the polyline is the to node. |
Direction | The direction of a polyline. Direction refers to how a polyline can be travelled between the from node and to node. |
Connectivity | Connectivity describes how polylines are connected to represent a traversable network. Polylines are connected based on their from node and to node values. Polylines that cannot be reached by a point, based on connectivity, will not be considered a match. |
Traversable | Polylines are traversable if they are connected by common nodes. For example, if the from node of polyline A is the same as the to node for polyline B, they are traversable. |
Request parameters
Parameter | Details |
---|---|
pointLayer (Required) | The track point features that will be matched to polylines. Syntax: As described in Feature input, this parameter can be one of the following:
REST examples
|
polylineLayer (Required) | The polyline features to which track points will be matched. Syntax: As described in Feature input, this parameter can be one of the following:
REST examples
|
trackFields (Required) | The fields used to identify distinct tracks. There can be multiple trackFields. REST examples
|
polylineFieldsToInclude
(Optional) | One or more fields from the polyineLayer that will be included in the output result. REST examples
|
connectivityFieldMatching
(Required) | The polyline layer fields that will be used to define the connectivity of the input polyline features. The following values are required:
REST examples
|
directionFieldMatching
(Optional) | The polyline layer field and attribute values that will be used to define the direction of the input polyline features. For example, a polyline layer has a field named direction with values T (backward), F (forward), B (both), and "" (none). If not specified, it is assumed the polyline is bidirectional. REST examples
|
searchDistance (Required) | The maximum distance allowed between a point and any polyline to be considered a match. It is recommended that you use values less than or equal to 50 meters. Larger distances will result in a longer process time and less accurate results. REST Examples
|
searchDistanceUnit (Required) | The searchDistance unit. REST Examples
|
distanceMethod (Required) | The method used to calculate search distances between points and lines. There are two methods: Geodesic and Planar. The Geodesic method calculates distances geodesically and will allow tracks to cross the antimeridian. This method is appropriate for large areas and any geographic coordinate system. This is the default. The Planar method calculates distances using a plane method and will not cross the antimeridian. REST examples
|
outputMode (Required) | Specifies whether all input features are returned or only the input features that were matched to a line feature. REST examples
|
timeSplit (Optional) | A time duration used to split tracks. Any features in the pointLayer that are in the same track and are farther apart than this time will be split into a new track. The units of the distance values are supplied by the timeSplitUnit parameter. If both distanceSplit and timeSplit are used, a track is split when at least one condition is met. REST examples
|
timeSplitUnit (Required if timeSplit is specified) | The temporal unit to be used with the temporal distance value specified in timeSplit. Values: Milliseconds | Seconds | Minutes | Hours | Days | Weeks| Months | Years REST examples
|
distanceSplit (Optional) | A distance used to split tracks. Any features in the pointLayer that are in the same track and are farther apart than this distance will be split into a new track. The units of the distance values are supplied by the distanceSplitUnit parameter. If both distanceSplit and timeSplit are used, the track is split when at least one condition is met. REST examples
|
distanceSplitUnit (Required if distanceSplit is specified) | The distance unit to be used with the distance value specified in distanceSplit. Values: Meters | Kilometers | Feet | FeetInt | FeetUS | Miles | MilesInt | MilesUS | NauticalMiles | NauticalMilesInt | NauticalMilesUS | Yards | YardsInt | YardsUS REST examples
|
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. REST examples
|
timeBoundarySplitUnit (Required if timeBoundarySplit is specified) | 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
|
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
|
outputName (Required) | The task will create a feature service of the results. You define the name of the service. REST examples
|
context (Optional) | The context parameter contains additional settings that affect task execution. For this task, there are four settings:
|
f | The response format. The default response format is html. Values: html | json |
Example usage
The following is a sample request URL for SnapTracks:
https://machine.domain.com/webadaptor/rest/services/System/GeoAnalyticsTools/GPServer/SnapTracks/submitJob?pointLayer={"url":"https://webadaptor.domain.com/server/rest/services/DeliveryTracks/0"}&polylineLayer={"url":"https://webadaptor.domain.com/server/rest/services/Roads/0"}&trackFields=TruckID&polylineFieldsToInclude=Street,Speed&connectivityFieldMatching={"polylineId":"streetname","fromNode":"fromnodeid","toNode":"tonodeid"}&directionFieldMatching={"directionField":"dirtravel","forwardValue":"F","backwardValue":"T","noneValue":"","bothValue":"B"}&searchDistance=5&searchDistanceUnit=Meters&distanceMethod=Geodesic&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.
{
"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>/SnapTracks/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>/SnapTracks/jobs/<jobId>/results/output?token=<your token>&f=json
Response | Description |
---|---|
output | The output contains points snapped to the nearest location along the polyline it matched. The polyline features are not returned. The unique identifier of the polyline dataset will be available for matched results. The unique identifier field is specified using the connectivityFieldMatching parameter. You can identify which polylines were matched to by referencing this field. In addition to any polyLineFieldsToInclude, and the fields from the inputPoints, the following fields will be returned:
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. See Feature output for more information about how the result layer is accessed. |