Créer une couche d’optimisation des tournées de véhicules (Network Analyst)
Récapitulatif
Crée une couche d'analyse de réseau d'optimisation des tournées de véhicules et définit ses propriétés d'analyse. Une couche d'optimisation des tournées de véhicules s'avère utile pour optimiser un ensemble de tournées au moyen d'une flotte de véhicules.
Remarque :Bien que similaires, les outils Créer une couche d'optimisation des tournées de véhicules et Résoudre la tournée de véhicules ont été conçus à des fins différentes. Faites appel à l'outil Résoudre la tournée de véhicules si vous configurez un service de géotraitement. Cela permettra de simplifier le processus de configuration. Sinon, utilisez l'outil Créer une couche d'optimisation des tournées de véhicules.
Pour créer un service de géotraitement de tournées de véhicules avec Résoudre la tournée de véhicules, il vous suffit de configurer un outil et de le publier en tant que service. En revanche, vous devez créer un modèle avec Créer une couche d'optimisation des tournées de véhicules, le connecter à d'autres outils et le publier pour créer un service.
Utilisation
Après avoir créé la couche d'analyse avec cet outil, vous pouvez y ajouter des objets d'analyse de réseau grâce à l'outil Ajouter des localisations, résoudre l'analyse à l'aide de l'outil Analyser et enregistrer les résultats sur le disque à l'aide de l'outil Enregistrer dans un fichier de couche.
-
Lorsque vous utilisez cet outil dans des modèles de géotraitement, si le modèle est exécuté en tant qu'outil, la couche d'analyse de réseau en sortie doit être convertie en paramètre de modèle. Dans le cas contraire, la couche en sortie n'est pas ajoutée à la table des matières d'ArcMap.
Syntaxe
| Paramètre | Explication | Type de données |
in_network_dataset |
Le jeu de données réseau sur lequel l'analyse de la tournée de véhicules est effectuée. Le jeu de données réseau doit avoir un attribut de coût basé sur le temps puisque le solveur de tournées de véhicules réduit le temps. | Network Dataset Layer |
out_network_analysis_layer |
Nom de la couche d'analyse de réseau de tournée de véhicules à créer. | String |
time_impedance |
Attribut de coût de temps utilisé pour définir le temps de traversée le long des éléments du réseau. L'attribut de coût de temps est obligatoire, car le solveur de tournées de véhicules réduit le temps. | String |
distance_impedance (Facultatif) |
Attribut de coût de distance utilisé pour définir la longueur le long des éléments du réseau. Cet attribut est facultatif. | String |
time_units (Facultatif) |
Unités de temps utilisées par les champs temporels des sous-couches et des tables de la couche d'analyse (classes d'analyse de réseau). Ces unités n'ont pas besoin d'être les mêmes que celles de l'attribut de coût de temps.
| String |
distance_units (Facultatif) |
Unités de distance utilisées par les champs de distance des sous-couches et des tables de la couche d'analyse (classes d'analyse de réseau). Ces unités n'ont pas besoin d'être les mêmes que celles de l'attribut de coût de distance facultatif.
| String |
default_date (Facultatif) |
Date implicite pour les valeurs de champs temporels n'ayant pas de date spécifiée avec l'heure. Si un champ temporel pour un objet d'ordre, tel que TimeWindowStart1, a une valeur d'heure uniquement, la date est supposée être la date par défaut. Par exemple, si un ordre a une valeur TimeWindowStart1 de 9h00 et si la date par défaut est le 6 mars 2013, la valeur de temps entière pour le champ est 9h00, le 6 mars 2013. La date par défaut n'a aucun effet sur les valeurs de champs temporels qui ont déjà une date. Le jour de la semaine peut aussi être spécifié en tant que date par défaut à l'aide des dates suivantes.
Si votre jeu de données réseau inclut des données de circulation, les résultats de l'analyse peuvent varier en fonction de la date que vous spécifiez ici. Par exemple, si l'on compare une tournée qui commence à 8h00 le dimanche, lorsqu'il n'y a pas beaucoup de circulation, à une tournée commençant à 8h00 le lundi, aux heures de pointe, la tournée du lundi prendra plus de temps. De plus, le meilleur trajet peut varier en fonction des conditions de circulation. | Date |
capacity_count (Facultatif) |
Nombre de dimensions de contrainte de capacité requises pour décrire les limites pertinentes des véhicules. Dans le cas d'une livraison d'ordre, chaque véhicule peut avoir une quantité limitée en poids et volume à transporter dans le cadre de limites physiques et légales. Dans ce cas, si vous effectuez le suivi du poids et du volume des ordres, vous pouvez utiliser ces deux capacités pour empêcher la surcharge des véhicules. Le nombre de capacités pour ce scénario est de deux (poids et volume). Selon le problème, vous pouvez avoir besoin d'effectuer le suivi de différents types ou quantités de capacités. Les capacités saisies dans les champs de capacité (DeliveryQuantities et PickupQuantities pour la classe Ordres et Capacities pour la classe Itinéraires) sont des chaînes de nombres séparés par des espaces, qui peuvent contenir le nombre maximal de valeurs spécifiées dans Nombre de capacités. Chaque dimension de capacité doit apparaître dans le même ordre de position pour toutes les valeurs des champs de capacités au sein de la même couche d'optimisation des tournées de véhicules. Les capacités étant elles-mêmes anonymes pour éviter de transposer accidentellement des dimensions de capacité, assurez-vous que les listes de capacités séparées par des espaces sont toujours saisies dans le même ordre pour toutes les valeurs de champs de capacité. | Long |
time_window_factor (Facultatif) |
Ce paramètre vous permet d'évaluer l'importance du respect des fenêtres horaires sans entraîner de violations. Une infraction de fenêtre horaire se produit quand un itinéraire arrive à un ordre, un dépôt ou une borne après la fermeture d'une fenêtre horaire. L'infraction est le laps de temps écoulé entre la fin de la fenêtre horaire et l'heure d'arrivée d'une tournée. La solution de tournées de véhicules peut changer en fonction de la valeur que vous sélectionnez pour le paramètre Importance de la violation des fenêtres horaires. La liste suivante présente la signification des valeurs et les variations de la solution de tournées de véhicules :
| String |
excess_transit_factor (Facultatif) |
Ce paramètre vous permet d'estimer l'importance de la réduction du temps de transit excessif. Le temps de transit excessif correspond à la quantité de temps dépassant le temps nécessaire pour effectuer le trajet direct entre une paire d'ordres. Le temps excessif découle de pauses ou de trajets vers d'autres ordres ou dépôts entres des visites à des ordres appariés. La solution de tournées de véhicules peut changer en fonction de la valeur que vous sélectionnez pour le champ Importance du temps de transit excessif. La liste suivante présente la signification des valeurs et les variations de la solution de tournées de véhicules :
| String |
UTurn_policy (Facultatif) |
Règle de demi-tour aux jonctions. L'autorisation des demi-tours implique que le solveur puisse faire demi-tour au niveau d'une jonction et revenir en arrière par la même rue. Dans la mesure où les jonctions représentent des intersections de rues et des voies sans issue, différents véhicules peuvent faire demi-tour à certaines jonctions mais pas à d'autres, selon que la jonction représente une intersection ou une voie sans issue. Pour en tenir compte, le paramètre de règle de demi-tour est spécifié implicitement par le nombre de tronçons connectés à la jonction, également connu sous le nom de "valence de jonction". Les valeurs acceptables pour ce paramètre sont répertoriées ci-dessous ; chacune est suivie d'une description de sa signification en termes de valence de jonction.
 Astuce:Si la définition de votre règle de demi-tour n'est pas suffisamment précise, envisagez d'ajouter un évaluateur de délai de tournant global à un attribut de coût de réseau ou de modifier ses paramètres, le cas échéant, en veillant tout particulièrement à la configuration des tournants inversés. Pensez également à définir la propriété CurbApproach de vos localisations réseau. | String |
