Create Drive-Time Areas

The Create Drive-Time Areas task creates areas that can be reached within a given drive time or drive distance.

It can help you answer questions such as:

How far can I drive from here in five minutes?
What areas are covered within a three-mile drive distance of my stores?
What areas are within four minutes of our fire stations?

Note:

This task is designed to provide a simple solution to the most common uses of drive-time areas. If you require additional flexibility to solve a more specialized problem, consider using either the Service Area Service with Asynchronous Execution or Service Area Service with Synchronous Execution instead. They provide options, for instance, to create more detailed polygons, specify travel towards the input points rather than away from them, and add barriers to block certain roads or areas.

Licensing

As described in the Get Started topic, in order to use any analysis task, the administrator of the organization needs to grant you certain basic privileges. To use Create Drive-Time Areas, you also need to be granted the Network Analysis privilege.

Limits

There are limits to the number of features and drive time or drive distance.

inputLayer—maximum 1,000 features
pointBarrierLayer—Maximum 250 features.
lineBarrierLayer—An error will occur if the number of street features intersected by all the line barriers exceeds 500.
polygonBarrierLayer—An error will occur if the number of street features intersected by all the polygon barriers exceeds 2000.
Travel times cannot exceed 9 hours 9 hours (540 minutes) when walking or 5 hours (300 minutes) for all other travel times.
Travel distances cannot exceed 27 miles (43.45 kilometers) when walking or 300 miles (482.80 kilometers) for all other travel distances.
When generating holes or reachable streets, travel times cannot exceed 5 hours (300 minutes) when walking or 15 minutes for all other travel times.
When generating holes or reachable streets, travel distances cannot exceed 15 miles (24.14 kilometers).
An error will occur if the tool takes more than 2 hour (7,200 seconds) to execute when using travel modes. If this error occurs, try rerunning the analysis with fewer input features.

Request URL

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

Request Parameters

Parameter Details

inputLayer

(Required)

The points around which travel areas based on a mode of transportation will be drawn.

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 feature collection

Examples:

{"url": <feature service layer url>, "filter": <where clause>}
{"layerDefinition": {}, "featureSet": {}, "filter": <where clause>}

travelMode

Specify the mode of transportation for the analysis.

Travel modes are managed in ArcGIS Online and can be configured by the administrator of your organization to better reflect your organization's workflows. You must specify the JSON object containing the settings for a travel mode supported by your organization. To get a list of supported travel modes, run the GetTravelModes operation from the Utilities service.

Use a JSON object representing travel mode settings for the travelMode parameter value. When you use the GetTravelModes operation from the Utilities service, the result is a string representing the travel mode JSON. You must convert this string to a valid JSON object using the API and pass the JSON object as the value for the travelMode parameter.

For example, the following is a string representing the Walking Time travel mode as returned by the GetTravelModes operation:

"{\"attributeParameterValues\": [{\"parameterName\": \"Restriction Usage\", \"attributeName\": \"Walking\", \"value\": \"PROHIBITED\"}, {\"parameterName\": \"Restriction Usage\", \"attributeName\": \"Preferred for Pedestrians\", \"value\": \"PREFER_LOW\"}, {\"parameterName\": \"Walking Speed (km/h)\", \"attributeName\": \"WalkTime\", \"value\": 5}], \"description\": \"Follows paths and roads that allow pedestrian traffic and finds solutions that optimize travel time. The walking speed is set to 5 kilometers per hour.\", \"impedanceAttributeName\": \"WalkTime\", \"simplificationToleranceUnits\": \"esriMeters\", \"uturnAtJunctions\": \"esriNFSBAllowBacktrack\", \"restrictionAttributeNames\": [\"Preferred for Pedestrians\", \"Walking\"], \"useHierarchy\": false, \"simplificationTolerance\": 2, \"timeAttributeName\": \"WalkTime\", \"distanceAttributeName\": \"Miles\", \"type\": \"WALK\", \"id\": \"caFAgoThrvUpkFBW\", \"name\": \"Walking Time\"}"

Convert the value above to a valid JSON object and pass it as the value for the travelMode parameter.

travelMode=

