Cette page explique comment remédier aux résultats inattendus obtenus lors de la résolution d’une analyse de réseau en utilisant un jeu de données de réseau local dans ArcGIS Pro, notamment un jeu de données réseau créé par vous-même ou votre organisation et basé sur vos propres données.
L’une des raisons suivantes peut être à l’origine de résultats d’analyse du réseau inattendus :
- Un problème de configuration du jeu de données réseau utilisé pour la résolution d’analyse
- Un problème avec les données source utilisées dans le jeu de données réseau
- Un problème au niveau des paramètres utilisés pour l’analyse
- Une incompréhension des paramètres ou d’une fonctionnalité du solveur
Les sections ci-dessous décrivent les principaux résultats d’analyse de réseau inattendus et leurs symptômes, les problèmes courants susceptibles de produire des résultats inattendus, ainsi que les outils et techniques permettant de remédier aux résultats inattendus.
Résultats inattendus courants et autres symptômes
Les sections ci-dessous décrivent les principaux résultats d’analyse de réseau inattendus et leurs symptômes, ainsi que les différentes causes possibles. Un grand nombre de ces symptômes peuvent avoir plusieurs causes possibles. Des liens vous renvoient à d’autres sections de ce document dans lesquelles vous trouverez des informations utiles sur les causes possibles et des conseils pour les étudier et y remédier.
Voici une liste des résultats inattendus possibles. Cliquez sur chacun d’eux pour afficher les détails :
- Le solveur a échoué : Aucune solution n’a été trouvée ou ERREUR 030212 : Le solveur n’a pas trouvé de solution
- L’itinéraire ne suit pas le chemin le plus direct ou fait un grand détour
- La ressource la plus proche indiquée n’est pas réellement la ressource la plus proche
- Le solveur a renvoyé les avertissements suivants : Aucune ressource trouvée ou Aucune destination trouvée
- Certaines origines dans une matrice de coût OD ne trouvent aucune destination, alors que d’autres origines à proximité en trouvent plusieurs
- Aucune solution n’est trouvée quand j’applique une limite
- L’itinéraire suit un trajet aléatoire sur l’ensemble du réseau
- Les coûts semblent inexacts
- Des restrictions sont ignorées ou les routes sont soumises à des restrictions inattendues
- L’itinéraire emprunte une rue à sens unique dans le mauvais sens
- L’itinéraire tourne à des endroits interdits ou évite de tourner à l’endroit escompté
- L’itinéraire tourne sur la route en dessous depuis le haut d’un pont
- L’itinéraire fait un demi-tour à un arrêt alors que la règle de demi-tour est définie sur Pas de demi-tour
- L’itinéraire débute ou s’arrête à une localisation inattendue, c’est-à-dire dans une rue qui n’est pas la plus proche du point en entrée
- Les entrées ne sont pas localisées
- Les polygones de zone de desserte sont très petits ou très grands
- Les polygones de zone de desserte ont des sections manquantes ou des formes inattendues
- Les polygones de zone de desserte couvrent des zones non conformes à la distance de tronquage définie
- Les temps de trajet et les heures du jour dans les feuilles de route ne correspondent pas aux valeurs des tables attributaires
- Les itinéraires pendant les heures de pointe et en dehors des heures de pointe dans l’analyse d’itinéraire de flotte sont identiques
- Un ordre ou un arrêt dans un calcul d’itinéraire de flotte n’a pas été pris en compte dans un itinéraire
- Le réseau modélise le transport en commun, mais les lignes de transport ne sont jamais prises en compte
- Des interruptions linéaires sont ignorées
- La géométrie de l’itinéraire ne correspond pas à la géométrie des rues sous-jacentes
- Le résultat du solveur ne reflète pas les mises à jour effectuées après la modification du réseau
- L’outil Construire le réseau a renvoyé des erreurs de construction (AVERTISSEMENT 030116)
Le solveur a échoué : Aucune solution n’a été trouvée ou ERREUR 030212 : Le solveur n’a pas trouvé de solution
Le solveur a échoué et renvoyé un message d’erreur, car il n’a pas réussi à calculer un chemin reliant les localisations en entrée. Il n’est pas possible de se déplacer entre les différents points de ce jeu de données réseau.
Ce résultat peut être considéré comme une solution valide et correcte. Si les arrêts sont situés sur des îles déconnectées, il peut être impossible de se déplacer entre eux par la route. Ou si des interruptions sont utilisées dans l’analyse, il se peut qu’une interruption bloque le seul chemin menant à l’un des arrêts. Ce résultat peut aussi indiquer un ou plusieurs problèmes avec les paramètres d’analyse ou le jeu de données réseau utilisé pour l’analyse.
Il est fort probable que des problèmes affectent la connectivité du réseau. Si des rues ne sont pas connectées correctement au niveau des intersections, il peut être impossible de traverser ces intersections, ce qui risque d’isoler certaines parties du réseau.
Voici plusieurs problèmes courants qui affectent la connectivité du réseau :
- Interruptions ou arcs pendants au niveau des intersections
- Extrémités ou sommets manquants au niveau d’intersections spécifiques
- Tournants incorrects
- Règle de connectivité de groupe incorrecte
- Valeurs de hiérarchie incorrectes
- Modèle de réseau incorrect
Autres problèmes potentiels :
L’itinéraire ne suit pas le chemin le plus direct ou fait un grand détour
L’itinéraire entre les points semble insolite, indirect ou non optimal, ou fait un grand détour par rapport au chemin le plus court.
Il est fort probable que des problèmes affectent la connectivité du réseau. Si des rues ne sont pas connectées correctement au niveau des intersections, il peut être impossible de traverser ces intersections, ce qui implique de faire de grands détours pour trouver un chemin.
Voici plusieurs problèmes courants qui affectent la connectivité du réseau :
- Interruptions ou arcs pendants au niveau des intersections
- Extrémités ou sommets manquants au niveau d’intersections spécifiques
- Tournants incorrects
- Règle de connectivité de groupe incorrecte
- Valeurs de hiérarchie incorrectes
- Modèle de réseau incorrect
Des restrictions incorrectes peuvent également impliquer de longs détours sur l’itinéraire.
La ressource la plus proche indiquée n’est pas réellement la ressource la plus proche
Le résultat de l’analyse de la ressource la plus proche semble inexact. La ressource la plus proche indiquée pour un incident donné n’est pas réellement la ressource la plus proche. Le résultat ignore une autre ressource qui semble pourtant plus proche.
Il se peut que la ressource à priori plus proche soit tronquée ou inaccessible en raison de problèmes de connectivité du réseau ou de restrictions incorrectes. Reportez-vous à la section L’itinéraire ne suit pas le chemin le plus direct ou fait un grand détour.
Le solveur a renvoyé les avertissements suivants : Aucune ressource trouvée ou Aucune destination trouvée
L’analyse de la ressource la plus proche a renvoyé des avertissements du type suivant : Aucune ressource trouvée pour <valeur> dans Incidents. Une matrice de coût OD a renvoyé des avertissements du type suivant : Aucune destination trouvée pour <valeur> dans Origines. L’analyse a renvoyé l’AVERTISSEMENT 030025 pour indiquer qu’une solution partielle est en cours de génération.
Aucun chemin n’a été trouvé entre un sous-ensemble d’origines et de destinations ou d’incidents et de ressources. Ce résultat peut être considéré comme une solution valide et correcte. Si une limite est appliquée à l’analyse, par exemple, certaines origines risquent de se trouver en dehors de la limite des destinations. Ou si les entrées sont situées sur des îles déconnectées, il peut être impossible de se déplacer entre elles par la route.
Cela peut aussi indiquer un problème avec le réseau utilisé pour l’analyse ou avec les paramètres d’analyse. Reportez-vous à la section Le solveur a échoué : Aucune solution n’a été trouvée ou ERREUR 030212 : Le solveur n’a pas trouvé de solution, car ce problème a généralement des causes similaires.
Certaines origines dans une matrice de coût OD ne trouvent aucune destination, alors que d’autres origines à proximité en trouvent plusieurs
L’analyse d’une matrice de coût OD avec de nombreuses origines et destinations renvoie des résultats étranges. Certaines origines ont trouvé de nombreuses destinations ou toutes les destinations, alors que d’autres origines à proximité censées donner un résultat similaire n’en ont trouvé aucune ou seulement quelques-unes.
Aucun chemin n’a été trouvé entre certaines origines et certaines destinations ou de nombreuses destinations. Comme les autres origines à proximité immédiate ont produit un résultat très différent, le problème est probablement dû à la connectivité du jeu de données réseau. Certaines origines sont situées sur des routes déconnectées du reste du réseau.
Voici plusieurs problèmes courants qui affectent la connectivité du réseau :
Aucune solution n’est trouvée quand j’applique une limite
Le calcul de l’itinéraire échoue si une limite est appliquée ou si aucun chemin n’est trouvé entre la paire origine-destination ou la paire incident-ressource, lorsqu’une limite est appliquée. Si la limite est supprimée, une solution raisonnable est trouvée.
Cela peut indiquer que les unités de la limite appliquée et de l’attribut d’impédance utilisé par le mode de déplacement pour l’analyse ne correspondent pas.
Apprendre à vérifier les unités du mode de déplacement
Cela peut aussi être le signe d’un attribut de coût configuré de façon incorrecte, notamment si le coût global semble incorrect alors que le chemin est pertinent. Reportez-vous à la section Les coûts semblent inexacts. Si le chemin semble inexact, reportez-vous à la section L’itinéraire ne suit pas le chemin le plus direct ou fait un grand détour.
L’itinéraire suit un trajet aléatoire sur l’ensemble du réseau
L’itinéraire semble suivre un parcours aléatoire sur l’ensemble du réseau.
Le solveur calcule toujours le chemin le plus court pour le réseau spécifié. Un chemin insolite est généralement le signe d’un problème avec le réseau sous-jacent.
Si l’itinéraire semble suivre un trajet aléatoire sur l’ensemble du réseau, cela peut être dû à une configuration incorrecte de l’attribut de coût, ce qui se traduit par des valeurs d’attribut de coût de 0. Si le temps ou la distance nécessaire pour traverser un tronçon du réseau a un coût de revient équivalent à 0, il est impossible de calculer l’itinéraire le plus court. Tous les chemins sont indiqués comme étant gratuits. Reportez-vous à la section Configuration incorrecte de l’attribut de coût.
Un itinéraire inattendu, calculé apparemment de façon aléatoire, peut être dû également à divers problèmes de connectivité. Reportez-vous à la section L’itinéraire ne suit pas le chemin le plus direct ou fait un grand détour pour découvrir d’autres causes possibles.
Les coûts semblent inexacts
Les coûts liés au temps ou à la distance de trajet calculés, ou à d’autres paramètres, semblent incorrects.
Les solveurs Network Analyst optimisent un attribut de coût dans le jeu de données réseau. Les coûts peuvent se révéler inexacts en cas d’utilisation d’un mauvais attribut de coût pour l’analyse. Si l’attribut de coût utilisé ne pose aucun problème, il se peut qu’il ne soit pas configuré correctement. Reportez-vous à la section Configuration incorrecte de l’attribut de coût.
Des restrictions sont ignorées ou les routes sont soumises à des restrictions inattendues
L’itinéraire emprunte des routes soumises à des restrictions ou évitent des routes qui ne doivent pas être restreintes.
Cela laisse généralement présager un problème avec les restrictions appliquées pour une analyse. Assurez-vous d’abord que les attributs de restriction désirés ont été appliqués pour l’analyse. Si c’est le cas, il se peut qu’un ou plusieurs attributs de restriction soient mal configurés. Reportez-vous à la section Restrictions incorrectes pour obtenir des conseils sur la façon de corriger et résoudre les problèmes de restriction.
Il est possible que les restrictions ne soient pas la cause du problème. Reportez-vous à la section L’itinéraire ne suit pas le chemin le plus direct ou fait un grand détour pour découvrir d’autres causes possibles de ce comportement.
L’itinéraire emprunte une rue à sens unique dans le mauvais sens
L’itinéraire vous fait passer par une rue en sens interdit.
Les rues à sens unique sont modélisées comme des restrictions, en principe. Soit la restriction en matière de rues à sens unique n’a pas été appliquée pour l’analyse, soit la configuration de l’attribut de restriction en matière de rues à sens unique pose un problème. Reportez-vous à la section Restrictions incorrectes pour obtenir des conseils sur la façon de corriger et résoudre les problèmes de restriction.
L’itinéraire tourne à des endroits interdits ou évite de tourner à l’endroit escompté
L’itinéraire tourne à un endroit interdit ou semble faire un détour au lieu de tourner à l’endroit qui était attendu.
Cela est dû, en principe, à un problème de modélisation des tournants dans le réseau ou à un problème de connectivité du réseau de façon plus générale.
L’itinéraire tourne sur la route en dessous depuis le haut d’un pont
L’itinéraire passe sur la route en dessous depuis le haut d’un pont, ou vice versa, en prenant un tournant impossible. L’itinéraire emprunte des voies considérées comme illicites entre des passages inférieurs et des passages supérieurs.
Ce type de comportement indique généralement un problème au niveau de la règle de connectivité verticale du réseau.
L’itinéraire fait un demi-tour à un arrêt alors que la règle de demi-tour est définie sur Pas de demi-tour
L’itinéraire arrive à un arrêt, puis repart dans la direction inverse et fait donc un demi-tour, alors que la règle de demi-tour du mode de déplacement est définie sur Pas de demi-tour.
Les règles de demi-tour du mode de déplacement contrôlent si et où un véhicule peut effectuer des demi-tours entre des localisations. Elles ne servent pas à contrôler si un véhicule a le droit de faire un demi-tour à un arrêt sur l’itinéraire. Certains arrêts donnent sur une voie ou un parking où il est possible de faire un demi-tour. D’autres arrêts peuvent impliquer l’arrêt du véhicule sur le bord de la route à un endroit où il est dangereux ou impossible de faire un demi-tour. Pour définir le comportement des demi-tours au niveau d’un arrêt, configurez la valeur du champ CurbApproach pour cet arrêt.
L’itinéraire débute ou s’arrête à une localisation inattendue, c’est-à-dire dans une rue qui n’est pas la plus proche du point en entrée
Le chemin proposé ne débute ou ne s’arrête pas dans la rue la plus proche du point en entrée.
Si le chemin débute ou s’arrête à proximité du point en entrée, mais pas au point le plus proche sur le réseau, reportez-vous à la section Entrées localisées sur la mauvaise entité de réseau.
Si l’itinéraire commence ou se termine à un endroit totalement inattendu, c’est-à-dire très loin des entrées, et que vous avez ajouté les entrées à l’aide de champs de localisation précalculés, ces champs risquent d’être obsolètes ou de s’appliquer à un autre jeu de données réseau. Reportez-vous à la section Champs de localisation non valides ou obsolètes.
Les entrées ne sont pas localisées
Le solveur a généré des avertissements au sujet d’entrées non localisées. Le solveur a échoué ou généré l’AVERTISSEMENT 030025 pour indiquer qu’une solution partielle a été trouvée.
Il est rare que les localisations géographiques des entrées utilisées dans une analyse de réseau intersectent parfaitement les tronçons et les jonctions du réseau. C’est la raison pour laquelle un processus de localisation de toutes les entrées sur le réseau est lancé, afin de trouver la localisation de réseau routable la plus proche.
En savoir plus sur la localisation des points dans un réseau
Si certains points ne peuvent pas être localisés, cela signifie qu’aucune localisation de réseau valide n’a été trouvée pour ces points, en raison des contraintes des paramètres de localisation et du mode de déplacement appliqué lors de l’analyse. Pour identifier les points non localisés, recherchez les valeurs 2 (élément de réseau non localisé) dans le champ Status de la table en entrée ou les valeurs -1 dans le champ SourceID.
Le fait d’avoir des points très éloignés du réseau, au-delà de la tolérance de recherche, est l’une des principales raisons pour lesquelles ils risquent de ne pas être localisés. Reportez-vous à la section Paramètres de localisation incorrects et à la section Entrées localisées sur la mauvaise entité de réseau.
Les polygones de zone de desserte sont très petits ou très grands
Les polygones de zone de desserte sont démesurément petits ou grands pour la limite utilisée.
Cela peut indiquer que les unités de la limite appliquée et de l’attribut d’impédance utilisé par le mode de déplacement pour l’analyse ne correspondent pas.
Apprendre à vérifier les unités du mode de déplacement
Cela peut aussi être le signe d’un attribut de coût configuré de façon incorrecte. Reportez-vous à la section Les coûts semblent inexacts.
Des polygones de zone de desserte anormalement petits peuvent être le signe d’un problème de connectivité du réseau ou d’un problème lié aux attributs de restriction. Reportez-vous à la section Le solveur a échoué : Aucune solution n’a été trouvée ou ERREUR 030212 : Le solveur n’a pas trouvé de solution.
Les polygones de zone de desserte ont des sections manquantes ou des formes inattendues
Il semblerait que les polygones de zone de desserte ne couvrent pas certaines rues escomptées ou qu’il manque des sections importantes, ce qui se traduit par des formes étranges.
Les polygones de zone de desserte sont générés autour de routes accessibles à partir de la ressource, dans la limite spécifiée. Des polygones avec des formes anormales peuvent être le signe de problèmes de connectivité du réseau. Essayez de générer des lignes de zone de desserte pour identifier les rues atteintes.
Voici plusieurs problèmes courants qui affectent la connectivité du réseau :
Les polygones de zone de desserte couvrent des zones non conformes à la distance de tronquage définie
Les polygones de zone de desserte couvrent de grandes zones sans aucune route et semblent ne pas tenir compte du paramètre de distance de tronquage.
Les polygones de zone de desserte sont une représentation artistique de la zone accessible jusqu’à la limite spécifiée et le polygone en sortie peut varier considérablement en fonction des paramètres définis par l’utilisateur. La distance de tronquage de la zone de desserte sert uniquement à la créer des zones tampons pour les routes, en fonction des tronçons de la zone de desserte qui ne sont pas entourés d’autres routes accessibles. Elle n’a aucune influence sur les parties intérieures de la zone accessible. Les zones entièrement cernées de routes accessibles sont totalement couvertes, même si la distance qui sépare la partie interne de la route est supérieure à la distance de tronquage.
Pour générer un polygone incluant uniquement la zone située dans la distance de tronquage de routes accessibles, configurez l’analyse de la zone de desserte avec des lignes en sortie au lieu de polygones, et utilisez l’outil Zone tampon ou Zone tampon deux par deux pour créer des zones tampons simples.
Les temps de trajet et les heures du jour dans les feuilles de route ne correspondent pas aux valeurs des tables attributaires
Lors du calcul de l’itinéraire d’une tournée de véhicules, d’une livraison sur le dernier kilomètre ou d’une collecte des déchets, les temps de trajet et les heures du jour indiqués dans les feuilles de route virage par virage ne correspondent pas aux valeurs des tables attributaires.
Cette incohérence est attendue. Les solveurs d’itinéraire de flotte utilisent une matrice de coût origine-destination (OD) ne tenant pas compte du temps afin de déterminer l’affectation des itinéraires et leur séquençage. Les valeurs de cette matrice de coût origine-destination ne tenant pas compte du temps servent à alimenter les coûts basés sur le temps et la distance indiqués dans les tables attributaires, à des fins de cohérence avec la logique d’optimisation utilisée pour résoudre le problème. Une fois la séquence d’arrêts finalisée pour chaque itinéraire, le solveur d’itinéraire est utilisé pour générer des feuilles de route en utilisant l’heure de début réelle de l’itinéraire, ce qui permet de remplir les champs de feuilles de route avec des heures d’arrivée plus précises en fonction des conditions de circulation aux heures du jour de visite.
Les itinéraires pendant les heures de pointe et en dehors des heures de pointe dans l’analyse d’itinéraire de flotte sont identiques
Le fait de changer l’heure du jour pour calculer l’itinéraire d’une tournée de véhicules, d’une livraison sur le dernier kilomètre ou d’une collecte des déchets ne change pas l’itinéraire, bien que le trafic aux heures de pointe ait un impact, en principe.
Ce comportement est prévu. Les solveurs d’itinéraire de flotte utilisent une matrice de coût origine-destination (OD) ne tenant pas compte du temps afin de déterminer l’affectation des itinéraires et leur séquençage. Les valeurs de cette matrice de coût origine-destination ne tenant pas compte du temps servent à alimenter les coûts basés sur le temps et la distance indiqués dans les tables attributaires, à des fins de cohérence avec la logique d’optimisation utilisée pour résoudre le problème.
Par conséquent, cette portion du résultat reste la même, quelle que soit l’heure du jour utilisée pour l’itinéraire.
Une fois la séquence d’arrêts finalisée pour chaque itinéraire, le solveur d’itinéraire est utilisé pour générer des feuilles de route en utilisant l’heure de début réelle de l’itinéraire, ce qui permet de remplir les champs de feuilles de route avec des heures d’arrivée plus précises en fonction des conditions de circulation aux heures du jour de visite. Les feuilles de route doivent donc être modifiées pour refléter le trafic aux heures de pointe.
Un ordre ou un arrêt dans un calcul d’itinéraire de flotte n’a pas été pris en compte dans un itinéraire
Un ordre ou un arrêt lors de l’analyse d’une tournée de véhicules, d’une livraison sur le dernier kilomètre ou d’une collecte des déchets n’a pas été pris en compte dans un itinéraire. Le solveur a renvoyé des messages d’avertissement précisant que les ordres ou arrêts ne figurent pas tous dans l’itinéraire.
Cela peut se produire si l’arrêt viole une ou plusieurs contraintes. Examinez les champs ViolatedConstraint_# pour savoir quelle contrainte a empêché la prise en compte de l’ordre ou de l’arrêt.
Le réseau modélise le transport en commun, mais les lignes de transport ne sont jamais prises en compte
Le réseau intègre un transport en commun et utilise, à ce titre, les tables et classes d’entités du modèle de données de transport en commun, mais au moment de résoudre l’analyse, aucune ligne de transport n’est prise en compte.
Assurez-vous d’abord que l’attribut d’impédance du mode de déplacement utilisé pour l’analyse est configuré avec l’évaluateur de transport en commun. Découvrez comment vérifier l’attribut d’impédance du mode de déplacement utilisé par une couche d’analyse de réseau.
Vérifiez ensuite la date et l’heure sélectionnées pour l’analyse. Si aucune date et heure n’est définie, les lignes de transport ne seront jamais prises en compte. Si la date et l’heure ont été définies, mais qu’aucun service de transport n’est disponible au moment indiqué, les lignes de transport ne seront pas prises en compte.
Si le fait de définir une valeur appropriée pour la date et l’heure ne permet pas de résoudre le problème, la connectivité du réseau peut être à l’origine du problème. Si les lignes de transport ne sont pas connectées aux rues, le voyageur ne pourra pas monter à bord du système de transport ou en descendre. Reportez-vous à la section Interruptions ou arcs pendants au niveau des intersections et à la section Règle de connectivité de groupe incorrecte. Pour plus d’informations sur les règles de connectivité plus spécifiques aux réseaux de transport en commun, reportez-vous aux sections appropriées du didacticiel Créer et utiliser un jeu de données réseau avec des données de transport en commun. Si la capture des entités StopsOnStreets aux rues n’a pas été effectuée correctement, cela peut être le signe d’un problème de référence spatiale. Vous devez alors reconstruire le réseau à partir de zéro en suivant le didacticiel, en veillant à projeter les rues dans la référence spatiale voulue, avant d’exécuter l’outil Connecter le modèle de données de transport en commun aux rues.
Des interruptions linéaires sont ignorées
Des interruptions linéaires ont été appliquées à l’analyse, mais l’itinéraire emprunte des routes qui devraient être restreintes par une interruption linéaire. L’itinéraire semble passer directement sous l’interruption elle-même ou sous une partie de l’interruption. La valeur de coût d’une rue entière n’est pas impactée comme attendu par une interruption linéaire de coût proportionnée.
Il est possible d’utiliser des interruptions linéaires pour restreindre le déplacement dans une zone spécifique ou pour proportionner le coût de ce déplacement.
Pour en savoir plus sur les interruptions
Si la géométrie de l’interruption linéaire a été créée pour suivre la rue sous-jacente, mais qu’elle ne correspond pas exactement à la géométrie de la rue, il se peut que certaines portions de la rue ne soient soumises à aucune restriction ou ne soient pas affectées par l’interruption de coût proportionnée. Modifiez l’interruption linéaire de telle sorte qu’elle corresponde exactement à la géométrie de la rue. L’outil Traçage peut être utile lors de la mise à jour de l’entité.
Certains processus impliquent de calculer un itinéraire, puis d’utiliser le chemin proposé comme interruption linéaire. Pour ce type de processus, désactivez la tolérance de simplification du mode de déplacement pour vous assurer que la forme de l’itinéraire correspond exactement au réseau sous-jacent.
Apprendre à ajuster la tolérance de simplification
Dans le cas d’une interruption de restriction, le moyen le plus efficace de restreindre le déplacement consiste parfois à faire correspondre l’interruption linéaire à la géométrie de la rue. Modifiez l’interruption linéaire de telle sorte qu’elle croise la rue à l’emplacement où la portion restreinte débute au lieu de faire correspondre la ligne à l’entité rue complète. Vous pouvez aussi utiliser une interruption surfacique ou une interruption ponctuelle, en définissant le champ FullEdge sur True, pour restreindre le déplacement sur la totalité de la rue.
La géométrie de l’itinéraire ne correspond pas à la géométrie des rues sous-jacentes
La géométrie de l’itinéraire diffère de la géométrie des classes d’entités source du jeu de données réseau.
Si la géométrie est proche, mais pas tout à fait exacte, il se peut que le mode de déplacement utilisé pour l’analyse ait appliqué une tolérance de simplification. En savoir plus sur les paramètres de mode de déplacement. Si c’est le cas, de petites différences sont attendues.
Si la géométrie est complètement différente, il se peut que le jeu de données réseau ait été mis à jour, mais n’ait pas encore été reconstruit, et que la géométrie des entités rues ait changé. Reportez-vous à la section Le jeu de données réseau n’est pas créé.
Le résultat du solveur ne reflète pas les mises à jour effectuées après la modification du réseau
Vous avez mis à jour les entités source du jeu de données réseau, leurs valeurs de champs ou les propriétés du jeu de données réseau, mais les résultats de l’analyse ne reflètent pas ces modifications.
Le réseau doit être reconstruit après avoir été mis à jour. Reportez-vous à la section Le jeu de données réseau n’est pas créé.
L’outil Construire le réseau a renvoyé des erreurs de construction (AVERTISSEMENT 030116)
Reportez-vous à la section Le réseau comporte des erreurs de construction non résolues.
Problèmes courants
En règle générale, les résultats d’analyse de réseau inattendus sont soit causés par des problèmes au niveau du jeu de données réseau utilisé pour l’analyse, soit par des paramètres incorrects appliqués à l’analyse. Si le jeu de données réseau et les paramètres d’analyse sont corrects, vous devez déterminer la raison pour laquelle vous avez obtenu de tels résultats.
Cette section présente plusieurs problèmes courants susceptibles de produire des résultats inattendus, ainsi que des suggestions pour les diagnostiquer et les résoudre.
- Le jeu de données réseau n’est pas créé
- Le réseau comporte des erreurs de construction non résolues
- Interruptions ou arcs pendants au niveau des intersections
- Règle de connectivité de groupe incorrecte
- Règle de connectivité verticale incorrecte
- Extrémités ou sommets manquants au niveau d’intersections spécifiques
- Configuration incorrecte de l’attribut de coût
- Restrictions incorrectes
- Déplacement incorrect dans des rues à sens unique
- Règle de demi-tour incorrecte ou très restrictive
- Tournants incorrects
- Valeurs de hiérarchie incorrectes
- Entrées localisées sur la mauvaise entité de réseau
- Paramètres de localisation incorrects
- Champs de localisation non valides ou obsolètes
- Modèle de réseau incorrect
Le jeu de données réseau n’est pas créé
Chaque fois que vous mettez à jour les propriétés d’un jeu de données réseau ou modifiez les classes d’entités source d’un réseau, il est impératif de reconstruire le jeu de données réseau avant d’utiliser ces modifications dans une analyse de réseau.
En savoir plus sur les types de mises à jour nécessitant une reconstruction
De nombreux types de résultats inattendus peuvent se produire si l’analyse est résolue alors que le réseau a été modifié, mais pas encore reconstruit. Il se peut que l’itinéraire ne tienne pas compte de rues mises à jour, que la géométrie ne corresponde pas aux entités rues sous-jacentes, que les coûts soient inexacts et que des restrictions soient ignorées.
Déterminer si le réseau doit être reconstruit
Pour savoir s’il est nécessaire de reconstruire le réseau, procédez comme suit :
- Ouvrez la boîte de dialogue Network Dataset Properties (Propriétés du jeu de données réseau).
- Cliquez sur Général.
La page affiche des informations générales sur le jeu de données réseau.
- Vérifiez les informations affichées sous la section Build Status (Statut de création).
Si le statut est Non créé, le jeu de données réseau doit être reconstruit. Si le statut est Créé, mais que le nombre de tronçons et de jonctions équivaut à 0, cela signifie qu’il y a un problème avec le jeu de données réseau, probablement des erreurs de construction non résolues.
Le réseau comporte des erreurs de construction non résolues
Lorsque vous exécutez l’outil Construire le réseau pour créer un jeu de données réseau, un message d’avertissement (AVERTISSEMENT 030116) peut indiquer que l’opération a réussi, mais que des erreurs ont eu lieu. Si certaines erreurs de construction peuvent être ignorées sans risque, d’autres sont sérieuses et peuvent produire des résultats d’analyse incorrects ou incomplets. Examinez les erreurs de construction avant de lancer l’analyse du réseau.
De nombreux types de résultats inattendus peuvent se produire si le réseau comporte des erreurs de construction non résolues. Les principaux problèmes à résoudre concernent généralement les évaluateurs d’attributs et les tournants.
Après avoir exécuté l’outil Construire le réseau, vérifiez si vous avez reçu l’AVERTISSEMENT 030116. Le message d’avertissement contient le chemin d’accès au fichier texte des erreurs de construction. Le fichier texte est stocké dans un emplacement temporaire et supprimé lorsque vous quittez ArcGIS Pro. Si vous n’avez plus accès au fichier texte des erreurs de construction, réexécutez l’outil Construire le réseau. Utilisez l’option Full rebuild (Régénération complète) pour reconstruire entièrement le réseau et vous assurer ainsi que toutes les erreurs sont visibles.
Ouvrez le fichier de messages d’erreur de construction et examinez les erreurs de construction.
Interruptions ou arcs pendants au niveau des intersections
Pour modéliser le déplacement d’une rue à une autre dans un réseau, les entités doivent être capturées correctement entre elles au niveau des intersections. Des erreurs de numérisation peuvent produire de petites interruptions entre les rues qui doivent être connectées aux intersections ou générer de petits arcs pendants (endroits où une rue dépasse légèrement une intersection au lieu de capturer l’autre rue). Ces interruptions et arcs pendants empêchent le déplacement d’une rue à l’autre dans le jeu de données réseau.
Des intersections déconnectées peuvent provoquer l’échec du calcul de l’itinéraire si aucun chemin n’est trouvé, impliquer un long détour pour trouver un itinéraire bis ou être la cause d’un tournant inattendu.
Pour vérifier la présence d’interruptions ou d’arcs pendants, ajoutez les classes d’entités source du réseau à la carte et faites un zoom avant pour inspecter visuellement une intersection problématique. Les rues se touchent-elles ou des interruptions ou arcs pendants sont-ils visibles ? Il est possible également d’utiliser l’outil Explorer le réseau pour cliquer sur une rue spécifique et identifier les autres rues qui lui sont connectées. Il est possible d’utiliser des lignes de zone de desserte pour isoler les zones à problème. Vous pouvez également utiliser la topologie pour signaler des interruptions ou des arcs pendants sur l’ensemble du réseau pouvant générer des faux positifs.
Si vous avez un petit nombre d’interruptions ou d’arcs pendants dans des localisations spécifiques, vous pouvez les corriger manuellement à l’aide des outils de mise à jour. Il est recommandé d’activer la capture pour faciliter les opérations de mise à jour. Dans le cas des entités faisant partie d’un jeu de données réseau, un comportement automatique peut vous aider à maintenir les rues parfaitement connectées.
Si vous rencontrez des problèmes d’ordre général, vous pouvez faire appel à l’outil Prolonger des lignes pour supprimer des interruptions et à l’outil Tronquer des lignes pour supprimer des arcs pendants.
Les intersections déconnectées peuvent être dues à d’autres types de problèmes :
Règle de connectivité de groupe incorrecte
Les règles de connectivité du jeu de données réseau contrôlent si les entités qui se touchent aux intersections sont considérées comme logiquement connectées dans le réseau, et s’il est possible, par conséquent, de se déplacer entre elles. La règle de connectivité de groupe contrôle les connexions entre des entités coïncidentes appartenant à différentes classes d’entités source et les connexions entre des entités coïncidentes provenant de la même classe d’entités source.
En savoir plus sur la connectivité du réseau
Bien qu’aucune règle de connectivité de groupe ne soit intrinsèquement incorrecte, elle n’est pas forcément adaptée à la configuration des classes d’entités source du réseau, et peut donner lieu à des intersections déconnectées. Le cas échéant, elle peut provoquer l’échec du calcul de l’itinéraire si aucun chemin n’est trouvé, impliquer un long détour pour trouver un itinéraire bis ou être la cause d’un tournant inattendu. Il s’agit généralement d’un problème systémique qui concerne l’ensemble du réseau et non d’un problème spécifique à une intersection ou une zone en particulier.
Le choix d’une règle de connectivité inadaptée pour les sources de tronçon est la cause la plus fréquente des problèmes liés à la règle de connectivité de groupe. Si les entités rues sont de longues lignes qui traversent de nombreuses autres entités rues, appliquez la règle de connectivité de tronçon Any Vertex (Tout sommet) au lieu de Endpoint (Extrémité). Avec la connectivité Endpoint (Extrémité), les entités sont considérées comme étant connectées à condition de se toucher au niveau de leurs extrémités. Les longues lignes qui se coupent au niveau des sommets sont donc considérées comme étant déconnectées.
Déterminer la connectivité du réseau
Pour déterminer si la connectivité du réseau pose problème, vérifiez d’abord si le réseau utilise une connectivité de type Endpoint (Extrémité) pour les sources de tronçon :
- Ouvrez la boîte de dialogue Propriétés du jeu de données réseau.
- Cliquez sur Source Settings (Paramètres de la source) > Groupe Connectivity (Connectivité de groupe).
- Vérifiez la valeur de la colonne Policy (Règle) pour chacune des sources de tronçon du réseau.
Si les sources de tronçon utilisent déjà une connectivité Any Vertex (Tout sommet), le problème peut provenir d’un autre aspect de la règle de connectivité ou être d’une toute autre nature. Cependant, si les sources de tronçon utilisent la connectivité Endpoint (Extrémité), continuez votre enquête.
- Ajoutez les classes d’entités source du réseau à la carte.
- Cliquez sur plusieurs entités rues à tour de rôle (ou sélectionnez-les une à une).
Si les entités rues sont longues et traversent de nombreuses autres entités rues, il est préférable d’appliquer la règle de connectivité Any Vertex (Tout sommet) à ces données au lieu de la règle de connectivité Endpoint (Extrémité). La règle de connectivité est probablement la cause des déconnexions.
Les intersections déconnectées peuvent être dues à d’autres types de problèmes :
- Interruptions ou arcs pendants au niveau des intersections
- Règle de connectivité verticale incorrecte
- Extrémités ou sommets manquants au niveau d’intersections spécifiques
- Tournants incorrects
Si la règle de connectivité est à l’origine du problème, il y a deux façons d’y remédier : la remplacer par la règle de connectivité Any Vertex (Tout sommet) ou fractionner les entités source aux intersections.
Remplacer la règle de connectivité par Tout sommet
Pour remplacer la règle de connectivité par Any Vertex (Tout sommet), procédez comme suit :
- Ouvrez la boîte de dialogue Propriétés du jeu de données réseau.
- Cliquez sur Source Settings (Paramètres de la source) > Groupe Connectivity (Connectivité de groupe).
- Pour la source de tronçon à modifier, utilisez la liste déroulante dans la colonne Policy (Règle) pour sélectionner la règle Any Vertex (Tout sommet) à la place de la règle Endpoint (Extrémité).
- Cliquez sur OK.
La règle de connectivité mise à jour est enregistrée dans le jeu de données réseau.
- Utilisez l’outil Construire le réseau pour recréer le jeu de données réseau en fonction de la nouvelle règle de connectivité.
En cas d’utilisation de la règle de connectivité Any Vertex (Tout sommet), examinez attentivement les passages supérieurs et les passages inférieurs. Si ces localisations possèdent un sommet, les rues ne seront pas connectées correctement. Vous pouvez corriger le problème en supprimant les sommets ou en effectuant d’autres modifications manuelles.
Fractionner les entités source au niveau des intersections
Au lieu de remplacer la règle de connectivité par Any Vertex (Tout sommet), vous pouvez continuer à utiliser la règle de connectivité Endpoint (Extrémité) à condition de modifier les entités source : fractionnez-les de façon à avoir des extrémités au niveau de tous les points d’intersection.
- Examinez et configurez les règles de fractionnement et de fusion appliquées aux domaines de votre géodatabase.
Cela est nécessaire si vos rues ont des valeurs de champ qui doivent être mises à jour chaque fois que des entités sont fractionnées (par exemple, des champs de temps ou de distance de trajet précalculés).
- Ajoutez la classe d’entités source du tronçon de réseau à la carte.
- Sélectionnez toutes les entités dans cette classe d’entités source.
- Si vos données sélectionnées contiennent des ponts, des tunnels, des passages supérieurs ou toute autre localisation où les rues passent au-dessus ou au-dessous d’une autre sans connexion physique, supprimez ces entités de la sélection.
Vous pouvez aussi corriger ces localisations manuellement une fois l’outil exécuté.
- Le cas échéant, désélectionnez les entités rues qui croisent d’autres entités rue sans connexion physique.
- Utilisez l’outil de mise à jour Planariser pour les fractionner au niveau des points d’intersection.
Règle de connectivité verticale incorrecte
Les règles de connectivité du jeu de données réseau contrôlent si les entités qui se touchent aux intersections sont considérées comme logiquement connectées dans le réseau, et s’il est possible, par conséquent, de se déplacer entre elles. La règle de connectivité verticale sert à modéliser les connexions au niveau des passages supérieurs et des passages inférieurs et des entités empilées verticalement.
En savoir plus sur la connectivité du réseau
Les problèmes en matière de connectivité verticale se limitent souvent à des intersections spécifiques. Par exemple, l’itinéraire passe sur la route en dessous en effectuant un virage à gauche en plein milieu d’un pont. Ou bien l’itinéraire ne peut pas passer par une intersection, car il est déconnecté verticalement alors qu’il ne devrait pas l’être.
Il est possible d’utiliser l’outil Explorer le réseau pour cliquer sur une rue ou une jonction spécifique et identifier les autres rues qui lui sont connectées.
Si le réseau utilise des valeurs de géométrie X, Y, Z pour contrôler la connectivité verticale, les problèmes de connectivité verticale sont probablement dus à des erreurs de géométrie des entités source. Utilisez les outils de mise à jour dans une carte ou une scène pour corriger ces erreurs de géométrie.
En savoir plus sur l’utilisation de la géométrie pour la connectivité verticale
Si le réseau utilise des champs d’élévation pour la connectivité verticale, le problème provient probablement des valeurs des champs d’élévation des entités représentant l’intersection. Si les valeurs des champs d’élévation sont identiques, les entités sont considérées comme étant connectées. Si elles sont différentes, les entités sont considérées comme étant déconnectées. Modifiez les valeurs de champ pour corriger ces problèmes de connectivité.
En savoir plus sur l’utilisation des champs d’élévation pour la connectivité verticale
Les intersections déconnectées peuvent être dues à d’autres types de problèmes :
Extrémités ou sommets manquants au niveau d’intersections spécifiques
Les règles de connectivité du jeu de données réseau contrôlent si les entités qui se touchent aux intersections sont considérées comme logiquement connectée dans le réseau, et s’il est possible, par conséquent, de se déplacer entre elles. Avec la connectivité Endpoint (Extrémité), les entités sont considérées comme étant connectées à condition que leurs extrémités coïncident. Avec la connectivité Any Vertex (Tout sommet), les entités sont considérées comme étant connectées à condition d’avoir une extrémité ou un sommet. S’il manque des extrémités ou des sommets au niveau des intersections, ces intersections ne sont pas connectées et l’itinéraire ne pourra donc pas passer par l’intersection.
En savoir plus sur la connectivité du réseau
Des intersections déconnectées peuvent provoquer l’échec du calcul de l’itinéraire si aucun chemin n’est trouvé, impliquer un long détour pour trouver un itinéraire bis ou être la cause d’un tournant inattendu. Si vous rencontrez fréquemment des problèmes de cette nature, assurez-vous d’abord que vous utilisez la règle de connectivité qui convient pour vos données. Si vous êtes convaincu que votre règle de connectivité est adaptée, mais que certaines zones posent un problème, vous devrez éventuellement procéder à un examen manuel et mettre à jour les entités au niveau de certaines intersections.
Utilisez l’outil Explorer le réseau pour cliquer sur une rue spécifique et identifier les autres rues qui lui sont connectées. Vous pouvez également utiliser la symbologie de la couche de jeu de données réseau pour symboliser les localisations des jonctions dans le jeu de données réseau. Si deux tronçons se croisent, mais n’ont aucune jonction au point d’intersection, cela signifie qu’ils ne sont pas connectés. Il est possible aussi d’utiliser des lignes de zone de desserte pour isoler les zones à problème.
Utilisez les outils de mise à jour pour apporter les corrections manuelles nécessaires aux entités.
Si vous utilisez une connectivité Any Vertex (Tout sommet), il est possible d’exécuter l’outil Intégrer pour générer automatiquement des sommets au niveau de tous les points d’intersection. Veillez d’abord à faire une copie de sauvegarde de vos données, car l’outil Intégrer peut entraîner des modifications inattendues de la géométrie de l’entité. Vérifiez manuellement les passages inférieurs et les passages supérieurs et supprimez les sommets pour les rues qui ne doivent pas être connectées.
Les intersections déconnectées peuvent être dues à d’autres types de problèmes :
Configuration incorrecte de l’attribut de coût
La résolution d’un problème de réseau implique de minimiser ou d’optimiser une valeur : la distance ou le temps de trajet, en général. La valeur à optimiser est l’attribut d’impédance du mode de déplacement utilisé par l’analyse. Vous pouvez obtenir des résultats d’analyse inattendus si l’attribut de coût utilisé pour l’impédance est inadapté, si cet attribut est mal configuré ou si les données source référencées par l’attribut possèdent des valeurs incorrectes.
Les problèmes liés aux attributs de coût se traduisent fréquemment par des distances ou des temps de trajet avec des valeurs absurdes, même si le chemin parcouru semble pertinent. Des polygones de zone de desserte très petits ou très grands peuvent également être un symptôme. Si une limite est appliquée à l’analyse, il arrive parfois qu’aucune solution ne soit trouvée en vertu de cette limite et que la suppression de la limite permette de résoudre le problème.
Assurez-vous d’abord que l’attribut de coût approprié a été utilisé comme impédance pour l’analyse. Découvrez comment vérifier l’attribut d’impédance du mode de déplacement utilisé par une couche d’analyse de réseau. Vérifiez également les unités de l’attribut d’impédance. De nombreux champs de coût de déplacement en sortie sont exprimés dans ces unités. Or, les champs et paramètres en entrée, tels que les limites, doivent être spécifiés dans ces unités.
Si l’attribut de coût utilisé convient et que les unités ont été interprétées correctement, la prochaine étape consiste à vérifier si l’attribut de coût est configuré correctement. Vous pouvez utiliser l’outil Explorer le réseau pour examiner la valeur renvoyée pour chaque élément de réseau pour un attribut de coût donné et corriger les erreurs éventuelles.
Examinez la façon dont l’attribut de coût est configuré sur les pages de propriétés du jeu de données réseau. Vérifiez, en particulier, les évaluateurs qui définissent le mode de calcul de la valeur de coût.
En savoir plus sur la configuration des attributs de coût dans un réseau
Même si l’attribut de coût est défini correctement, les valeurs calculées risquent d’être incorrectes si l’attribut utilise les évaluateurs de script de champ et que les champs référencés possèdent des valeurs incorrectes. Si c’est le cas, vous devrez éventuellement mettre à jour les classes d’entités source du réseau.
En savoir plus sur les évaluateurs de script de champ et afficher des exemples
En cas de modification de l’attribut de coût, vous devez reconstruire le réseau avant de relancer l’analyse ou d’utiliser l’outil Explorer le réseau pour examiner les valeurs.
Remarque :
Les valeurs d’attribut de coût peuvent être incorrectes si l’attribut ou les valeurs de champ de l’entité source ont été modifiés et que le réseau n’a pas été reconstruit, ou que le réseau a été reconstruit, mais qu’il comporte des erreurs de construction non résolues.Restrictions incorrectes
Les attributs de restriction servent à interdire la circulation sur certaines routes d’un réseau. Vous pouvez, par exemple, définir une restriction pour empêcher les camions de grande hauteur de passer sous des ponts trop bas ou empêcher les piétons de marcher sur des autoroutes. Si les attributs de restriction ne sont pas configurés correctement, la circulation risque d’être interdite ou autorisée à tort sur certains segments de route.
Si l’itinéraire passe par une rue qui devrait être soumise à restriction ou contourne une rue de façon inattendue, l’attribut de restriction peut être la cause du problème. Un attribut de restriction peut interdire la circulation dans des rues ne devant être soumises à aucune restriction. Des problèmes généraux de restriction peuvent provoquer l’échec du calcul d’un itinéraire si aucun chemin n’est trouvé.
Assurez-vous d’abord que les restrictions appropriées ont été appliquées pour l’analyse. Découvrez comment vérifier les restrictions s’appliquant au mode de déplacement utilisé par une couche d’analyse de réseau. Vérifiez également les valeurs des paramètres d’attribut s’appliquant à la restriction. Une restriction de hauteur comprend, par exemple, un paramètre pour spécifier la hauteur du véhicule.
Pour corriger le problème, désactivez les restrictions et relancez l’analyse. Si vous obtenez le résultat escompté, activez une à une les restrictions jusqu’à ce que le résultat change. Vous pourrez ainsi identifier la restriction qui pose un problème.
Si les restrictions appropriées ont été appliquées et que les valeurs définies pour les paramètres conviennent, la prochaine étape consiste à vérifier si les attributs de restriction sont configurés correctement. Il est possible d’utiliser l’outil Explorer le réseau pour vérifier si une route donnée est restreinte par chaque attribut de restriction et corriger les erreurs éventuelles. La symbologie de la couche de jeu de données réseau est pratique pour visualiser le statut Restreint des routes sur l’ensemble du réseau.
Examinez la façon dont l’attribut de restriction est configuré sur les pages de propriétés du jeu de données réseau. Vérifiez, en particulier, les évaluateurs qui définissent le mode de calcul du statut Restreint.
En savoir plus sur la configuration des attributs de restriction dans un réseau
Même si l’attribut de restriction est défini correctement, les valeurs calculées risquent d’être incorrectes si l’attribut utilise les évaluateurs de script de champ et que les champs référencés possèdent des valeurs incorrectes. Si c’est le cas, vous devrez éventuellement mettre à jour les classes d’entités source du réseau.
En savoir plus sur les évaluateurs de script de champ et afficher des exemples
En cas de modification des attributs de restriction, vous devez reconstruire le réseau avant de relancer l’analyse ou d’utiliser l’outil Explorer le réseau pour examiner les valeurs.
Remarque :
Les valeurs d’attribut de restriction peuvent être incorrectes si les attributs de restriction ou les valeurs de champ de l’entité source ont été modifiés et que le réseau n’a pas été reconstruit, ou que le réseau a été reconstruit, mais qu’il comporte des erreurs de construction non résolues.
Déplacement incorrect dans des rues à sens unique
Les rues à sens unique dans un jeu de données réseau sont modélisées, en principe, comme attributs de restriction. Si un itinéraire emprunte une rue en sens unique dans le mauvais sens ou évite d’emprunter une rue en sens unique dans le bon sens, il est probable que l’attribut de restriction en matière de rues à sens unique pose un problème. Reportez-vous à la section Restrictions incorrectes pour obtenir des conseils sur la façon de corriger les problèmes de restriction.
Règle de demi-tour incorrecte ou très restrictive
La règle de demi-tour du mode de déplacement utilisé dans une analyse contrôle si et où un véhicule peut effectuer un demi-tour entre des arrêts.
Pour en savoir plus sur les règles de demi-tour
Une règle de demi-tour restrictive peut entrainer l’échec d’un calcul d’itinéraire s’il n’est pas possible de se déplacer d’un arrêt à un autre sans faire de demi-tour. Des arrêts intermédiaires sur un itinéraire situés sur des voies sans issue sont une cause fréquente de ce type de problème.
Modifiez la règle de demi-tour de façon à autoriser tous les demi-tours et relancez le calcul de l’itinéraire. Si le calcul d’itinéraire réussit, il est probable que cette règle soit à l’origine du problème. Il est impossible de circuler entre les arrêts en obéissant à la règle de demi-tour sélectionnée. Vous pouvez ignorer le problème si vous êtes satisfait de l’explication donnée pour l’échec du calcul d’itinéraire. Sinon, prévoyez une règle de demi-tour moins stricte pour votre analyse. Découvrez comment vérifier et mettre à jour la règle de demi-tour pour une couche d’analyse de réseau.
Les règles de demi-tour du mode de déplacement contrôlent si et où un véhicule peut effectuer des demi-tours entre des localisations. Elles ne servent pas à contrôler si un véhicule a le droit de faire un demi-tour à un arrêt sur l’itinéraire. Certains arrêts donnent sur une voie ou un parking où il est possible de faire un demi-tour. D’autres arrêts peuvent impliquer l’arrêt du véhicule sur le bord de la route à un endroit où il est dangereux ou impossible de faire un demi-tour. Pour définir le comportement des demi-tours au niveau d’un arrêt, configurez la valeur du champ CurbApproach pour cet arrêt. Des valeurs CurbApproach restrictives utilisées conjointement à une règle de demi-tour restrictive augmentent les risques d’échec d’une résolution.
Tournants incorrects
Des restrictions spécifiques aux tournants vous empêchent de tourner d’une route à une autre ou impliquent un coût supplémentaire pour effectuer ce tournant. Les entités tournants modélisent les tournants à certaines intersections, alors que les tournants globaux peuvent être configurés pour contrôler tous les tournants d’un type spécifique (tels que les virages à gauche).
En savoir plus sur les tournants dans un jeu de données réseau
Les problèmes de configuration des tournants entraînent généralement des problèmes au niveau des intersections. Ils peuvent provoquer l’échec du calcul de l’itinéraire si aucun chemin n’est trouvé, impliquer un long détour pour trouver un itinéraire bis ou être la cause d’un tournant inattendu à un endroit illicite. Les problèmes concernant les entités tournants affectent seulement des intersections spécifiques, alors que les problèmes de configuration des tournants globaux ont un impact sur la totalité du réseau, de façon systémique.
L’intérêt des tournants dans un réseau est d’empêcher les tournants illicites et d’appliquer des délais réalistes pour négocier des tournants. Si un itinéraire ne tourne pas à une intersection, cela ne signifie pas qu’il y a un problème et que le résultat est incorrect. Examinez attentivement le tournant pour déterminer s’il se comporte comme attendu.
Les entités tournants peuvent être visualisées sur la carte grâce à la symbologie de la couche de jeu de données réseau et examinées individuellement à l’aide de l’outil Explorer le réseau. Les tournants globaux ne peuvent pas être visualisés.
L’attribut de coût utilisé comme impédance lors d’une analyse peut inclure des délais (pour négocier les tournants) pour des entités tournants, ou de façon globale en utilisant l’évaluateur de catégories de tournants. Chaque attribut de restriction utilisé lors d’une analyse peut impliquer des restrictions supplémentaires pour des tournants spécifiques. Examinez la façon dont les attributs de coût et de restriction sont configurés sur les pages de propriétés du jeu de données réseau. Vérifiez, en particulier, les évaluateurs qui définissent le mode de calcul des valeurs de coût et de restriction pour les classes d’entités tournants et les tournants par défaut.
En savoir plus sur la configuration des attributs de coût dans un réseau
En savoir plus sur la configuration des attributs de restriction dans un réseau
Il est possible de configurer des évaluateurs de classe d’entités tournants avec des évaluateurs de script de champ de script, qui font référence aux valeurs des champs dans la classe d’entités tournants. Même si l’évaluateur est configuré correctement, les valeurs calculées risquent d’être incorrectes si les champs référencés possèdent des valeurs incorrectes. Si c’est le cas, vous devrez éventuellement mettre à jour la classe d’entités tournants.
En savoir plus sur les évaluateurs de script de champ et afficher des exemples
Les processus de mise à jour peuvent aussi entraîner des problèmes au niveau des entités tournants. Les entités tournants sont liées à leurs entités tronçons correspondantes grâce à un ensemble de champs faisant référence aux valeurs ObjectID des entités tronçons. En cas de modification des tronçons, les valeurs ObjectID risquent de ne plus être synchronisées. Utilisez l’outil Mettre à jour selon la géométrie pour resynchroniser les valeurs de champ d’ID des tournants par rapport aux tronçons en vous basant sur la géométrie des entités tournants et des entités tronçons. Lors des prochains processus de mise à jour, vous pourrez utiliser les outils Renseigner les champs d’ID de substitution et Mettre à jour par des champs d’ID de substitution pour préserver les ID après modification.
En cas de modification des entités tournants ou de la configuration des attributs de coût ou de restriction, vous devez reconstruire le réseau avant de relancer l’analyse ou d’utiliser l’outil Explorer le réseau pour examiner les valeurs.
Remarque :
Les tournants peuvent être incorrects si les entités tournants ou les attributs de coût ou de restriction ont été modifiés et que le réseau n’a pas été reconstruit, ou que le réseau a été reconstruit, mais qu’il comporte des erreurs de construction non résolues.
Les intersections déconnectées peuvent être dues à d’autres types de problèmes :
Valeurs de hiérarchie incorrectes
La hiérarchie est un ordre ou rang attribué aux éléments du réseau pour améliorer les performances des résolutions de l’analyse de réseau en limitant le nombre de rues à rechercher par le solveur. Des résultats d’analyse inattendus peuvent se produire si les valeurs de hiérarchie attribuées aux tronçons sont invalides (0, par exemple) ou incomplètes (les valeurs de hiérarchie ne sont pas toutes attribuées aux tronçons du réseau), ou si le réseau est hiérarchiquement déconnecté (par exemple, les tronçons de niveau 1 ne sont pas connectés au niveau 1).
En savoir plus sur la hiérarchie dans un réseau
Les problèmes de hiérarchie sont subtils et peuvent s’avérer difficiles à identifier. Il est possible que les chemins proposés en guise d’itinéraire ne vous semblent pas optimaux. Il arrive parfois qu’un itinéraire soit introuvable, mais qu’un itinéraire (bien meilleur ou non) soit proposé dès que vous rapprochez des arrêts entre eux. Il peut aussi arriver que les coûts de déplacement entre des localisations inchangées diffèrent dès lors que d’autres points sont ajoutés ou supprimés (notamment dans le cas d’une matrice de coût OD).
Pour savoir si la hiérarchie est la cause du problème, relancez la résolution de l’analyse en désactivant la hiérarchie.
Apprendre à vérifier si une hiérarchie a été utilisée à des fins d’analyse et à la désactiver
Si la hiérarchie semble poser un problème, examinez la façon dont l’attribut de hiérarchie est configuré sur les pages de propriétés du jeu de données réseau. Vérifiez, en particulier, les évaluateurs qui définissent le mode de calcul des valeurs de hiérarchie pour chaque tronçon, puis examinez les valeurs de la plage de hiérarchie.
En savoir plus sur la configuration des attributs de hiérarchie dans un réseau
Les attributs de hiérarchie sont fréquemment configurés pour faire référence aux valeurs de classes de routes. Même si l’attribut de hiérarchie est défini correctement, les valeurs calculées risquent d’être incorrectes si l’attribut utilise les évaluateurs de script de champ pour faire référence aux valeurs de classes de routes ou à d’autres champs, et que les champs référencés possèdent des valeurs incorrectes. Si c’est le cas, vous devrez éventuellement mettre à jour les classes d’entités source du réseau.
En savoir plus sur les évaluateurs de script de champ et afficher des exemples
Entrées localisées sur la mauvaise entité de réseau
Il est rare que les localisations géographiques des entrées utilisées dans une analyse de réseau intersectent parfaitement les tronçons et les jonctions du réseau. C’est la raison pour laquelle un processus de localisation de toutes les entrées sur le réseau est lancé, afin de trouver la localisation de réseau routable la plus proche.
En savoir plus sur la localisation des points dans un réseau
Utilisez l’outil Explorer les localisations pour visualiser la localisation de réseau pour chaque point en entrée de l’analyse. Pour visualiser toutes les localisations de réseau à la fois, utilisez l’outil Table XY vers points avec les champs SnapX et SnapY pour créer une couche des entrées à leurs localisations de réseau. Lors du chargement des entrées dans l’analyse, vous pouvez utiliser l’option Snap to Network (Capturer sur le réseau) dans l’outil Ajouter des localisations au moment d’importer des entrées dans une couche d’analyse de réseau. Cette option crée les points en entrée à leurs localisations de réseau (avec un certain décalage) au lieu de les laisser à leurs localisations d’origine.
Si les points sont localisés sur la mauvaise entité de réseau, l’itinéraire risque de débuter ou de terminer à une localisation inattendue. Il est rare, en général, que les points soient localisés sur la mauvaise entité de réseau. Ils se trouvent sur l’élément de réseau non restreint le plus proche, selon les paramètres de localisation appliqués. Il est important de bien comprendre les règles de localisation et il peut être nécessaire d’ajuster les paramètres de localisation ou les localisations géographiques des points en entrée pour s’assurer que les points se trouvent aux localisations désirées.
Par défaut, les entrées ne sont pas localisées sur des éléments de réseau soumis à des restrictions ou sujets à des interruptions qui interdisent la circulation. Vous avez ainsi l’assurance que chaque point est accessible, même s’il n’est pas possible d’accéder à la localisation de réseau la plus proche. Pour identifier les points en entrée dans cette situation, recherchez la valeur 7 (Non localisé sur le plus proche) dans le champ Status de la table en entrée. Utilisez l’outil Explorer le réseau et la symbologie de la couche de jeu de données réseau pour identifier les éléments du réseau soumis à des restrictions. Si les restrictions semblent incorrectes, reportez-vous à la section Restrictions incorrectes pour en savoir plus à ce sujet.
Il est possible d’utiliser des paramètres de localisation pour contrôler où et comment les points sont localisés, en veillant à les configurer correctement pour éviter d’obtenir des résultats indésirables. Pour plus d’informations sur les paramètres de localisation, reportez-vous à la section Paramètres de localisation incorrects.
Les points peuvent se trouver sur des rues latérales et non pas sur les rues elles-mêmes si l’adresse est associée à l’entrée de l’allée. Cela arrive, en général, quand le point est géographiquement plus proche de la rue latérale, ce qui est souvent le cas si vous utilisez des centroïdes de parcelles ou des points de localisation d’adresse de toit. Ces points peuvent être corrigés de façon manuelle. Toutefois, il peut être préférable d’effectuer un prétraitement avant de localiser les points dans un réseau, notamment pour corriger un problème à grande échelle. Ajustez, au besoin, les paramètres de localisation et chargez à nouveau les entrées en appliquant ces nouveaux paramètres. Si les entrées ont été générées par géocodage des adresses, essayez de les géocoder à nouveau en utilisant la localisation d’itinéraire au lieu de la localisation de toit, si le localisateur utilisé offre cette possibilité. Vous pouvez utiliser l’outil Attribuer des rues à des points pour générer des localisations correspondant à des adresses le long de la rue appropriée.
Si vous avez précalculé les localisations de réseau, il se peut que les champs de localisation soient obsolètes ou non valides.
Paramètres de localisation incorrects
Il est rare que les localisations géographiques des entrées utilisées dans une analyse de réseau intersectent parfaitement les tronçons et les jonctions du réseau. C’est la raison pour laquelle un processus de localisation de toutes les entrées sur le réseau est lancé, afin de trouver la localisation de réseau routable la plus proche.
En savoir plus sur la localisation des points dans un réseau
Divers paramètres de localisation contrôlent la façon dont les entrées sont localisées sur le réseau. Les paramètres de localisation déterminent sur quelles sources de jonctions et de tronçons de réseau les points peuvent être localisés, ainsi que la distance de recherche à appliquer. Un paramètre a été prévu également pour définir si les points peuvent être automatiquement relocalisés au moment de la résolution d’analyse (lorsque ces points sont localisés sur un élément qui vient d’être restreint par une interruption ou dont le mode de déplacement a changé).
Si les entrées de votre analyse semblent localisées au mauvais emplacement, vérifiez les paramètres de localisation pour vous assurer d’utiliser les valeurs prévues.
Champs de localisation non valides ou obsolètes
Il est rare que les localisations géographiques des entrées utilisées dans une analyse de réseau intersectent parfaitement les tronçons et les jonctions du réseau. C’est la raison pour laquelle un processus de localisation de toutes les entrées sur le réseau est lancé, afin de trouver la localisation de réseau routable la plus proche. La localisation de réseau est stockée dans un ensemble de champs de la table des entrées.
En savoir plus sur la localisation des points dans un réseau
Vous pouvez précalculer des champs de localisation de réseau et les réutiliser pour différentes analyses. Cependant, les champs de localisation de réseau sont valides uniquement pour le jeu de données réseau et le mode de déplacement pour lesquels ils ont été calculés à l’origine. En cas d’utilisation de champs de localisation pour une analyse dont le réseau ou le mode de déplacement diffère, ou si le réseau est mis à jour après le calcul des champs de localisation, il est probable que ceux-ci soient non valides et causent un comportement inattendu lors de l’analyse. Les itinéraires peuvent débuter ou s’arrêter à des endroits inattendus et certains points risquent de ne pas être localisés.
Utilisez l’outil Calculer les localisations pour recalculer les localisations de réseau pour les entrées d’analyse en sélectionnant le jeu de données réseau et le mode de déplacement que vous prévoyez d’utiliser pour l’analyse.
Modèle de réseau incorrect
Les classes d’entités source du jeu de données réseau doivent inclure des routes ou d’autres entités sur lesquelles il est possible de se déplacer, ainsi que des jonctions modélisant les intersections et des tournants modélisant les transitions au niveau des intersections. Une fois le jeu de données réseau créé, vous pouvez l’utiliser pour résoudre des analyses de réseau telles que le calcul d’itinéraires et des zones de desserte. Les entrées de ces analyses (arrêts, ressources et interruptions, par exemple) ne doivent pas faire partie du jeu de données réseau. Elles sont spécifiques à chaque analyse. Un même jeu de données réseau peut être utilisé par différentes analyses.
Le fait d’inclure les entrées d’analyse dans le jeu de données réseau peut être à l’origine de nombreux types d’erreurs et d’un comportement inattendu. De façon générale, le calcul des itinéraires risque d’échouer si les entrées sont localisées sur des jonctions déconnectées du reste du réseau. Par ailleurs, la construction du réseau peut générer des erreurs de construction dans le cas de jonctions autonomes définies par l’utilisateur.
Veillez à ne pas inclure des entrées d’analyse en tant qu’entités source dans le jeu de données réseau. Supprimez-les du réseau, reconstruisez le réseau, puis relancez l’analyse.
En savoir plus sur le mode de création d’un jeu de données réseau
Outils et techniques de dépannage
Cette section décrit plusieurs outils et techniques pour remédier à des résultats d’analyse de réseau inattendus.
- Explorer le réseau
- Symbologie de la couche de jeu de données réseau
- Lignes de zone de desserte
- Topologie
- Explorer les localisations
- Fichiers ou paquetages de couches en sortie issus des résultats d’un objet de solveur du module arcpy.nax
Explorer le réseau
Vous pouvez examiner dans l’affichage cartographique les attributs et éléments de réseau d’un jeu de données réseau référencé par une couche de jeu de données réseau ou couche d’analyse de réseau à l’aide de l’outil Explorer le réseau. Cet outil peut aider à identifier les éléments suivants :
- Les éléments de réseau qui sont associés à une entité rue source
- Les autres éléments de réseau adjacents
- Le coût pour le traverser
- Si les attributs sont configurés correctement pour renvoyer les valeurs attendues
- S’il existe une restriction par le mode de déplacement actif
Commencez toujours par utiliser l’outil Explorer le réseau pour examiner et diagnostiquer de nombreux types de résultats d’analyse inattendus.
En savoir plus sur l’outil Explore Network (Explorer le réseau)
Lorsque vous utilisez l’outil Explorer le réseau pour déterminer la cause de résultats d’analyse inattendus, ajustez les paramètres de cet outil de façon à utiliser le même mode de déplacement que la couche d’analyse de réseau inspectée. Vous aurez ainsi l’assurance que les valeurs affichées pour les attributs de l’outil correspondent à celles utilisées dans l’analyse.
L’outil Explorer le réseau et la symbologie de la couche de jeu de données réseau sont complémentaires. Alors que la symbologie de la couche de jeu de données réseau est pratique pour évaluer visuellement l’exactitude générale du réseau et le schéma des rues soumises à restriction, l’outil Explorer le réseau s’avère utile pour examiner des éléments de réseau spécifiques ou des zones à problème.
Symbologie de la couche de jeu de données réseau
Il est possible d’ajuster la symbologie de la couche de jeu de données réseau pour faciliter le dépannage. En plus de contrôler le rendu de base des tronçons de réseau, des jonctions, des tournants, du trafic et des zones à valider, la fenêtre Symbologie d’une couche du jeu de données réseau permet d’effectuer le rendu d’éléments de réseau (en fonction de leur statut de restriction pour des modes de déplacement spécifiques) et d’afficher des flèches sur des éléments de tronçon pouvant être traversés dans un seul sens (routes à sens unique).
En savoir plus sur la symbologie de la couche de jeu de données réseau
La symbologie de la couche de jeu de données réseau et l’outil Explorer le réseau sont complémentaires. Alors que l’outil Explorer le réseau s’avère utile pour examiner des éléments de réseau spécifiques ou des zones à problème, la symbologie de la couche de jeu de données réseau est pratique pour évaluer visuellement l’exactitude générale du réseau et le schéma des rues soumises à restriction.
Lorsque vous utilisez la symbologie de la couche de jeu de données réseau pour déterminer la cause de résultats d’analyse inattendus, ajustez les options de symbologie de façon à utiliser le même mode de déplacement que la couche d’analyse de réseau inspectée. Vous aurez ainsi l’assurance que la symbologie affichée sur la carte correspond aux paramètres utilisés pour l’analyse.
Lignes de zone de desserte
Le solveur de zone de desserte est communément employé pour générer des polygones représentant la zone accessible en un temps de trajet donné ou à une distance limite d’une localisation particulière. Cependant, le solveur a aussi la possibilité de générer des entités linéaires pour représenter les rues accessibles dans le temps de trajet imparti ou la distance limite indiquée. Les lignes de zone de desserte peuvent s’avérer très pratiques pour évaluer et résoudre des problèmes de connectivité de réseau.
Pour utiliser les lignes de zone de desserte en vue de résoudre les problèmes de connectivité de réseau, créez une couche d’analyse de zone de desserte, définissez le type de sortie sur Lignes, ajoutez une ressource à proximité de la zone à inspecter, puis définissez une valeur limite suffisamment élevée pour accéder à la totalité de la zone en question. Si les lignes de zone de desserte en sortie ne comprennent pas de zones ou de rues individuelles, celles-ci sont susceptibles d’être déconnectées. Utilisez l’outil Explorer le réseau pour examiner, de façon plus approfondie, la connectivité dans certaines zones à problème.
Apprendre à effectuer une analyse de la zone de desserte dans ArcGIS Pro
Topologie
Il est possible d’utiliser la topologie de la géodatabase pour identifier, analyser et corriger les problèmes de géométrie des entités linéaires susceptibles de causer des problèmes dans un jeu de données réseau et de fausser les résultats des analyses de réseau. Vous pouvez utiliser la topologie au moment de créer un réseau ou lors de la correction de problèmes généraux de géométrie dans les entités source d’un jeu de données réseau existant.
Utiliser la topologie pour identifier et corriger des problèmes
Procédez comme suit pour utiliser la topologie en vue d’identifier et de corriger des problèmes dans les entités source de réseau :
- Créez une topologie.
- Ajoutez une ou plusieurs classes d’entités à la topologie.
- Ajoutez des règles à la topologie.
- Validez la topologie en appliquant les règles aux classes d’entités.
- Utilisez la fenêtre Inspecteur d’erreurs pour analyser et résoudre les problèmes identifiés.
De nombreuses règles de topologie sont applicables aux entités linéaires. Les règles recommandées pour les entités source de réseau sont les suivantes : « Ne doivent pas se superposer à (Ligne) », « Ne doivent pas s’auto-superposer (Ligne) », « Ne doivent pas être auto-sécantes (Ligne) » et « Ne doivent être coïncidentes qu’aux extrémités (Ligne) ».
En savoir plus sur les règles de topologie applicables aux entités linéaires
Explorer les localisations
L’outil Explorer les localisations est pratique pour visualiser les localisations de réseau des entrées d’analyse et examiner leurs champs de localisation de réseau. Utilisez cet outil pour corriger les erreurs de localisation des entrées sur le réseau et expérimenter différents paramètres de localisation.
En savoir plus sur la localisation des points dans un réseau
L’outil Explorer les localisations est accessible à partir du ruban de la couche d’analyse de réseau. Une fois que cet outil est actif, cliquez sur l’entité en entrée pour voir où elle est localisée sur le réseau et afficher ses champs de localisation.
Fichiers ou paquetages de couches en sortie issus des résultats d’un objet de solveur du module arcpy.nax
Si vous procédez à la résolution d’analyses de réseau dans Python à l’aide des objets de solveur du module arcpy.nax, utilisez la méthode saveAsLayerFile() pour enregistrer les paramètres et les résultats d’analyse dans un fichier ou paquetage de couche, de façon à pouvoir l’examiner et le tester sur une carte. Rappelez-vous, cependant, que le schéma des entrées et sorties de la couche d’analyse de réseau est différent, dans de nombreux cas, du schéma utilisé par les objets de solveur du module arcpy.nax.
Conseils de dépannage pour des solveurs spécifiques
Rappelez-vous que chaque solveur Network Analyst produit différents types de résultats et que les types de problèmes décrits sur cette page ne se manifestent pas toujours de la même façon. Cette section décrit les techniques permettant de dépanner certains solveurs.
Itinéraire
Lorsqu’un itinéraire comporte plusieurs arrêts, essayez de les supprimer à tour de rôle jusqu’à ce que le résultat change ou que le problème soit résolu. Vous pourrez en déduire que le dernier arrêt supprimé est probablement la cause du problème.
Zone de desserte
Les polygones de zone de desserte sont une représentation artistique de la zone accessible jusqu’à la limite spécifiée et le polygone en sortie peut varier considérablement en fonction des paramètres définis par l’utilisateur. La solution algorithmique d’une analyse de zone de desserte correspond aux rues ayant été atteintes. Configurez la zone de desserte de façon à renvoyer les lignes en sortie et repérer les rues atteintes. Les lignes de zone de desserte peuvent souvent s’avérer utiles pour détecter des problèmes avec le jeu de données réseau utilisé pour l’analyse.
Matrice de coût OD
Il peut être difficile d’identifier et de diagnostiquer les résultats inattendus d’une analyse de matrice de coût OD, si les chemins entre les origines et les destinations sur le réseau ne sont pas disponibles. Pour évaluer les problèmes posés par une paire origine-destination en particulier, utilisez le solveur d’itinéraire pour afficher le chemin suivi.
Si l’analyse porte sur un grand nombre d’origines et de destinations, essayez de limiter le nombre d’origines ou de destinations permettant de reproduire le problème au strict minimum.
Les lignes en sortie comprennent un enregistrement pour chaque paire origine-destination pour laquelle un chemin a été trouvé. Si la table de lignes ne contient aucun enregistrement pour une paire origine-destination, aucun chemin répondant aux contraintes définies pour l’analyse (la limite spécifiée ou le nombre de destinations à rechercher, par exemple) ne peut être trouvé.
Vous avez un commentaire à formuler concernant cette rubrique ?