Desktop Help 10.0 - 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.

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.
Lors de l'utilisation de cet outil dans les 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 devenir un 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

MakeVehicleRoutingProblemLayer_na (in_network_dataset, out_network_analysis_layer, time_impedance, {distance_impedance}, {time_units}, {distance_units}, {default_date}, {capacity_count}, {time_window_factor}, {excess_transit_factor}, {UTurn_policy}, {restriction_attribute_name}, {hierarchy}, {hierarchy_settings}, {output_path_shape})

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 2011, la valeur de temps entière pour le champ est 9h00, le 6 mars 2011. 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. Aujourd'hui -- 12/30/1899 Dimanche -- 12/31/1899 Lundi -- 1/1/1900 Mardi -- 1/2/1900 Mercredi -- 1/3/1900 Jeudi -- 1/4/1900 Vendredi -- 1/5/1900 Samedi -- 1/6/1900 Par exemple, pour spécifier que la date implicite pour les valeurs de champs temporels doit être mardi, précisez la valeur de paramètre comme 1/2/1900. Si votre jeu de données réseau inclut l'historique des données de trafic, les résultats de l'analyse peuvent varier en fonction de la date que vous spécifiez ici. Par exemple, si l'on compare des itinéraires qui commencent à 8h00 le dimanche lorsqu'il n'y a pas beaucoup de circulation à ceux qui commencent à 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é.	String
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 : Haute —Le solveur tente de trouver une solution qui réduit les violations de fenêtre horaire mais augmente le temps de trajet total. Sélectionnez cette option s'il est plus important d'arriver à l'heure aux ordres que de réduire le coût global de la solution. Ce peut être le cas si vous rencontrez des clients à vos ordres et que vous ne voulez pas les importuner par des arrivées tardives (une autre option consiste à utiliser des fenêtres horaire strictes qui ne peuvent pas du tout être violées).En raison d'autres contraintes d'une tournée de véhicules, il peut s'avérer impossible de visiter tous les ordres dans leur fenêtre horaire. Dans ce cas, même l'option Elevée peut entraîner des violations. Moyenne —Il s'agit de l'option par défaut. Le solveur cherche un équilibre entre le respect des fenêtres horaires et la réduction du coût total de la solution. Faible —Le solveur tente de trouver une solution qui réduit le temps de trajet total, quelle que soit la fenêtre horaire. Sélectionnez cette option si le respect des fenêtres horaire est moins important que la réduction du coût global de votre solution. Vous pouvez utiliser ce paramètre si vous avez un retard croissant de traitement des demandes de service. Si vous souhaitez servir un plus grand nombre d'ordres et pour combler le retard, vous pouvez sélectionner l'option Min., même si les clients risquent d'être gênés par l'arrivée tardive de votre flotte.	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 : Haute —Le solveur tente de trouver une solution présentant moins de temps de transit excessif entre des ordre appariés, mais augmente les coûts de trajet globaux. Ce paramètre est utile si vous transportez des personnes entre des paires d'ordres et que voulez raccourcir le temps de trajet. Il est caractéristique des services de taxi. Moyenne —Il s'agit de l'option par défaut. Le solveur cherche un équilibre entre la réduction du temps de transit excessif et la réduction du coût total de la solution. Faible —Le solveur tente de trouver une solution qui réduit le coût global de la solution, quel que soit le temps de transit. Ce paramètre est fréquemment utilisé par les messageries privées. Ces sociétés transportant des paquets plutôt que des personnes, elles ne se préoccupent pas du temps de trajet. Cette option permet aux messageries de servir les paires d'ordres dans le bon ordre et de réduire le coût global de la solution.	String
UTurn_policy (Facultatif)	Restreint ou autorise les demi-tours aux jonctions qui pourraient survenir lors de la traversée du réseau entre des arrêts. ALLOW_UTURNS —Les demi-tours sont permis aux jonctions comportant un nombre de tronçons adjacents quelconque. NO_UTURNS —Les demi-tours sont interdits au niveau de toutes les jonctions. Notez toutefois que les demi-tours restent autorisés au niveau des localisations réseau lorsque ce paramètre est sélectionné ; en revanche, vous pouvez configurer la propriété CurbApproach des localisations réseau individuelles pour interdire les demi-tours. ALLOW_DEAD_ENDS_ONLY —Les demi-tours sont interdits au niveau de toutes les jonctions, sauf celles ayant un seul tronçon adjacent (voie sans issue). ALLOW_DEAD_ENDS_AND_INTERSECTIONS_ONLY —Les demi-tours sont interdits aux jonctions où deux tronçons adjacents se rencontrent, mais sont autorisés aux intersection (jonctions avec au moins trois tronçons adjacents) ou aux voies sans issue (jonctions avec exactement un tronçon adjacent).	String
restriction_attribute_name [restriction_attribute_name,...] (Facultatif)	Liste des attributs de restriction à appliquer lors de l'analyse.	String
hierarchy (Facultatif)	USE_HIERARCHY — Utilise l'attribut de hiérarchie pour l'analyse. L'utilisation d'une hiérarchie implique une préférence du solveur pour les tronçons d'ordre supérieur par rapport aux tronçons d'ordre inférieur. Les recherches hiérarchiques sont plus rapides et permettent de simuler la préférence d'un chauffeur de circuler sur des autoroutes au lieu de routes locales si possible, même si cela implique un trajet plus long. Cette option est valide uniquement si le jeu de données réseau en entrée a un attribut de hiérarchie. NO_HIERARCHY —N'utilise pas l'attribut de hiérarchie pour l'analyse. Un itinéraire exact est alors obtenu pour le jeu de données réseau. 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)	Héritage : 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)	TRUE_LINES_WITH_MEASURES —Les itinéraires en sortie ont la forme exacte des sources de données du réseau sous-jacentes. En outre, la sortie comprend des mesures d'itinéraire pour le référencement linéaire. Les mesures augmentent à partir du premier arrêt et enregistrent l'impédance cumulée pour atteindre une position donnée. TRUE_LINES_WITHOUT_MEASURES —Les itinéraires en sortie ont la forme exacte des sources de données du réseau sous-jacentes. STRAIGHT_LINES —La forme de l'itinéraire en sortie correspondra à des lignes droites qui connectent des passages aux dépôts et des ordres dans la séquence d'itinéraires. NO_LINES —Aucune forme n'est créée pour les itinéraires en sortie. Vous ne pouvez pas générer de trajets non plus.	String