{
  "attributeParameterValues": [
    {
      "parameterName": "Restriction Usage",
      "attributeName": "Walking",
      "value": "PROHIBITED"
    },
    {
      "parameterName": "Restriction Usage",
      "attributeName": "Preferred for Pedestrians",
      "value": "PREFER_LOW"
    },
    {
      "parameterName": "Walking Speed (km\/h)",
      "attributeName": "WalkTime",
      "value": 5
    }
  ],
  "description": "Follows paths and roads that allow pedestrian traffic and finds solutions that optimize travel time. The walking speed is set to 5 kilometers per hour.",
  "impedanceAttributeName": "WalkTime",
  "simplificationToleranceUnits": "esriMeters",
  "uturnAtJunctions": "esriNFSBAllowBacktrack",
  "restrictionAttributeNames": [
    "Preferred for Pedestrians",
    "Walking"
  ],
  "useHierarchy": false,
  "simplificationTolerance": 2,
  "timeAttributeName": "WalkTime",
  "distanceAttributeName": "Miles",
  "type": "WALK",
  "id": "caFAgoThrvUpkFBW",
  "name": "Walking Time"
}

breakValues

The size of the polygons to create. The units for breakValues is specified with the breakUnits parameter.

The numeric break value or values are passed in as an array of doubles. By setting many unique values in the array, polygons of different sizes are generated around each input location.

Examples:

"breakValues": [5.0]
"breakValues": [5.0, 10.0, 15.0]

breakUnits

The units of the breakValues parameter. The default is Minutes.

To create areas showing how far you can go along roads or walkways within a given time, specify a time unit. Alternatively, specify a distance unit to generate areas bounded by a maximum travel distance.

When the travelMode is time based, a time unit should be specified for the breakUnits. When the travelMode is distance based, a distance unit should be specified for the breakUnits

Example:"breakUnits": "Minutes"

overlapPolicy

Determines how overlapping areas are processed.

Values: Overlap | Dissolve | Split


	Overlap—Overlapping areas are kept. This is the default.
	Dissolve—Overlapping areas are combined by break value. Because the areas are dissolved, use this option when you need to know the areas that can be reached within a given time or distance, but you don't need to know which input points are nearest.
	Split—Overlapping areas are split in the middle. Use this option when you need to know the one nearest input location to the covered area.

Example: "overlapPolicy": "Split"

timeOfDay

