Disponible avec une licence Network Analyst.
L'ArcGIS Network Analyst extension vous permet d'utiliser des informations de trafic historique pour modéliser les vitesses de déplacement sur les routes en fonction des horaires. Le temps de trajet et l'heure d'arrivée prévus sont ainsi plus fiables et vous passerez certainement moins de temps au volant si vous tenez compte des courants de trafic.
Création de données de trafic historique à utiliser avec Network Analyst
Si vos données proviennent d'un tiers, il est important de comprendre comment l'historique des données de trafic a été créé pour que vous puissiez le configurer correctement dans un jeu de données réseau. Cette section propose une vue d'ensemble du modèle utilisé par Network Analyst.
Comme les données de trafic rendent compte du flux et du reflux permanent des vitesses de déplacement, les coûts dans chaque sens de déplacement sur un tronçon peuvent considérablement varier selon l'heure de la journée. Cela contraste avec un attribut de coût type, qui n'autorise qu'une valeur par sens de déplacement sur un tronçon.
Vous pouvez modéliser plusieurs coûts par sens de déplacement sur un tronçon de différentes manières. Pour comprendre pourquoi Network Analyst utilise un modèle spécifique, il est important de comprendre les points faibles de la méthode de modélisation du trafic à priori la plus évidente.
Comment Network Analyst ne modélise pas le trafic historique
L'une des méthodes de stockage des données de trafic historique consiste à créer une série de coûts correspondant à chaque tronçon. Les coûts représentent les vitesses de déplacement à différentes heures de la journée, sur une semaine. Par exemple, une semaine peut être partitionnée en 168 intervalles discrets d'une heure. En d'autres termes, chaque tronçon a besoin de 168 attributs de coût pour représenter les variations du trafic sur une semaine. Si la période est réduite à des intervalles de 5 minutes pour fournir une meilleure résolution temporelle, chaque tronçon a besoin de 2 016 attributs de coût. L'enregistrement de toutes ces valeurs uniques nécessiterait beaucoup d'espace, surtout pour les grands réseaux. Comme les coûts sont par ailleurs les mêmes pour de nombreuses rues pendant la journée, de nombreuses données seraient inutilement dupliquées. C'est pour toutes ces raisons que cette option de modélisation n'est pas appropriée dans Network Analyst.
Comment Network Analyst modélise le trafic historique
Au lieu d'enregistrer toutes les données de trafic entité par entité, ArcGIS utilise un modèle normalisé pour réduire la taille des données de trafic. Au lieu d'enregistrer les 168 ou 2 016 attributs de coût par entité, une table reliée est créée pour contenir ces informations. Chaque ligne de la table contient les vitesses ou éventuellement les temps de trajet de chaque intervalle au cours d'une journée. Une ligne est un profil de vitesse qui représente les fluctuations des vitesses de déplacement tout au long de la journée. En présence, par exemple, de nombreuses rues secondaires à 50 km/h où les temps de trajet varient à l'unisson tout au long de la journée, vous pourriez créer une ligne unique dans la table Profil de vitesse pour représenter ces dynamiques et faire en sorte que toutes ces rues pointent sur cette ligne ou le profil de vitesse. Comme vous le verrez plus loin, d'autres affinages permettent que même les routes où les limitations de vitesse varient et qui suivent le même courant de trafic tout au long de la journée puissent faire référence au même profil de vitesse.
Pour mieux comprendre ce modèle de trafic, supposez que vous devez l'utiliser pour enregistrer les vitesses de déplacement d'un segment de rue à sens unique pendant une semaine, à partir du lundi. En premier lieu, vous devez déterminer la vitesse par trafic fluide, qui est la vitesse à laquelle un véhicule se déplace lorsque rien n'entrave son trajet. Vous pouvez suivre la méthode de votre choix pour déterminer la vitesse par trafic fluide, mais il s'agit généralement de la limitation de vitesse ou de la vitesse moyenne observée des voitures qui circulent en l'absence d'autres véhicules. Partons du principe que vous avez choisi la vitesse moyenne observée des voitures et établi la vitesse par trafic fluide à 110 km/h.
Vous pouvez maintenant faire des observations tout au long de la journée à intervalles égaux (ou tranches horaires). Les intervalles que vous choisissez donnent à vos données leur résolution temporelle. Vous pourriez choisir des intervalles d'une heure, de 10 minutes, et ainsi de suite. Partons du principe que vous choisissez des intervalles de 5 minutes. Vos observations sont enregistrées en tant que facteurs d'échelle des vitesses par trafic fluide. Les facteurs d'échelle sont limités à une plage allant de zéro à un. Supposez que vous observiez des voitures se déplaçant à 45 km/h à 8h00. Cela équivaut à 0,4 fois la vitesse de déplacement par trafic fluide. A 17h00, la vitesse moyenne est de 95 km/h, ce qui équivaut à près de 0,85 fois la vitesse de déplacement par trafic fluide. A 23 h 00, peu de voitures circulent sur la route et leur vitesse de déplacement moyenne est 110 km/h, ce qui correspond à une vitesse de déplacement par trafic fluide. Le facteur d'échelle est égal à un.
Une fois vos observations terminées pour la journée, vous devez référencer une table de profils de vitesse et sélectionner le profil qui correspond le mieux à la variation observée des vitesses de déplacement relatives tout au long de la journée.
Vous choisissez le profil de vitesse 68 (voir le graphique ci-dessous) pour représenter le temps de trajet du segment les lundis.
Vous pouvez effectuer votre choix parmi de nombreux profils de vitesse. Plus vous disposez de profils, plus vous pouvez modéliser avec précision les temps de trajet. Lorsque vous disposez d'un nombre limité de profils, l'espace requis pour l'enregistrement des données est toutefois plus limité. Il convient de trouver un bon équilibre entre précision et espace requis. Il n'est pas rare que de grands réseaux de transport disposent de dizaines voire de centaines de profils de vitesse.
Maintenant que vous avez choisi un profil pour le lundi, vous devez répéter cette procédure pour les autres jours de la semaine. La procédure est, en résumé, la suivante :
- Observez ou calculez les vitesses de déplacement par trafic fluide sur le segment de rue. (Il est inutile de répéter cette étape, car le résultat est le même quel que soit le jour de la semaine.)
- Observez les vitesses de déplacement moyennes à intervalles égaux tout au long de la journée.
- Convertissez les vitesses en facteur d'échelle (entre 0 et 1) de vitesse par trafic fluide. (Si vous modélisez directement des temps de trajet plutôt que des vitesses, le facteur d'échelle doit être supérieur ou égal à un.)
- Choisissez un profil pour représenter le trafic du segment de rue pour ce jour de la semaine.
Vous déterminez que le profil de vitesse 68 correspond également bien au segment tous les autres jours de la semaine. Tel est souvent le cas, car les courants de trafic généraux sont fréquemment les mêmes tous les jours ouvrables. Il n'est toutefois pas difficile de trouver des jours de semaine qui utilisent des profils représentatifs différents : un même profil peut, par exemple, être utilisé les lundis, mardis et mercredis et un autre profil les jeudis et vendredis.
Comme le trafic est fluide et constant sur le segment le samedi et le dimanche, vous choisissez le Profil de vitesse 3 (ci-dessous) pour représenter les temps de trajet les week-ends.
Vous enregistrez ensuite les vitesses de déplacement par trafic fluide et les relations entre les profils de vitesse et de segment de rue dans une table : la table de jointure Rue-Profil. Cette table, ainsi que les autres entrées nécessaires, sont présentées dans les prochaines sections.
Enregistrement de données et de relations dans la géodatabase
Vous avez besoin d'une ou plusieurs classes d'entités lignes et de deux tables dans une géodatabase pour créer un jeu de données réseau avec des données de trafic historique. Les classes d'entités lignes représentent des rues, qui doivent être enregistrées dans un jeu de données d'entité. Les profils de vitesse sont enregistrés dans l'une des tables et les relations entre les rues et les profils de vitesse sont enregistrées dans l'autre table. Ces entités et les champs requis pour définir l'historique du trafic sur un jeu de données réseau sont décrits dans les sous-sections ci-dessous.
Classe d'entités Streets
Chaque entité de rue possède un identifiant unique : la valeur ObjectID. Les rues sont reliées à leurs différents profils de vitesse via l'identifiant unique dans la table de jointure Rue-Profil.
D'autres champs peuvent s'avérer utiles lors de la définition de l'historique du trafic. Ils sont répertoriés ci-dessous et décrits plus en détail plus loin dans cette rubrique.
| Champ | Exemples de nom de champ | Description |
|---|---|---|
Temps de trajet ne tenant pas compte du temps | FT_Minutes TF_Minutes | Pour la création d'un attribut de coût de réseau utilisé lors du séquencement des emplacements dans un itinéraire ou une analyse de tournée de véhicules qui utilise le trafic |
Temps de trajet les jours de la semaine | FT_WeekdayMinutes TF_WeekdayMinutes | Pour créer un attribut de coût de réseau à utiliser lorsqu'aucun profil de vitesse historique n'est associé à un segment de rue un jour de la semaine. (Les temps de trajet ne tenant pas compte du temps sont également souvent utilisés en tant que temps de trajet spécifiques aux jours de la semaine.) |
Temps de trajet les week-ends | FT_WeekendMinutes TF_WeekendMinutes | Pour créer un attribut de coût de réseau à utiliser lorsqu'aucun profil de vitesse n'est associé à un segment de rue le samedi ou le dimanche. |
Fuseau horaire | TimeZoneID | Pour créer un attribut de réseau de fuseau horaire à utiliser lorsqu'un réseau couvre plusieurs fuseaux horaires. |
Table Profil
Chaque enregistrement dans une table de profil de vitesse possède un identifiant unique, ainsi que plusieurs champs qui permettent d'enregistrer le facteur d'échelle de trafic fluide à différentes heures de la journée. Les heures de la journée sont divisées en intervalles (ou tranches horaires) dont la durée doit être identique. Une période de 24 heures doit donc être divisée en intervalles égaux. Si, par exemple, les tranches horaires durent cinq minutes, 288 champs sont alors concernés (de 12 h 00 à 12 h 05, de 12 h 05 à 12 h 10, et ainsi de suite).
La géodatabase de San Francisco proposée dans les données du didacticiel de Network Analyst contient des profils qui couvrent la journée par tranches horaires de cinq minutes. Le champ SpeedFactor_0000 contient les facteurs d'échelle de trafic fluide de minuit à 12h05. Le champ SpeedFactor_1140 contient les multiplicateurs de 11h40 à 11h45. Lorsqu'une entité de rue est reliée à un profil, vous pouvez obtenir le temps de trajet prévu quelle que soit l'heure de la journée. Par exemple, si une rue est reliée au profil 16 (voir graphique ci-dessous), vous pouvez calculer le temps de trajet prévu à 11 h 41 en multipliant le temps de trajet par trafic fluide de la rue par la valeur SpeedFactor_1140 (0,889) du profil. 
Table de jointure Rue-Profil
Les entités rues, leurs vitesses de déplacement (ou temps de trajet) par trafic fluide et le profil de vitesse qui y est associé pour chaque jour de la semaine figurent dans la table de jointure Rue-Profil. Les champs obligatoires, un exemple de nom de champ, les types de données autorisés et une brève description sont répertoriés dans le tableau suivant :
| Champ | Exemples de nom de champ | Type de données | Description |
|---|---|---|---|
Identifiant de la classe d'entités tronçons | EdgeFCID Vous devez nommer ce champ EdgeFCID. | Entier long | Identifie la classe d'entités dans laquelle l'entité rue est enregistrée. |
Identifiant de l'entité tronçon | EdgeFID Vous devez nommer ce champ EdgeFID. | Entier long | Identifie l'entité rue. |
Position de départ du tronçon | EdgeFrmPos Vous devez nommer ce champ EdgeFrmPos. | Réel double | Fonctionne avec EdgeToPos pour identifier un sens de circulation ou le côté de la rue. Zéro indique le début de l'entité ligne défini par son sens de numérisation. Un indique l'extrémité opposée. Prenons l'exemple d'une valeur EdgeFrmPos de 0 et d'une valeur EdgeToPos de 1 qui identifient le côté droit de l'entité ligne (avec un trafic du côté droit). Les profils de vitesse répertoriés dans le même enregistrement représentent dans ce cas le trafic uniquement pour ce côté de la rue. Toutes les valeurs décimales indiquent une position le long du sens de numérisation de l'entité, ce qui permet à l'outil Fusion du réseau de conserver les bons profils pour les rues une fois les tronçons fusionnés. |
Position d'arrivée du tronçon | EdgeToPos Vous devez nommer ce champ EdgeToPos. | Réel double | Fonctionne avec EdgeFrmPos pour identifier un sens de circulation ou le côté de la rue. |
Champ Vitesse de base ou Champ Temps de trajet de base | BaseSpeedKPH ou FreeflowMinutes | Flottant ou double | Vitesse par trafic fluide. Eventuellement, le temps de trajet par trafic fluide. En tant que champ de vitesse de base, il peut représenter des kilomètres/heure ou des miles/heure. En tant que champ de temps de trajet de base, il peut représenter des jours, heures, minutes ou secondes. |
Champ Profil dimanche | Profile_1 SundayProfile | Entier court ou long | Id d'objet de la table Profils qui représente le mieux le courant de trafic les dimanches pour la portion de la rue identifiée par EdgeFCID, EdgeFID, EdgeFrmPos et EdgeToPos. |
Champ Profil lundi | Profile_2 MondayProfile | Entier court ou long | ID d'objet de la table Profils qui représente le mieux le trafic les lundis. |
Champ Profil mardi | Profile_3 TuesdayProfile | Entier court ou long | ID d'objet de la table Profils qui représente le mieux le trafic les mardis. |
Champ Profil mercredi | Profile_4 WednesdayProfile | Entier court ou long | ID d'objet de la table Profils qui représente le mieux le trafic les mercredis. |
Champ Profil jeudi | Profile_5 ThursdayProfile | Entier court ou long | ID d'objet de la table Profils qui représente le mieux le trafic les jeudis. |
Champ Profil vendredi | Profile_6 FridayProfile | Entier court ou long | ID d'objet de la table Profils qui représente le mieux le trafic les vendredis. |
Champ Profil samedi | Profile_7 SaturdayProfile | Entier court ou long | ID d'objet de la table Profils qui représente le mieux le trafic les samedis. |
Dans le graphique ci-dessous, la table intitulée Streets_DailyProfiles est un exemple de table de jointure Rue-Profil. Le champ PROFILE_1 représente le champ Profil dimanche, le champ PROFILE_7 représente le champ Profil samedi et les champs compris entre et incluant PROFILE_2 à PROFILE_6 (qui ne figurent pas dans la table) représentent les champs de profil du lundi au vendredi.
Observez l'enregistrement sélectionné (identifiant d'objet 111). Il associe les profils de chaque jour de la semaine avec le côté sens aller de l'entité rue dont l'ID d'objet est 28803. Le sens aller de la rue est identifié par les valeurs EdgeFrmPos et EdgeToPos qui correspondent respectivement à zéro et un. Le profil de vitesse 12 représente ce côté de la rue les dimanches et les samedis, car la valeur 12 figure dans les champs PROFILE_1 et PROFILE_7. Le champ SPFREEFLOW indique la vitesse de déplacement correspondant à la rue, dans le sens aller par trafic fluide.
Observez maintenant les deux premiers enregistrements. Le premier enregistrement (ID d'objet 109) stocke les profils d'un segment de rue dans le sens aller et le deuxième enregistrement (ID d'objet 110) stocke les mêmes profils pour le même segment de rue, mais en sens inverse. Cela est automatiquement calculé à partir des valeurs EdgeFCID et EdgeFID qui sont identiques et des valeurs EdgeFrmPos et EdgeToPos qui sont inversées. Notez également que les valeurs des champs des profils dimanche et samedi sont nulles. Cela signifie qu'aucune donnée n'a été collectée ou qu'aucun profil n'a été choisi pour ces jours. Lors de l'évaluation de l'historique des temps de trajet les samedis ou les dimanches sur ce tronçon, l'évaluateur devra se replier vers un attribut de coût secondaire défini dans l'évaluateur de trafic sur un tronçon.