Exemple de code

Exemple 1 d'utilisation de l'outil Créer une couche d’optimisation des tournées de véhicules (fenêtre Python)

Exécute l'outil uniquement avec les paramètres requis

import arcpy
arcpy.env.workspace = "C:/ArcTutor/Network Analyst/Tutorial/SanFrancisco.gdb"
arcpy.MakeVehicleRoutingProblemLayer_na("Transportation/Streets_ND",
                                        "DeliveryRoutes","Minutes")

Exemple 2 d'utilisation de l'outil Créer une couche d’optimisation des tournées de véhicules (fenêtre Python)

Exécute l'outil avec tous les paramètres

import arcpy
arcpy.env.workspace = "C:/ArcTutor/Network Analyst/Tutorial/SanFrancisco.gdb"
arcpy.MakeVehicleRoutingProblemLayer_na("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")

Exemple 3 d'utilisation de l'outil Créer une couche d’optimisation des tournées de véhicules (workflow)

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"
    outNALayer = "StoreDeliveryRoute"
    impedanceAttribute = "TravelTime"
    distanceAttribute = "Meters"
    timeUntis = "Minutes"
    distanceUntis = "Miles"
    inOrders = "Analysis/Stores"
    inDepots = "Analysis/DistributionCenter"
    inRoutes = "RoutesTable"
    orderFieldMappings = "Name Name #; ServiceTime ServiceTime #; " + \
                       "TimeWindowStart1 TimeStart1 #; " + \
                       "TimeWindowEnd1 TimeEnd1 #; MaxViolationTime1 # 0; " + \
                       "DeliveryQuantities Demand #"
    depotFieldMappings = "Name Name #; TimeWindowStart1 # 8 AM; " + \
                       "TimeWindowEnd1 # 5 PM"
    outLayerFile = "C:/data/output" + "/" + outNALayer + ".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.
    arcpy.MakeVehicleRoutingProblemLayer_na(inNetworkDataset,outNALayer,
                                            impedanceAttribute,distanceAttribute,
                                            timeUntis, distanceUntis, "", 1, 
                                            UTurn_policy="NO_UTURNS", 
                                            output_path_shape="STRAIGHT_LINES")
    
    #Load the store locations as orders. Using field mappings we map the Name, 
    #ServiceTime, TimeWindowStart1, TimeWindowEnd1 and DeliveryQuantities 
    #properties for Orders from the fields of store features and assign a value
    #of 0 to MaxViolationTime1 property
    arcpy.AddLocations_na(outNALayer, "Orders", 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
    arcpy.AddLocations_na(outNALayer, "Depots", inDepots, depotFieldMappings,"")
    
    #Load the routes from a table containing information about routes
    #In this case, since the fields on the table and property names for Routes
    #are same, we will just use the default field mappings
    arcpy.AddLocations_na(outNALayer, "Routes", inRoutes, "", "")
    
    #Solve the VRP layer
    arcpy.Solve_na(outNALayer)
    
    #Save the solved VRP layer as a layer file on disk with relative paths
    arcpy.SaveToLayerFile_management(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)

Environnements

Espace de travail courant

Rubriques connexes

Optimisation des tournées de véhicules

A propos de l'analyse de réseau avec une hiérarchie

Fenêtres horaires

Vue d'ensemble du jeu d'outils Analyse

Que sont les couches d'analyse de réseau ?

Informations de licence

ArcView : Oui

ArcEditor : Oui

ArcInfo : Oui

7/10/2012