Specify whether travel times should consider traffic conditions. To use traffic in the analysis, To use traffic in the analysis, set travelMode to a travel mode object whose impedanceAttributeName property is set to TravelTime, set breakUnits to a time unit and assign a value to timeOfDay. (A travel mode with other impedanceAttributeName values don't support traffic.). The timeOfDay value represents the time at which travel begins, or departs, from the input points. The time is specified as Unix time (milliseconds since midnight, January 1 1970).

The service supports two kinds of traffic: typical and live. Typical traffic references travel speeds that are made up of historical averages for each five-minute interval spanning a week. Live traffic retrieves speeds from a traffic feed that processes phone probe records, sensors, and other data sources to record actual travel speeds and predict speeds for the near future.

The Data Coverage page shows the countries Esri currently provides traffic data for.

Typical Traffic:

To ensure the task uses typical traffic in locations where it is available, choose a time and day of the week, and then convert the day of the week to one of the following dates from 1990:

Monday—1/1/1990
Tuesday—1/2/1990
Wednesday—1/3/1990
Thursday—1/4/1990
Friday—1/5/1990
Saturday—1/6/1990
Sunday—1/7/1990

Set the time and date as Unix time in milliseconds.

For example, to solve for 1:03 p.m. on Thursdays, set the time and date to 1:03 p.m., 4 January 1990; and convert to milliseconds (631458180000).

Note:

Although the dates representing days of the week are from 1990, typical traffic is calculated from recent traffic trends—usually over the last several months.

Live Traffic:

To use live traffic when and where it is available, choose a time and date and convert to Unix time.

Esri saves live traffic data for 4 hours and references predictive data extending 4 hours into the future. If the time and date you specify for this parameter is outside the 8-hour time window, or the travel time in the analysis continues past the predictive data window, the task falls back to typical traffic speeds.

Note:

All points in inputLayer need to be in the same time zone when using traffic and setting overlapPolicy to split or dissolve.
This parameter is ignored when breakUnits is set to distance unit.
The time zone for timeOfDay can be UTC or the time zone or zones in which the points in inputLayer are located. Specify time zones with the timeZoneForTimeOfDay parameter.

Syntax: The number of milliseconds since the Unix epoch (January 1, 1970).

Examples:

"timeOfDay":631458180000 // 13:03, 4 January 1990. Typical traffic on Thursdays at 1:03 p.m.
"timeOfDay": 631731600000 // 17:00, 7 January 1990. Typical traffic on Sundays at 5:00 p.m.
"timeOfDay": 1413964800000 // 8:00, 22 October 2014. If the current time is between 8:00 p.m., 21 Oct. 2014 and 8:00 p.m., 22 Oct. 2014, live traffic speeds are referenced in the analysis; otherwise, typical traffic speeds are referenced.
"timeOfDay": 1426674000000 // 10:20, 18 March 2015. If the current time is between 10:20 p.m., 17 Mar. 2015 and 10:20 p.m., 18 Mar. 2015, live traffic speeds are referenced in the analysis; otherwise, typical traffic speeds are referenced.

timeZoneForTimeOfDay

Specify the time zone or zones of the timeOfDay parameter. There are two options: GeoLocal (default) and UTC.

GeoLocal:

The timeOfDay value refers to the time zone or zones in which the input points are located. This option causes the analysis to have rolling start times across time zones.

GeoLocal Illustration: Setting timeOfDay to 9:00 a.m., 4 January 1990 (631443600000 milliseconds); timeZoneForTimeOfDay to GeoLocal; and submitting a valid request causes the drive times for points in the Eastern Time Zone to start at 9:00 a.m. Eastern Time and 9:00 a.m. Central Time for points in the Central Time Zone. (The start times are offset by an hour in real or UTC time.)

Input: timeOfDay is 9:00 a.m., 4 Jan. 1990 (631443600000 milliseconds), and timeZoneForTimeOfDay is set to GeoLocal

UTC:

The timeOfDay value refers to Coordinated Universal Time (UTC). The start times for all points are simultaneous, regardless of time zones.

UTC Illustration: Setting timeOfDay to 9:00 a.m., 4 January 1990 (631443600000 milliseconds) and timeZoneForTimeOfDay to UTC, the start time for points in the Eastern Time Zone is 4:00 a.m. Eastern Time and 3:00 a.m. Central Time for those in the Central Time Zone.

Input: timeOfDay is 9:00 a.m., 4 Jan. 1990 (631443600000 milliseconds), and timeZoneForTimeOfDay is set to UTC

Values: GeoLocal | UTC

pointBarrierLayer

Specify one or more point features that act as temporary restrictions (barriers) when traveling on the underlying streets.

A point barrier can model a fallen tree, an accident, a downed electrical line, or anything that completely blocks traffic at a specific position along the street. Travel is permitted on the street but not through the barrier.

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 feature collection

Examples:

{"url": <feature service layer url>, "filter": <where clause>}
{"layerDefinition": {}, "featureSet": {}, "filter": <where clause>}

lineBarrierLayer

Specify one or more line features that prohibit travel anywhere the lines intersect the streets.

A line barrier prohibits travel anywhere the barrier intersects the streets. For example, a parade or protest that blocks traffic across several street segments can be modeled with a line barrier.

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 feature collection

Examples:

{"url": <feature service layer url>, "filter": <where clause>}
{"layerDefinition": {}, "featureSet": {}, "filter": <where clause>}

polygonBarrierLayer

Specify one or more polygon features that completely restrict travel on the streets intersected by the polygons.

One use of this type of barrier is to model floods covering areas of the street network and making road travel there impossible.

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 feature collection

Examples:

{"url": <feature service layer url>, "filter": <where clause>}
{"layerDefinition": {}, "featureSet": {}, "filter": <where clause>}

travelDirection

Specify whether the direction of travel used to generate the travel areas is toward or away from the input locations.

Values: AwayFromFacility | TowardsFacility

Default: AwayFromFacility

The travel direction can influence how the areas are generated. CreateDriveTimeAreas will obey one-way streets, avoid illegal turns, and follow other rules based on the direction of travel. You should select the direction of travel based on the type of input locations and the context of your analysis. For example, the drive-time area for a pizza delivery store should be created away from the facility, whereas the drive-time area for a hospital should be created toward the facility.

showHoles

When set to true, the output areas will include holes if some streets couldn't be reached without exceeding the cutoff or due to travel restrictions imposed by the travel mode.

includeReachableStreets

When set to true, the output includes an additional layer that shows the streets used to create the drive-time areas.

CreateDriveTimeAreas measures the reach of a facility along the street network, then creates drive-time areas from the streets that were traveled. Therefore, the areas are an approximation of the traveled streets. If your analysis is to determine which streets are covered within a specific travel distance or time from a facility, generating reachable streets can be more accurate than using the drive-time areas to evaluate if a particular street was reachable.

outputName

If provided, the task will create a feature service of the results. You define the name of the service. If an outputName value is not provided, the task will return a feature collection.

Syntax:

{
  "serviceProperties": {
    "name": "<service name>"
  }
}

In ArcGIS Online or ArcGIS Enterprise 10.9.1 and later, you can overwrite an existing feature service by providing the itemId value of the existing feature service and setting the overwrite property to true. Including the serviceProperties parameter is optional. As described in the Feature output topic, you must either be the owner of the feature service or have administrative privileges to perform the overwrite.

Syntax:

{

  "itemProperties": {
			"itemId": "<itemID of the existing feature service>",
			"overwrite": true
	}
}

{
"serviceProperties": {
    "name": "<existing service name>"
  },
"itemProperties": {
				"itemId": "<itemID of the existing feature service>",
				"overwrite": true
	}
}

context

The Context parameter contains the following additional settings that affect task operation:

Extent (extent)—A bounding box that defines the analysis area. Only input features that intersect the bounding box will be analyzed.
Output spatial reference (outSR)—The output features will be projected into the output spatial reference.

Syntax:

{
"extent" : {extent},
"outSR" : {spatial reference}
}

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 the jobId to periodically check the status of the job and messages as described in the topic Checking job status. Once the job has successfully completed, you use the jobId to retrive the results. To track the status, you can make a request of the following form:

http://<analysis url>/CreateDriveTimeAreas/jobs/<jobId>

Accessing results

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

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


Parameter	Description
driveTimeAreasLayer	The output layer containing the areas that can be reached within the given driving time or driving distance from the points in the input layer. Example: `{"url": "http://<analysis url>/CreateDriveTimeAreas/jobs/<jobId>/results/driveTimeAreasLayer"}` The result has properties for parameter name, data type, and value. The contents of value depends on the outputName parameter provided in the initial request. If outputName was provided, value contains the url to the feature service layer. `{ "paramName":"driveTimeAreasLayer", "dataType":"GPString", "value":{"url":"<hosted featureservice layer url>"} }` If outputName was not provided, value contains a feature collection. `{ "paramName": "driveTimeAreasLayer", "dataType": "GPString", "value":{"layerDefinition": {}, "featureSet": {} } }` See Feature Output for more information about how the result layer or collection is accessed. Discussion: The result layer has the following attributes: FacilityOID—A number that relates each drive-time area back to the unique identifier of the point around which the area was generated. Name—The name of the drive-time area is the same as the name of the point location from which it was created followed by the from- and to-break values of the area. FromBreak—The travel distance or travel time from which the area begins. This is normally zero, since most travel time polygons start from the input point location. However, non-zero values are present when you specify multiple break values, because all but the first output areas would start from one of the break values. ToBreak—The travel distance or travel time at which the area ends. If the analysis includes multiple input break values, multiple ToBreakValues are included here but in different rows.
reachableStreetsLayer	The output layer containing the streets (also known as service area lines) that were used to create the drive-time areas. Example: `{"url": "http://<analysis url>/CreateDriveTimeAreas/jobs/<jobId>/results/reachableStreetsLayer"}` The result has properties for parameter name, data type, and value. The contents of value depends on the outputName parameter provided in the initial request. If outputName was provided, value contains the url to the feature service layer. `{ "paramName":"reachableStreetsLayer", "dataType":"GPString", "value":{"url":"<hosted featureservice layer url>"} }` If outputName was not provided, value contains a feature collection. `{ "paramName": "reachableStreetsLayer", "dataType": "GPString", "value":{"layerDefinition": {}, "featureSet": {} } }` See Feature Output for more information about how the result layer or collection is accessed. Discussion: The result layer has the following attributes: FacilityOID—A number that relates each reachable street back to the unique identifier of the point around which the drive-time area was generated. FromPosition—Specifies where along the underlying street feature the service area line begins. A value of 0 (zero) indicates the service area line begins at the from-point of the underlying street feature. A value of 1 indicates the service area line begins at the to-point of the street feature. A value between 0 and 1 indicates the line begins at a point along the underlying street feature; for example, a value of 0.25 means the line begins 25 percent along the digitized direction of the underlying street feature. ToPosition—Specifies where along the underlying street feature the service area line ends. A value of 0 (zero) indicates the service area line ends at the from-point of the underlying street feature. A value of 1 indicates the service area line ends at the to-point of the street feature. A value between 0 and 1 indicates the line ends at a point along the underlying street feature; for example, a value of 0.25 means the line ends 25 percent along the digitized direction of the underlying street feature. FromCumul_<Minutes \| Miles \| Kilometers>— For example, FromCumul_Minutes. The cumulative cost, in minutes, miles or kilometers of the path from the facility to the beginning of the line feature. ToCumul_<Minutes \| Miles \| Kilometers>— For example, ToCumul_Kilometers. The cumulative cost, in minutes, miles, or kilometers of the path from the facility to the end of the line feature. SourceOID—A number that relates each reachable street back to the unique identifier of the street feature. SourceName—The name of the street feature class from which the service area line was created.