Make Closest Facility Layer (Network Analyst)
Summary
Makes a closest facility network analysis layer and sets its analysis properties. A closest facility analysis layer is useful in determining the closest facility or facilities to an incident based on a specified network cost.
Note:The Find Closest Facilities and Make Closest Facility Layer tools are similar, but they are designed for different purposes. Use Find Closest Facilities if you are setting up a geoprocessing service; it simplifies the setup process. Otherwise, use Make Closest Facility Layer.
To create a closest facility geoprocessing service using Find Closest Facilities, you only need to set up one tool, and you can publish the tool directly as a service. In contrast, you need to create a model with the Make Closest Facility Layer tool, properly connect it to various other tools, and publish the model to create a closest-facility geoprocessing service. See Overview of the Network Analyst geoprocessing service examples to learn how to set up a closest facility service using tutorial data. One other option to consider is the ArcGIS Online Closest Facility service. It is a service that runs like a geoprocessing tool within ArcMap, can be accessed from other applications, and includes high quality road data for much of the world.
Usage
-
After creating the analysis layer with this tool, you can add network analysis objects to it using the Add Locations tool, solve the analysis using the Solve tool, and save the results on disk using Save To Layer File tool.
-
When using this tool in geoprocessing models, if the model is run as a tool, the output network analysis layer must be made a model parameter; otherwise, the output layer is not added to the table of contents in ArcMap.
Syntax
| Parameter | Explanation | Data Type |
in_network_dataset |
The network dataset on which the closest facility analysis will be performed. | Network Dataset Layer |
out_network_analysis_layer |
Name of the closest facility network analysis layer to create. | String |
impedance_attribute |
The cost attribute to be used as impedance in the analysis. | String |
travel_from_to (Optional) |
Specifies the direction of travel between facilities and incidents.
Using this option can find different facilities on a network with one-way restrictions and different impedances based on direction of travel. For instance, a facility may be a 10-minute drive from the incident while traveling from the incident to the facility, but while traveling from the facility to the incident, it may be a 15-minute journey because of different travel time in that direction. Fire departments commonly use the TRAVEL_FROM setting since they are concerned with the time it takes to travel from the fire station (facility) to the location of the emergency (incident). A retail store (facility) is more concerned with the time it takes the shoppers (incidents) to reach the store; therefore, stores commonly use the TRAVEL_TO option. | String |
default_cutoff (Optional) |
Default impedance value at which to stop searching for facilities for a given incident. The default can be overridden by specifying the cutoff value on incidents when the TRAVEL_TO option is used or by specifying the cutoff value on facilities when the TRAVEL_FROM option is used. | Double |
default_number_facilities_to_find (Optional) |
Default number of closest facilities to find per incident. The default can be overridden by specifying a value for the TargetFacilityCount property on the incidents. | Long |
accumulate_attribute_name [accumulate_attribute_name,...] (Optional) | List of cost attributes to be accumulated during analysis. These accumulation attributes are purely for reference; the solver only uses the cost attribute specified by the Impedance attribute parameter to calculate the route. For each cost attribute that is accumulated, a Total_[Impedance] property is added to the routes that are output by the solver. | String |
UTurn_policy (Optional) |
The U-Turn policy at junctions. Allowing U-turns implies the solver can turn around at a junction and double back on the same street. Given that junctions represent street intersections and dead ends, different vehicles may be able to turn around at some junctions but not at others—it depends on whether the junction represents an intersection or dead end. To accommodate, the U-turn policy parameter is implicitly specified by how many edges connect to the junction, which is known as junction valency. The acceptable values for this parameter are listed below; each is followed by a description of its meaning in terms of junction valency.
 Tip:If you need a more precisely defined U-turn policy, consider adding a global turn delay evaluator to a network cost attribute, or adjusting its settings if one exists, and pay particular attention to the configuration of reverse turns. Also, look at setting the CurbApproach property of your network locations. | String |
restriction_attribute_name [restriction_attribute_name,...] (Optional) |
List of restriction attributes to apply during the analysis. | String |
hierarchy (Optional) |
The parameter is not used if a hierarchy attribute is not defined on the network dataset used to perform the analysis. In such cases, use "#" as the parameter value. | Boolean |
hierarchy_settings (Optional) |
 Legacy:Prior to version 10, this parameter allowed you to change the hierarchy ranges for your analysis from the default hierarchy ranges established in the network dataset. At version 10, this parameter is no longer supported and should be specified as an empty string. If you wish to change the hierarchy ranges for your analysis, update the default hierarchy ranges in the network dataset. | Network Analyst Hierarchy Settings |