restriction_attribute_name [restriction_attribute_name,...] (Facultatif) |
Liste des attributs de restriction à appliquer lors de l'analyse. | String |
hierarchy (Facultatif) |
Le paramètre n'est pas utilisé si un attribut de hiérarchie n'est pas défini sur le jeu de données réseau utilisé pour l'analyse. Dans ces cas, utilisez "#" comme valeur de paramètre. | Boolean |
hierarchy_settings (Facultatif) |
 Legacy :Avant la version 10, ce paramètre permettait de modifier les plages de hiérarchies pour l'analyse des plages de hiérarchies par défaut établies dans le jeu de données réseau. Dans la version 10, ce paramètre n'est plus pris en charge et doit être spécifié en tant que chaîne vide. Si vous souhaitez modifier les plages de hiérarchies de votre analyse, mettez à jour les plages de hiérarchies par défaut du jeu de données réseau. | Network Analyst Hierarchy Settings |
output_path_shape (Facultatif) |
| String |
Exemple de code
Exécutez l'outil uniquement avec les paramètres requis.
import arcpy
arcpy.env.workspace = "C:/ArcTutor/Network Analyst/Tutorial/SanFrancisco.gdb"
arcpy.na.MakeVehicleRoutingProblemLayer("Transportation/Streets_ND",
"DeliveryRoutes","Minutes")
Exécutez l'outil avec tous les paramètres.
import arcpy
arcpy.env.workspace = "C:/ArcTutor/Network Analyst/Tutorial/SanFrancisco.gdb"
arcpy.na.MakeVehicleRoutingProblemLayer("Transportation/Streets_ND",
"FridayRoutes","Minutes","Meters",
"Minutes","Miles", "1/2/1900", "1",
"High","Medium","ALLOW_DEAD_ENDS_ONLY",
["Oneway"],"USE_HIERARCHY","",
"TRUE_LINES_WITHOUT_MEASURES")
Le script Python autonome illustre l'utilisation de l'outil Créer une couche d’optimisation des tournées de véhicules pour servir un ensemble d'ordres avec une flotte de véhicules.
# Name: MakeVehicleRoutingProblemLayer_Workflow.py
# Description: Find the best routes for a fleet of vehicles, which is operated
# by a distribution company, to deliver goods from a main
# distribution center to a set of grocery stores.
# Requirements: Network Analyst Extension
#Import system modules
import arcpy
from arcpy import env
try:
#Check out the Network Analyst extension license
arcpy.CheckOutExtension("Network")
#Set environment settings
env.workspace = "C:/data/SanFrancisco.gdb"
env.overwriteOutput = True
#Set local variables
inNetworkDataset = "Transportation/Streets_ND"
outNALayerName = "StoreDeliveryRoute"
impedanceAttribute = "TravelTime"
distanceAttribute = "Meters"
timeUntis = "Minutes"
distanceUntis = "Miles"
inOrders = "Analysis/Stores"
inDepots = "Analysis/DistributionCenter"
inRoutes = "RoutesTable"
outLayerFile = "C:/data/output/" + outNALayerName + ".lyr"
#Create a new Vehicle routing problem (VRP) layer. Since the time-based
#attributes such as ServiceTime on orders and CostPerUnitTime on routes is
#recorded in minutes, we use minutes for time_units parameter. As we are
#using cost per unti distance in routes, we have to specify a
#distance attribute. The values for CostPerUnitDistance are in miles, so we
#specify miles for distance units parameter.
outNALayer = arcpy.na.MakeVehicleRoutingProblemLayer(inNetworkDataset, outNALayerName,
impedanceAttribute,
distanceAttribute, timeUntis,
distanceUntis, "", 1,
UTurn_policy = "NO_UTURNS",
output_path_shape = "STRAIGHT_LINES")
#Get the layer object from the result object. The VRP layer can now be
#referenced using the layer object.
outNALayer = outNALayer.getOutput(0)
#Get the names of all the sublayers within the VRP layer.
subLayerNames = arcpy.na.GetNAClassNames(outNALayer)
#Stores the layer names that we will use later
ordersLayerName = subLayerNames["Orders"]
depotsLayerName = subLayerNames["Depots"]
routesLayerName = subLayerNames["Routes"]
#Load the store locations as orders. Using field mappings we map the
#TimeWindowStart1, TimeWindowEnd1 and DeliveryQuantities
#properties for Orders from the fields of store features and assign a value
#of 0 to MaxViolationTime1 property. The Name and ServiceTime properties have
#the correct mapped field names when using the candidate fields from store
#locations feature class.
candidateFields = arcpy.ListFields(inOrders)
orderFieldMappings = arcpy.na.NAClassFieldMappings(outNALayer, ordersLayerName,
False, candidateFields)
orderFieldMappings["TimeWindowStart1"].mappedFieldName = "TimeStart1"
orderFieldMappings["TimeWindowEnd1"].mappedFieldName = "TimeEnd1"
orderFieldMappings["DeliveryQuantities"].mappedFieldName = "Demand"
orderFieldMappings["MaxViolationTime1"].defaultValue = 0
arcpy.na.AddLocations(outNALayer, ordersLayerName, inOrders, orderFieldMappings,"")
#Load the depots from the distribution center features. Using field mappings
#we map the Name properties for Depots from the fields of distribution
#center features and assign a value of 8 AM for TimeWindowStart1 and a value
#of 5PM for TimeWindowEnd2 properties
depotFieldMappings = arcpy.na.NAClassFieldMappings(outNALayer, depotsLayerName)
depotFieldMappings["Name"].mappedFieldName = "Name"
depotFieldMappings["TimeWindowStart1"].defaultValue = "8 AM"
depotFieldMappings["TimeWindowEnd1"].defaultValue = "5 PM"
arcpy.na.AddLocations(outNALayer, depotsLayerName, inDepots, depotFieldMappings, "")
#Load the routes from a table containing information about routes
#In this case, since the fields on the routes table and property names for
#Routes are same, we will just use the default field mappings
arcpy.na.AddLocations(outNALayer, routesLayerName, inRoutes, "", "")
#Solve the VRP layer
arcpy.na.Solve(outNALayer)
#Save the solved VRP 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)