output_path_shape (Optional) | Specifies the shape type for the route features that are output by the analysis.
No matter which output shape type is chosen, the best route is always determined by the network impedance, never Euclidean distance. This means only the route shapes are different, not the underlying traversal of the network. | String |
time_of_day (Optional) |
Specifies the time and date at which the routes should begin or end. The interpretation of this value depends on whether Time of Day Usage is set to START_TIME or END_TIME. If you have chosen a traffic-based impedance attribute, the solution will be generated given dynamic traffic conditions at the time of day specified here. A date and time can be specified as 5/14/2012 10:30 AM. Instead of using a particular date, a day of the week can be specified using the following dates.
| Date |
time_of_day_usage (Optional) |
Indicates whether the value of the Time of Day parameter represents the arrival or departure time for the route or routes.
| String |
Code Sample
Execute the tool using only the required parameters.
network = "C:/Data/SanFrancisco.gdb/Transportation/Streets_ND"
arcpy.na.MakeClosestFacilityLayer(network, "ClosestFireStations", "TravelTime")
Execute the tool using all parameters.
network = "C:/Data/SanFrancisco.gdb/Transportation/Streets_ND"
arcpy.na.MakeClosestFacilityLayer(network, "ClosestHospitals", "TravelTime",
"TRAVEL_TO", 5 ,3, ["Meters", "TravelTime"],
"ALLOW_UTURNS", ["Oneway"], "USE_HIERARCHY",
"", "TRUE_LINES_WITH_MEASURES")
The following stand-alone Python script demonstrates how the MakeClosestFacilityLayer tool can be used to find the closest warehouse from the store locations.
# Name: MakeClosestFacilityLayer_Workflow.py
# Description: Find the closest warehouse from the store locations and save the
# results to a layer file on disk.
# Requirements: Network Analyst Extension
#Import system modules
import arcpy
from arcpy import env
import os
try:
#Check out the Network Analyst extension license
arcpy.CheckOutExtension("Network")
#Set environment settings
env.workspace = r"C:/data/Paris.gdb"
env.overwriteOutput = True
#Set local variables
inNetworkDataset = r"Transportation/ParisMultimodal_ND"
outNALayerName = "ClosestWarehouse"
impedanceAttribute = "Drivetime"
accumulateAttributeName = ["Meters"]
inFacilities = r"Analysis/Warehouses"
inIncidents = r"Analysis/Stores"
outLayerFile = os.path.join(r"C:/data/output", outNALayerName + ".lyr")
#Create a new closest facility analysis layer. Apart from finding the drive
#time to the closest warehouse, we also want to find the total distance. So
#we will accumulate the "Meters" impedance attribute.
NAResultObject = arcpy.na.MakeClosestFacilityLayer(inNetworkDataset,outNALayerName,
impedanceAttribute,"TRAVEL_TO",
"",1, accumulateAttributeName,
"NO_UTURNS")
#Get the layer object from the result object. The closest facility layer can
#now be referenced using the layer object.
outNALayer = NAResultObject.getOutput(0)
#Get the names of all the sublayers within the closest facility layer.
subLayerNames = arcpy.na.GetNAClassNames(outNALayer)
#Stores the layer names that we will use later
facilitiesLayerName = subLayerNames["Facilities"]
incidentsLayerName = subLayerNames["Incidents"]
#Load the warehouses as Facilities using the default field mappings and
#search tolerance
arcpy.na.AddLocations(outNALayer, facilitiesLayerName, inFacilities, "", "")
#Load the Stores as Incidents. Map the Name property from the NOM field
#using field mappings
fieldMappings = arcpy.na.NAClassFieldMappings(outNALayer, incidentsLayerName)
fieldMappings["Name"].mappedFieldName = "NOM"
arcpy.na.AddLocations(outNALayer, incidentsLayerName, inIncidents,
fieldMappings,"")
#Solve the closest facility layer
arcpy.na.Solve(outNALayer)
#Save the solved closest facility layer as a layer file on disk with
#relative paths
arcpy.management.SaveToLayerFile(outNALayer,outLayerFile,"RELATIVE")
print "Script completed successfully"
except Exception as e:
# If an error occurred, print line number and error message
import traceback, sys
tb = sys.exc_info()[2]
print "An error occured on line %i" % tb.tb_lineno
print str(e)