Disponible avec la licence Location Referencing.
Lors du réalignement d’un itinéraire, les événements sont affectés dans la zone de l’opération de mise à jour, ainsi qu’en amont et en aval du réalignement, selon le comportement des événements configuré pour chaque couche d’événements.
Remarque :
Après la mise à jour de l’itinéraire, les événements sont actualisés dès que l’outil Appliquer des comportements d’événement est exécuté. Si vous utilisez la prévention des conflits sur les données de branche versionnée, un message vous invite à exécuter l’outil Appliquer les comportements d’événement pour procéder à la réinjection de la version par défaut.
Remarque :
Lorque Recalibrate route downstream (Recalibrer l’itinéraire en aval) est sélectionné pour la mise à jour d’un itinéraire LRS, le comportement d’événement de calibrage d’itinéraire est appliqué aux sections en aval. Vous pouvez passer en revue les comportements d’événement en consultant les propriétés des événements LRS.
Le réalignement de l’itinéraire et les comportements d’événement correspondants sont décrits ci-dessous.
Scénario de réalignement d’itinéraire
Vous pouvez utiliser l’outil Réaligner pour réaligner un itinéraire unique ou plusieurs itinéraires adjacents faisant partie de la même ligne. Pour un réseau linéaire, vous pouvez réattribuer les segments d’itinéraire de la zone de réalignement à l’itinéraire abandonné.
Consultez la section Réaligner avec les scénarios d’abandon dans un réseau de ligne avec un événement de capture ci-dessous pour en savoir plus.
Sections en amont et en aval
La mise à jour de l’itinéraire impacte les sections en amont et en aval de manière différente.
L’image suivante illustre les sections en amont et en aval impliquées dans le scénario de réalignement de l’itinéraire :
Le tableau suivant fournit des informations supplémentaires sur la manière dont les événements sont affectés par un réalignement selon le comportement d’événement configuré :
| Comportement | Événements en amont du réalignement | Événements formant une intersection avec le réalignement | Événements en aval du réalignement |
|---|---|---|---|
| Immobile | Aucune action. | L’événement est retiré ; les événements linéaires traversant la section de mise à jour ne sont pas divisés et l’événement original est retiré. | Si le calibrage de l’itinéraire est modifié, le comportement d’événement de calibrage est appliqué ; dans le cas contraire, aucune action n’est effectuée. |
| Déplacer | Aucune action. | La forme est régénérée selon une nouvelle localisation des mesures d’itinéraire. | Si le calibrage de l’itinéraire est modifié, le comportement d’événement de calibrage est appliqué ; dans le cas contraire, aucune action n’est effectuée. |
| Retirer | Aucune action. | Événement Retirer. | Si le calibrage de l’itinéraire est modifié, le comportement d’événement de calibrage est appliqué ; dans le cas contraire, aucune action n’est effectuée. |
| Couverture | Aucune action. | L’événement est retiré ; les événements linéaires traversant la section de mise à jour ne sont pas divisés et sont déplacés proportionnellement sur les localisations du nouvel itinéraire. | Si le calibrage de l’itinéraire est modifié, le comportement d’événement de calibrage est appliqué ; dans le cas contraire, aucune action n’est effectuée. |
| Capturer | Aucune action. | L’événement est retiré ; le nouvel événement retiré est capturé sur un itinéraire coïncident, s’il en existe un. | Si le calibrage de l’itinéraire est modifié, le comportement d’événement de calibrage est appliqué ; dans le cas contraire, aucune action n’est effectuée. |
Remarque :
Le réseau peut inclure des événements qui couvrent des itinéraires d’un réseau linéaire. Les comportements sont toujours appliqués de la même manière.
Lorsque le LRS possède une dimension temporelle, les opérations de mise à jour, telles que le réalignement d’un itinéraire, entraînent le découpage des itinéraires et des événements en intervalles temporels.
Résultats du réalignement d’itinéraire
Dans cet exemple, Route1 est actif à partir du 01/01/2000. Le réalignement est défini pour se produire le 01/01/2005, lors de la réorientation du milieu de Route1 vers une nouvelle localisation, effectuée avec la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) cochée. Les images et tables ci-dessous présentent les informations sur l’itinéraire avant et après le réalignement.
Remarque :
Lors du réalignement d’un itinéraire, vous pouvez fournir de nouvelles mesures pour la portion réalignée de l’itinéraire.
Si vous utilisez un réseau non linéaire avec la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) désélectionnée, la valeur To Measure (Mesure d’arrivée) indiquée doit être inférieure à la mesure du point de calibrage en aval le plus proche pour que l’itinéraire reste monotonique. Cochez la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) si la mesure d’arrivée du réalignement doit être supérieure à celle du point de calibrage en aval le plus proche.
Lorsque vous utilisez un réseau linéaire, les valeurs des mesures fournies et l’option Recalibrate route downstream (Recalibrer l’itinéraire en aval) déterminent si les nouveaux itinéraires vont être créés sur la ligne de l’itinéraire réaligné.
Pour plus d’informations, reportez-vous aux rubriques Réaligner des itinéraires et Comportement d’événement en cas de calibrage de l’itinéraire.
Avant le réalignement de l’itinéraire
L’image suivante présente l’itinéraire avant le réalignement :
Le tableau suivant donne des détails sur l’itinéraire avant le réalignement :
| Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|
| Route1 | 01/01/2000 | <Nul> | 0 | 20 |
Après le réalignement de l’itinéraire
Dans ce scénario, Route1 comporte une mesure mise à jour à la fin du réalignement. La nouvelle mesure est 18 et est inférieure à la mesure du point de calibrage en aval le plus proche (20). Par conséquent, Route1 reste monotonique et est recalibrée entre les mesures 6 à 20, avec la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) cochée. La mesure d’arrivée de Route1 n’a pas changé.
L’image suivante présente l’itinéraire après le réalignement.
Le tableau suivant contient des détails sur l’itinéraire après le réalignement :
| Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|
| Route1 | 01/01/2000 | 01/01/2005 | 0 | 20 |
| Route1 | 01/01/2005 | <Nul> | 0 | 20 |
Événements avant le réalignement de l’itinéraire
Route1 comporte trois événements qui ont tous une date de début fixée au 01/01/2000. L’image suivante présente l’itinéraire et les événements avant le réalignement :
Le tableau suivant contient des détails sur les événements avant le réalignement :
| Événement | Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|---|
| Event1 | Route1 | 01/01/2000 | <Nul> | 0 | 8 |
| Event2 | Route1 | 01/01/2000 | <Nul> | 8 | 12 |
| Event3 | Route1 | 01/01/2000 | <Nul> | 12 | 20 |
Les sections suivantes décrivent la façon dont les règles de comportement d’événement sont appliquées après l’exécution de l’outil Appliquer les comportements d’événement dans ce scénario de réaffectation d’itinéraire.
Comportement d’événement Immobile
Même si la localisation géographique de l’événement est conservée, les mesures peuvent changer. L’événement peut également être divisé s’il traverse la région réalignée. Des parties des événements dans la région réalignée sont retirées.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Immobile |
| Calibrer | Immobile |
Remarque :
Bien que la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) ne soit pas cochée, l’itinéraire est recalibré depuis le début du réalignement sur le point de calibrage en aval le plus proche. Le comportement d’événement Calibrer est appliqué aux événements dans les sections impactées de l’itinéraire.
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Un nouvel événement est créé sur l’itinéraire postérieur au réalignement, avec une date de réalignement correspondant à la date de début. La mesure de départ prend la valeur 0 et la mesure d’arrivée la valeur 6 pour s’adapter aux nouvelles mesures de Route1.
- Event2 est retiré à la date de réalignement, car il se trouve en totalité dans la section de mise à jour.
- Event3 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Un nouvel événement est créé sur l’itinéraire postérieur au réalignement, avec une date de réalignement correspondant à la date de début. La mesure de départ de l’événement prend la valeur 18 et la mesure d’arrivée la valeur 20 pour s’adapter aux nouvelles mesures de Route1.
L’image suivante présente l’itinéraire et les événements après le réalignement :
Remarque :
L’événement retiré n’est pas représenté dans l’image ci-dessus.
Le tableau suivant contient des détails sur les événements après le réalignement :
| Événement | Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|
| Event1 | Route1 | 01/01/2000 | 01/01/2005 | 0 | 8 | Aucune erreur |
| Event1 | Route1 | 01/01/2005 | <Nul> | 0 | 6 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 8 | 12 | Aucune erreur |
| Event3 | Route1 | 01/01/2000 | 01/01/2005 | 12 | 20 | Aucune erreur |
| Event3 | Route1 | 01/01/2005 | <Nul> | 18 | 20 | Aucune erreur |
Comportement d’événement Déplacer
Même si les mesures de l’événement sont conservées, la localisation géographique peut changer.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Déplacer |
| Calibrer | Immobile |
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Un nouvel événement est créé sur l’itinéraire postérieur au réalignement, avec une date de réalignement correspondant à la date de début. Comme les mesures restent identiques pour le comportement Déplacer, l’événement se déplace sur la nouvelle localisation de Route1 pour conserver ses valeurs initiales de mesure de départ et d’arrivée de 0 à 8.
- Event2 est retiré à la date de réalignement, car il se trouve en totalité dans la section de mise à jour. Un nouvel événement est créé sur l’itinéraire postérieur au réalignement, avec une date de réalignement correspondant à la date de début. Comme les mesures restent identiques pour le comportement Déplacer, l’événement se déplace sur la nouvelle localisation de Route1 pour conserver ses valeurs initiales de mesure de départ et d’arrivée de 8 à 12.
- Event3 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Un nouvel événement est créé sur l’itinéraire postérieur au réalignement, avec une date de réalignement correspondant à la date de début. Comme les mesures restent identiques pour le comportement Déplacer, l’événement se déplace sur la nouvelle localisation de Route1 pour conserver ses valeurs initiales de mesure de départ et d’arrivée de 12 à 20.
L’image suivante présente l’itinéraire et les événements après le réalignement :
Le tableau suivant contient des détails sur les événements après le réalignement :
| Événement | Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|
| Event1 | Route1 | 01/01/2000 | 01/01/2005 | 0 | 8 | Aucune erreur |
| Event1 | Route1 | 01/01/2005 | <Nul> | 0 | 8 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 8 | 12 | Aucune erreur |
| Event2 | Route1 | 01/01/2005 | <Nul> | 8 | 12 | Aucune erreur |
| Event3 | Route1 | 01/01/2000 | 01/01/2005 | 12 | 20 | Aucune erreur |
| Event3 | Route1 | 01/01/2005 | <Nul> | 12 | 20 | Aucune erreur |
Comportement d’événement Retirer
Les événements intersectant la région de réalignement sont retirés. Les trois événements sont retirés.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Retirer |
| Calibrer | Immobile |
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Une partie d’Event1 se trouvait dans la portion du réalignement ; Event1 est retiré à la date du réalignement.
- Event2 se trouvait en totalité dans la portion du réalignement ; il est retiré à la date du réalignement.
- Une partie d’Event3 se trouvait dans la portion du réalignement ; Event3 est retiré à la date du réalignement.
L’image suivante présente l’itinéraire et les événements après le réalignement :
Le tableau suivant contient des détails sur les événements après le réalignement :
| Événement | Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|
| Event1 | Route1 | 01/01/2000 | 01/01/2005 | 0 | 8 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 8 | 12 | Aucune erreur |
| Event3 | Route1 | 01/01/2000 | 01/01/2005 | 12 | 20 | Aucune erreur |
Comportement d’événement Couvrir
Si l’événement se trouve dans la zone de réalignement, sa forme change proportionnellement pour couvrir la partie réalignée de l’itinéraire. Les mesures de l’événement sont également mises à jour en fonction de la nouvelle forme.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Couverture |
| Calibrer | Immobile |
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Un nouvel événement est créé sur l’itinéraire postérieur au réalignement, avec une date de réalignement correspondant à la date de début. Une partie de l’événement se trouvant dans la zone de réalignement, cette partie d’Event1 est rallongée proportionnellement pour couvrir la longueur augmentée de l’itinéraire en raison du réalignement. Les mesures de départ et d’arrivée passent de 0 à 9.
- Event2 est retiré à la date de réalignement, car il se trouve en totalité dans la section de mise à jour. Un nouvel événement est créé sur l’itinéraire postérieur au réalignement, avec une date de réalignement correspondant à la date de début. Comme une partie de l’événement se trouve dans la zone de réalignement, la totalité de l’événement est rallongée proportionnellement pour couvrir la longueur augmentée de l’itinéraire en raison du réalignement. Les mesures de départ et d’arrivée passent de 9 à 15.
- Event3 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Un nouvel événement est créé sur l’itinéraire postérieur au réalignement, avec une date de réalignement correspondant à la date de début. Une partie de l’événement se trouvant dans la zone de réalignement, cette partie d’Event3 est rallongée proportionnellement pour couvrir la longueur augmentée de l’itinéraire en raison du réalignement. Les mesures de départ et d’arrivée passent de 15 à 20.
L’image suivante présente l’itinéraire et les événements après le réalignement :
Le tableau suivant contient des détails sur les événements après le réalignement :
| Événement | Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|
| Event1 | Route1 | 01/01/2000 | 01/01/2005 | 0 | 8 | Aucune erreur |
| Event1 | Route1 | 01/01/2005 | <Nul> | 0 | 9 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 8 | 12 | Aucune erreur |
| Event2 | Route1 | 01/01/2005 | <Nul> | 9 | 15 | Aucune erreur |
| Event3 | Route1 | 01/01/2000 | 01/01/2005 | 12 | 20 | Aucune erreur |
| Event3 | Route1 | 01/01/2005 | <Nul> | 15 | 20 | Aucune erreur |
Comportement d’événement Capturer
Même si la localisation géographique de l’événement est conservée en faisant une capture sur la localisation du nouvel itinéraire de réalignement, les mesures peuvent changer. L’événement peut également être divisé s’il traverse la zone de réalignement où des itinéraires coïncidents existent.
Dans cet exemple, Route2 et Route1 coïncident. Route2 est dans la direction inverse et a des valeurs de mesure de départ et d’arrivée de 0 à 20.
Remarque :
Pour avoir davantage d’exemples de scénarios d’itinéraire concurrents, consultez la section Comportements d’événement de réalignement détaillé avec les itinéraires concurrents ci-dessous.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Capturer |
| Calibrer | Immobile |
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il se divise ensuite en deux enregistrements d’événement sur les itinéraires postérieurs au réalignement, la date de réalignement correspondant à la date de début. Cela est dû au fait qu’il existe un itinéraire coïncident dans la section de réalignement, et que la partie d’Event1 se trouvant dans la section de réalignement effectue la capture sur Route2 (l’itinéraire coïncident) après le réalignement. Il est également inversé pour tenir compte de la direction de Route2. Par conséquent, Event1 est divisé en deux parties pour conserver sa localisation géographique. L’enregistrement du premier événement et a des valeurs de mesure de départ et d’arrivée de 0 à 6 sur Route1. L’enregistrement du deuxième événement effectue la capture sur Route2 et a des valeurs de mesure de départ et d’arrivée de 12 à 14 sur Route2.
- Event2 est retiré à la date de réattribution, car il se trouve en totalité dans la section de mise à jour. Comme il existe un itinéraire coïncident dans la section de réalignement, l’événement Event2 effectue la capture sur Route2, l’itinéraire coïncident, après le réalignement. Il est également inversé pour tenir compte de la direction de Route2. La date de réalignement de l’enregistrement du nouvel événement correspond à la date de début. Les nouvelles valeurs de mesure de départ et d’arrivée d’Event2 passent de 8 à 12 sur Route2 pour conserver la localisation géographique d’Event2.
- Event3 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il se divise ensuite en deux enregistrements d’événement sur les itinéraires postérieurs au réalignement, la date de réalignement correspondant à la date de début. Cela est dû au fait qu’il existe un itinéraire coïncident dans la section de réalignement, et que la partie d’Event3 se trouvant dans la section de réalignement effectue la capture sur Route2 (l’itinéraire coïncident) après le réalignement. Il est également inversé pour tenir compte de la direction de Route2. Par conséquent, Event3 est divisé en deux parties pour conserver sa localisation géographique. L’enregistrement du premier événement a des valeurs de mesure de départ et d’arrivée de 18 à 20 sur Route1.L’ L’enregistrement du deuxième événement effectue la capture sur Route2 et a des valeurs de mesure de départ et d’arrivée de 6 à 8 sur Route2.
L’image suivante présente l’itinéraire et les événements après le réalignement :
Le tableau suivant contient des détails sur les événements après le réalignement :
| Événement | Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|
| Event1 | Route1 | 01/01/2000 | 01/01/2005 | 0 | 8 | Aucune erreur |
| Event1 | Route1 | 01/01/2005 | <Nul> | 0 | 6 | Aucune erreur |
| Event1 | Route2 | 01/01/2005 | <Nul> | 12 | 14 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 8 | 12 | Aucune erreur |
| Event2 | Route2 | 01/01/2005 | <Nul> | 8 | 12 | Aucune erreur |
| Event3 | Route1 | 01/01/2000 | 01/01/2005 | 12 | 20 | Aucune erreur |
| Event3 | Route1 | 01/01/2005 | <Nul> | 18 | 20 | Aucune erreur |
| Event3 | Route2 | 01/01/2005 | <Nul> | 6 | 8 | Aucune erreur |
Scénarios de réalignement avec abandon dans un réseau linéaire avec événements étendus
Si le réseau sélectionné est un réseau linéaire, vous pouvez réattribuer la section d’itinéraire de la zone de réalignement à l’itinéraire abandonné, qui est un nouvel itinéraire sur une nouvelle ligne. Tous les événements de la section de réalignement se conforment au comportement des événements lors de la réattribution. Pour transférer les événements vers l’itinéraire abandonné, configurez le comportement Capturer pour le type de mise à jour de l’itinéraire réattribué.
Dans cet exemple, quatre itinéraires figurent sur LineA et sont actifs à partir du 01/01/2000. Le réalignement est défini pour se produire le 01/01/2005 entre le milieu de Route2 et le milieu de Route4 et il a des mesures de 20 à 45. Un nouvel itinéraire est donc créé dans la section du réalignement. Le nouvel itinéraire est nommé Route3A. La case Recalibrate route downstream (Recalibrer l’itinéraire en aval) n’est pas cochée, mais l’option Reassign to abandoned route (Réattribuer à l’itinéraire abandonné) l’est dans cette mise à jour.
Remarque :
Le comportement d’événement Reassign (Réattribuer) étant appliqué avant celui de l’événement Realign (Réaligner), il est important de vérifier la configuration du comportement d’événement Reassign (Réattribuer) de la couche d’entités d’événement avant de cocher la case Reassign to abandoned route (Réattribuer à l’itinéraire abandonné).
Le comportement d’événement Calibrer étant appliqué avant celui de l’événement de réalignement, il est important de vérifier la configuration du comportement d’événement de calibrage de la couche d’entités d’événement avant de cocher la case Recalibrate route downstream (Recalibrer l’itinéraire en aval). Comme la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) n’est pas cochée pour les scénarios ci-dessous, le comportement d’événement Calibrer n’est pas appliqué.
Pour des exemples d’autres comportements d’événement pour la réattribution et le calibrage, consultez les rubriques Comportement d’événement en cas de réattribution de l’itinéraire et Comportement d’événement en cas de calibrage de l’itinéraire.
Avant le réalignement de l’itinéraire
L’image suivante présente les itinéraires avant le réalignement :
Le tableau suivant contient des détails sur les itinéraires avant le réalignement :
| Nom de l’itinéraire | Nom de la ligne | Ordre de ligne | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|---|---|
| Route1 | LineA | 100 | 01/01/2000 | <Nul> | 0 | 10 |
| Route2 | LineA | 200 | 01/01/2000 | <Nul> | 12 | 22 |
| Route3 | LineA | 300 | 01/01/2000 | <Nul> | 25 | 35 |
| Route4 | LineA | 400 | 01/01/2000 | <Nul> | 38 | 48 |
Après le réalignement de l’itinéraire
La case Reassign to abandoned route (Réattribuer à l’itinéraire abandonné) étant cochée, les itinéraires et les parties d’itinéraires se trouvant dans la zone de réalignement sont devenus les nouveaux itinéraires abandonnés sur une ligne nommée LineB. Route2_Ab a une mesure de départ de 17 et une mesure d’arrivée de 22. Route3_Ab a une mesure de départ de 25 et une mesure d’arrivée de 35. Route4_Ab a une mesure de départ de 38 et une mesure d’arrivée de 43. Ces mesures proviennent des mesures d’origine sur les itinéraires réalignés.
L’image suivante présente les itinéraires après le réalignement :
Le tableau suivant contient des détails sur les itinéraires après le réalignement :
| Nom de l’itinéraire | Nom de la ligne | Ordre de ligne | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|---|---|
| Route1 | LineA | 100 | 01/01/2000 | <Nul> | 0 | 10 |
| Route2 | LineA | 200 | 01/01/2000 | 01/01/2005 | 12 | 22 |
| Route2 | LineA | 200 | 01/01/2005 | <Nul> | 12 | 17 |
| Route3 | LineA | 300 | 01/01/2000 | 01/01/2005 | 25 | 35 |
| Route3A | LineA | 300 | 01/01/2005 | <Nul> | 20 | 45 |
| Route4 | LineA | 400 | 01/01/2000 | 01/01/2005 | 38 | 48 |
| Route4 | LineA | 400 | 01/01/2005 | <Nul> | 43 | 48 |
| Route2_Ab | LineB | 100 | 01/01/2005 | <Nul> | 17 | 22 |
| Route3_Ab | LineB | 200 | 01/01/2005 | <Nul> | 25 | 35 |
| Route4_Ab | LineB | 300 | 01/01/2005 | <Nul> | 38 | 43 |
Événements avant le réalignement de l’itinéraire
Deux événements se trouvent sur LineA et tous deux ont pour date de début le 01/01/2000. L’image suivante présente les itinéraires et événements avant le réalignement :
Le tableau suivant contient des détails sur les événements avant le réalignement :
| ID de l’événement | Date de début | Date de fin | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|---|---|
| Event1 | 01/01/2000 | <Nul> | Route1 | Route3 | 0 | 30 |
| Event2 | 01/01/2000 | <Nul> | Route3 | Route4 | 30 | 48 |
Les sections suivantes décrivent la façon dont les règles de comportement d’événement sont appliquées après l’exécution de l’outil Appliquer les comportements d’événement dans ce scénario de réaffectation d’itinéraire.
Comportement d’événement Immobile
Même si la localisation géographique de l’événement est conservée, les mesures peuvent changer. L’événement peut également être divisé s’il traverse la région réalignée. Si le comportement d’événement de réattribution défini est Capturer, les événements et parties d’événements se trouvant dans la zone de réalignement effectuent une capture sur l’itinéraire abandonné pour conserver leurs localisations géographiques.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Immobile |
| Réattribuer | Capturer |
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il se divise ensuite en deux enregistrements d’événement sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date de début. Le comportement d’événement Réattribuer étant appliqué avant le comportement d’événement Réaligner, la partie d’Event1 se trouvant dans la section de réalignement se sépare de l’Event1 d’origine et effectue la capture sur les itinéraires abandonnés. L’autre partie d’Event1 qui reste sur LineA est raccourcie à la longueur de la partie gauche de LineA avant d’appliquer le comportement d’événement Immobile pour le réalignement. Lorsque le comportement d’événement Immobile est appliqué pour le réalignement, il n’est pas nécessaire de modifier les mesures de cet événement pour conserver sa localisation géographique. En conséquence, Event1 se divise en deux événements. Un événement reste sur LineA avec une mesure de départ de 0 sur Route1 et une mesure d’arrivée de 17 sur Route2. L’autre événement effectue la capture sur les itinéraires abandonnés avec une mesure de départ de 17 sur Route2_Ab et une mesure d’arrivée de 30 sur Route3_Ab.
- Event2 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il se divise ensuite en deux enregistrements d’événement sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date de début. Le comportement d’événement Réattribuer étant appliqué avant le comportement d’événement Réaligner, la partie d’Event2 se trouvant dans la section de réalignement se sépare de l’Event2 d’origine et effectue la capture sur les itinéraires abandonnés. L’autre partie d’Event2 qui reste sur LineA est raccourcie à la longueur de la partie droite de LineA avant d’appliquer le comportement d’événement Immobile pour le réalignement. Lorsque le comportement d’événement Immobile est appliqué pour le réalignement, il n’est pas nécessaire de modifier les mesures de cet événement pour conserver sa localisation géographique. En conséquence, Event2 se divise en deux événements. Un événement reste sur LineA avec une mesure de départ de 43 sur Route4 et une mesure d’arrivée de 48 sur Route4. L’autre événement effectue la capture sur les itinéraires abandonnés avec une mesure de départ de 30 sur Route3_Ab et une mesure d’arrivée de 43 sur Route4_Ab.
L’image suivante présente les itinéraires et événements après le réalignement :
Remarque :
L’événement retiré n’est pas représenté dans l’image ci-dessus.
Le tableau suivant contient des détails sur les événements après le réalignement :
| ID de l’événement | Date de début | Date de fin | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|---|
| Event1 | 01/01/2000 | 01/01/2005 | Route1 | Route3 | 0 | 30 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route1 | Route2 | 0 | 17 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route2_Ab | Route3_Ab | 17 | 30 | Aucune erreur |
| Event2 | 01/01/2000 | 01/01/2005 | Route3 | Route4 | 30 | 48 | Aucune erreur |
| Event2 | 01/01/2005 | <Nul> | Route3_Ab | Route4_Ab | 30 | 43 | Aucune erreur |
| Event2 | 01/01/2005 | <Nul> | Route4 | Route4 | 43 | 48 | Aucune erreur |
Comportement d’événement Déplacer
Même si les mesures de l’événement sont conservées, la localisation géographique peut changer. Si le comportement d’événement de réattribution défini est Capturer, les événements et parties d’événements se trouvant dans la zone de réalignement effectuent une capture sur l’itinéraire abandonné pour conserver leurs localisations géographiques, entraînant la division des événements d’origine.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Déplacer |
| Réattribuer | Capturer |
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il se divise ensuite en deux enregistrements d’événement sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date de début. Le comportement d’événement Réattribuer étant appliqué avant le comportement d’événement Réaligner, la partie d’Event1 se trouvant dans la section de réalignement se sépare de l’Event1 d’origine et effectue la capture sur les itinéraires abandonnés. L’autre partie d’Event1 qui reste sur LineA est raccourcie à la longueur de la partie gauche de LineA avant d’appliquer le comportement d’événement Déplacer pour le réalignement. Lorsque le comportent d’événement Déplacer est appliqué pour le réalignement, cet événement n’a pas besoin d’être déplacé, car il ne se trouve pas dans la section de mise à jour. En conséquence, Event1 se divise en deux événements. Un événement reste sur LineA avec une mesure de départ de 0 sur Route1 et une mesure d’arrivée de 17 sur Route2. L’autre événement effectue la capture sur les itinéraires abandonnés avec une mesure de départ de 17 sur Route2_Ab et une mesure d’arrivée de 30 sur Route3_Ab.
- Event2 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il se divise ensuite en deux enregistrements d’événement sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date de début. Le comportement d’événement Réattribuer étant appliqué avant le comportement d’événement Réaligner, la partie d’Event2 se trouvant dans la section de réalignement se sépare de l’Event2 d’origine et effectue la capture sur les itinéraires abandonnés. L’autre partie d’Event2 qui reste sur LineA est raccourcie à la longueur de la partie droite de LineA avant d’appliquer le comportement d’événement Déplacer pour le réalignement. Lorsque le comportent d’événement Déplacer est appliqué pour le réalignement, cet événement n’a pas besoin d’être déplacé, car il ne se trouve pas dans la section de mise à jour. En conséquence, Event2 se divise en deux événements. Un événement reste sur LineA avec une mesure de départ de 43 sur Route4 et une mesure d’arrivée de 48 sur Route4. L’autre événement effectue la capture sur les itinéraires abandonnés avec une mesure de départ de 30 sur Route3_Ab et une mesure d’arrivée de 43 sur Route4_Ab.
L’image suivante présente les itinéraires et événements après le réalignement :
Le tableau suivant contient des détails sur les événements après le réalignement :
| ID de l’événement | Date de début | Date de fin | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|---|
| Event1 | 01/01/2000 | 01/01/2005 | Route1 | Route3 | 0 | 30 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route1 | Route2 | 0 | 17 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route2_Ab | Route3_Ab | 17 | 30 | Aucune erreur |
| Event2 | 01/01/2000 | 01/01/2005 | Route3 | Route4 | 30 | 48 | Aucune erreur |
| Event2 | 01/01/2005 | <Nul> | Route3_Ab | Route4_Ab | 30 | 43 | Aucune erreur |
| Event2 | 01/01/2005 | <Nul> | Route2 | Route2 | 45 | 50 | Aucune erreur |
Comportement d’événement Retirer
Les événements intersectant la région de réalignement sont retirés. Si le comportement d’événement de réattribution défini est Capturer, les événements et parties d’événements se trouvant dans la zone de réalignement effectuent une capture sur l’itinéraire abandonné pour conserver leurs localisations géographiques, entraînant la division des événements d’origine.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Retirer |
| Réattribuer | Capturer |
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il se divise ensuite en deux enregistrements d’événement sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date de début. Le comportement d’événement Réattribuer étant appliqué avant le comportement d’événement Réaligner, la partie d’Event1 se trouvant dans la section de réalignement se sépare de l’Event1 d’origine et effectue la capture sur les itinéraires abandonnés. L’autre partie d’Event1 qui reste sur LineA est raccourcie à la longueur de la partie gauche de LineA avant d’appliquer le comportement d’événement Retirer pour le réalignement. Lorsque le comportent d’événement Retirer est appliqué pour le réalignement, cet événement n’a pas besoin d’être retiré, car il ne se trouve pas dans la section de mise à jour. En conséquence, Event1 se divise en deux événements. Un événement reste sur LineA avec une mesure de départ de 0 sur Route1 et une mesure d’arrivée de 17 sur Route2. L’autre événement effectue la capture sur les itinéraires abandonnés avec une mesure de départ de 17 sur Route2_Ab et une mesure d’arrivée de 30 sur Route3_Ab.
- Event2 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il se divise ensuite en deux enregistrements d’événement sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date de début. Le comportement d’événement Réattribuer étant appliqué avant le comportement d’événement Réaligner, la partie d’Event2 se trouvant dans la section de réalignement se sépare de l’Event2 d’origine et effectue la capture sur les itinéraires abandonnés. L’autre partie d’Event2 qui reste sur LineA est raccourcie à la longueur de la partie droite de LineA avant d’appliquer le comportement d’événement Retirer pour le réalignement. Lorsque le comportent d’événement Retirer est appliqué pour le réalignement, cet événement n’a pas besoin d’être retiré, car il ne se trouve pas dans la section de mise à jour. En conséquence, Event2 se divise en deux événements. Un événement reste sur LineA avec une mesure de départ de 43 sur Route4 et une mesure d’arrivée de 48 sur Route4. L’autre événement effectue la capture sur les itinéraires abandonnés avec une mesure de départ de 30 sur Route3_Ab et une mesure d’arrivée de 43 sur Route4_Ab.
L’image suivante présente les itinéraires et événements après le réalignement :
Le tableau suivant contient des détails sur les événements après le réalignement :
| ID de l’événement | Date de début | Date de fin | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|---|
| Event1 | 01/01/2000 | 01/01/2005 | Route1 | Route3 | 0 | 30 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route1 | Route2 | 0 | 17 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route2_Ab | Route3_Ab | 17 | 30 | Aucune erreur |
| Event2 | 01/01/2000 | 01/01/2005 | Route3 | Route4 | 30 | 48 | Aucune erreur |
| Event2 | 01/01/2005 | <Nul> | Route3_Ab | Route4_Ab | 30 | 43 | Aucune erreur |
| Event2 | 01/01/2005 | <Nul> | Route2 | Route2 | 45 | 50 | Aucune erreur |
Comportement d’événement Couvrir
Si l’événement se trouve dans la zone de réalignement, sa forme change pour couvrir la partie réalignée de l’itinéraire. Les mesures de l’événement sont également mises à jour en fonction de la nouvelle forme.
Pour les événements dont le comportement de réalignement est Couvrir, la réattribution du comportement d’événement n’entraîne pas la division des événements. Les événements et parties d’événements se trouvant dans la zone de réalignement sont capturés sur l’itinéraire abandonné, tandis que les événements d’origine demeurent intacts et couvrent proportionnellement l’itinéraire postérieur au réalignement.
Remarque :
Utilisez le comportement d’événement Couvrir pour le réalignement si les événements doivent rester sur les parties d’itinéraire réalignées. Le comportement d’événement Couvrir est le seul à empêcher les événements de se diviser en réattribuant les comportements d’événement.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Couverture |
| Réattribuer | Capturer |
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il forme ensuite deux enregistrements d’événement sur les itinéraires postérieurs au réalignement, la date de réalignement correspondant à la date de début. Le comportement d’événement Réattribuer étant appliqué avant le comportement d’événement Réaligner, la partie d’Event1 se trouvant dans la section de réalignement effectue la capture sur les itinéraires abandonnés. L’autre partie d’Event1 qui reste sur LineA est rallongée proportionnellement pour couvrir la première moitié de Route3A en raison du réalignement. En conséquence, Event1 devient deux événements. Un événement reste sur LineA avec une mesure de départ de 0 sur Route1 et une mesure d’arrivée de 32,5 sur Route3A. L’autre événement effectue la capture sur les itinéraires abandonnés avec une mesure de départ de 17 sur Route2_Ab et une mesure d’arrivée de 30 sur Route3_Ab.
- Event2 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il forme ensuite deux enregistrements d’événement sur les itinéraires postérieurs au réalignement, la date de réalignement correspondant à la date de début. Le comportement d’événement Réattribuer étant appliqué avant le comportement d’événement Réaligner, la partie d’Event2 se trouvant dans la section de réalignement effectue la capture sur les itinéraires abandonnés. L’autre partie d’Event2 qui reste sur LineA est rallongée proportionnellement pour couvrir la seconde moitié de Route3A en raison du réalignement. En conséquence, Event2 devient deux événements. Un événement reste sur LineA avec une mesure de départ de 32,5 sur Route3A et une mesure d’arrivée de 48 sur Route4. L’autre événement effectue la capture sur les itinéraires abandonnés avec une mesure de départ de 30 sur Route3_Ab et une mesure d’arrivée de 43 sur Route4_Ab.
L’image suivante présente les itinéraires et événements après le réalignement :
Le tableau suivant contient des détails sur les événements après le réalignement :
| ID de l’événement | Date de début | Date de fin | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|---|
| Event1 | 01/01/2000 | 01/01/2005 | Route1 | Route3 |
0 | 30 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route1 | Route3A |
0 | 32,5 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route2_Ab | Route3_Ab |
17 | 30 | Aucune erreur |
| Event2 | 01/01/2000 | 01/01/2005 | Route3 | Route4 |
30 | 48 | Aucune erreur |
| Event2 | 01/01/2005 | <Nul> | Route3A | Route4 |
32,5 | 48 | Aucune erreur |
| Event2 | 01/01/2005 | <Nul> | Route3_Ab | Route4_Ab |
30 | 43 | Aucune erreur |
Comportement d’événement Capturer
Même si la localisation géographique de l’événement est conservée en faisant une capture sur la localisation du nouvel itinéraire de réalignement, les mesures peuvent changer. L’événement peut également être divisé s’il traverse la zone de réalignement où des itinéraires coïncidents existent.
Si le comportement d’événement de réattribution défini est Capturer, les événements et parties d’événements se trouvant dans la zone de réalignement effectuent une capture sur l’itinéraire abandonné pour conserver leurs localisations géographiques, entraînant la division des événements d’origine.
Dans cet exemple, Route5 coïncide avec les itinéraires sur LineA. Route5 est sur LineC, dans la direction inverse. Sa mesure de départ a pour valeur 0 et sa mesure d’arrivée 40.
Remarque :
Lorsqu’à la fois des itinéraires abandonnés et des itinéraires coïncidents sont présents dans le réalignement, les événements avec un comportement Capturer pour le réalignement et la réattribution effectuent une capture sur les itinéraires abandonnés, quelle que soit la configuration des règles dominantes.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Capturer |
| Réattribuer | Capturer |
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il se divise ensuite en deux enregistrements d’événement sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date de début. Le comportement d’événement Réattribuer étant appliqué avant le comportement d’événement Réaligner, la partie d’Event1 se trouvant dans la section de réalignement se sépare de l’Event1 d’origine et effectue la capture sur les itinéraires abandonnés. L’autre partie d’Event1 qui reste sur LineA est raccourcie à la longueur de la branche gauche de LineA avant d’appliquer le comportement d’événement Capturer pour le réalignement. Lorsque le comportement d’événement Capturer est appliqué pour le réalignement, il n’est pas nécessaire de modifier les mesures de cet événement pour conserver sa localisation géographique, car il ne se trouve pas dans la section de mise à jour. En conséquence, Event1 se divise en deux événements. Un événement reste sur LineA avec une mesure de départ de 0 sur Route1 et une mesure d’arrivée de 17 sur Route2. L’autre événement effectue la capture sur les itinéraires abandonnés avec une mesure de départ de 17 sur Route2_Ab et une mesure d’arrivée de 30 sur Route3_Ab.
- Event2 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il se divise ensuite en deux enregistrements d’événement sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date de début. Le comportement d’événement Réattribuer étant appliqué avant le comportement d’événement Réaligner, la partie d’Event2 se trouvant dans la section de réalignement se sépare de l’Event2 d’origine et effectue la capture sur les itinéraires abandonnés. L’autre partie d’Event2 qui reste sur LineA est raccourcie à la longueur de la branche droite de LineA avant d’appliquer le comportement d’événement Capturer pour le réalignement. Lorsque le comportement d’événement Capturer est appliqué pour le réalignement, il n’est pas nécessaire de modifier les mesures de cet événement pour conserver sa localisation géographique, car il ne se trouve pas dans la section de mise à jour. En conséquence, Event2 se divise en deux événements. Un événement reste sur LineA avec une mesure de départ de 43 sur Route4 et une mesure d’arrivée de 48 sur Route4. L’autre événement effectue la capture sur les itinéraires abandonnés avec une mesure de départ de 30 sur Route3_Ab et une mesure d’arrivée de 43 sur Route4_Ab.
L’image suivante présente les itinéraires et événements après le réalignement :
Le tableau suivant contient des détails sur les événements après le réalignement :
| ID de l’événement | Date de début | Date de fin | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|---|
| Event1 | 01/01/2000 | 01/01/2005 | Route1 | Route3 |
0 |
30 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route1 | Route2 |
0 |
17 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route2_Ab | Route3_Ab |
17 |
30 | Aucune erreur |
| Event2 | 01/01/2000 | 01/01/2005 | Route3 | Route4 |
30 |
48 | Aucune erreur |
| Event2 | 01/01/2005 | <Nul> | Route3_Ab | Route4_Ab |
30 |
43 | Aucune erreur |
| Event2 | 01/01/2005 | <Nul> | Route4 | Route4 |
43 |
48 | Aucune erreur |
Comportements d’événement de réalignement détaillés avec itinéraires coïncidents
Les sections suivantes décrivent la façon dont les règles de comportement d’événement Couvrir et Capturer pour le réalignement sont appliquées lorsque des itinéraires comportant une section coïncidente avec des itinéraires dominants sont réalignés.
Scénario avec réseau non linéaire
Dans cet exemple, trois itinéraires sont actifs à partir du 01/01/2000 : Route1, Route2 et Route3. Route3 coïncide avec la partie centrale de Route2 et se trouve dans la direction inverse. Route3 est un itinéraire subordonné. Le réalignement est défini pour se produire le 01/01/2005, lors du réalignement de Route2 dans une section qui recouvre l’itinéraire coïncident dominant, Route1. La partie réalignée de Route2 se voit attribuer de nouvelles mesures de 7 à 23. La case Recalibrate route downstream (Recalibrer l’itinéraire en aval) n’est pas cochée.
Les graphiques et les tableaux ci-dessous présentent les informations sur l’itinéraire avant et après le réalignement.
Avant le réalignement de l’itinéraire
L’image suivante présente les itinéraires avant le réalignement :
Le tableau suivant contient des détails sur les itinéraires avant le réalignement :
| Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|
| Route1 | 01/01/2000 | <Nul> | 0 | 10 |
| Route2 | 01/01/2000 | <Nul> | 0 | 30 |
| Route3 | 01/01/2000 | <Nul> | 10 | 20 |
Après le réalignement de l’itinéraire
L’image suivante présente les itinéraires après le réalignement :
Le tableau suivant contient des détails sur les itinéraires après le réalignement :
| Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|
| Route1 | 01/01/2000 | <Nul> | 0 | 10 |
| Route2 | 01/01/2000 | 01/01/2005 | 0 | 30 |
| Route2 | 01/01/2005 | <Nul> | 0 | 30 |
| Route3 | 01/01/2000 | <Nul> | 10 | 20 |
Événements avant le réalignement de l’itinéraire
Event1 se trouve sur Route2 et sa date de début est le 01/01/2000. L’image suivante présente les itinéraires et l’événement avant le réalignement :
Le tableau suivant contient des détails sur l’événement avant le réalignement :
| Événement | Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|---|
| Event1 | Route2 | 01/01/2000 | <Nul> | 0 | 30 |
Comportement d’événement Couvrir
Si l’événement se trouve dans la zone de réalignement, sa forme change pour couvrir la partie réalignée de l’itinéraire. Les mesures de l’événement sont également mises à jour en fonction de la nouvelle forme.
Si l’événement est créé sur l’itinéraire dominant et que des coïncidences d’itinéraires sont formées par le réalignement, l’événement continue de couvrir la totalité de l’itinéraire dominant. Si l’événement est créé sur l’itinéraire subordonné et que des coïncidences d’itinéraires sont formées par le réalignement, l’événement ne couvre pas le segment d’itinéraire subordonné où se trouve l’itinéraire dominant.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Couverture |
| Calibrer | Immobile |
Remarque :
Bien que la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) ne soit pas cochée, l’itinéraire est recalibré depuis le début du réalignement sur le point de calibrage en aval le plus proche. Le comportement d’événement Calibrer est appliqué aux événements dans les sections impactées de l’itinéraire.
Le réalignement de l’itinéraire décrit ci-dessus a l’effet suivant :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il forme ensuite deux enregistrements d’événement sur les itinéraires postérieurs au réalignement, la date de réalignement correspondant à la date de début. Cela est dû au fait qu’Event1 est associé à l’itinéraire subordonné, Route2, et qu’après le réalignement, il ne couvre pas le segment de Route2 où se trouve l’itinéraire dominant, Route1. L’enregistrement de l’événement en amont a pour mesure de départ la valeur 0 et pour mesure d’arrivée la valeur 12 pour couvrir la partie de Route2 jusqu’à sa coïncidence avec Route1, tandis que l’enregistrement de l’événement en aval a pour mesure de départ la valeur 18 et pour mesure d’arrivée la valeur 30 pour couvrir Route2 après sa coïncidence avec Route1.
L’image suivante présente les itinéraires et l’événement après le réalignement :
Remarque :
L’événement retiré n’est pas représenté dans l’image ci-dessus.
Le tableau suivant contient des détails sur l’événement après le réalignement :
| Événement | Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|
| Event1 | Route2 | 01/01/2000 | 01/01/2005 | 0 | 30 | Aucune erreur |
| Event1 | Route2 | 01/01/2005 | <Nul> | 0 | 12 | Aucune erreur |
| Event1 | Route2 | 01/01/2005 | <Nul> | 18 | 30 | Aucune erreur |
Comportement d’événement Capturer
Même si la localisation géographique de l’événement est conservée en faisant une capture sur la localisation du nouvel itinéraire de réalignement, les mesures peuvent changer. L’événement peut également être divisé s’il traverse la zone de réalignement où des itinéraires coïncidents existent.
Le tableau suivant présente les opérations de mise à jour impliquées dans la mise à jour de l’itinéraire ainsi que leurs comportements d’événement associés :
| Opération de mise à jour | Comportement d’événement |
|---|---|
| Réaligner | Capturer |
| Calibrer | Immobile |
Le réalignement de l’itinéraire décrit ci-dessus a les effets suivants :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Il forme ensuite trois enregistrements d’événement sur les itinéraires postérieurs au réalignement, la date de réalignement correspondant à la date de début. Cela est dû au fait qu’il existe un itinéraire coïncident dans la section de réalignement, et que la partie d’Event1 se trouvant dans la section de réalignement effectue la capture sur Route3 (l’itinéraire coïncident) après le réalignement. Il est également inversé pour tenir compte de la direction de Route3. Par conséquent, Event1 est divisé en trois parties pour conserver sa localisation géographique.
- L’enregistrement du premier événement a pour mesure de départ la valeur 0 et pour mesure d’arrivée la valeur 7 sur Route2 ; l’enregistrement du second événement capture sur Route3 et a pour mesure de départ la valeur 10 et pour mesure d’arrivée la valeur 20 sur Route3 ; et l’enregistrement de l’événement en aval a pour mesure de départ la valeur 23 et pour mesure d’arrivée la valeur 30 sur Route2.
L’image suivante présente les itinéraires et l’événement après le réalignement :
Le tableau suivant contient des détails sur l’événement après le réalignement :
| Événement | Nom de l’itinéraire | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|
| Event1 | Route2 | 01/01/2000 | 01/01/2005 | 0 | 30 | Aucune erreur |
| Event1 | Route2 | 01/01/2005 | <Nul> | 0 | 7 | Aucune erreur |
| Event1 | Route2 | 01/01/2005 | <Nul> | 23 | 30 | Aucune erreur |
| Event1 | Route3 | 01/01/2005 | <Nul> | 10 | 20 | Aucune erreur |
Scénario du réseau linéaire
Dans cet exemple, deux itinéraires sur LineA sont actifs à partir du 01/01/2000 : Route1 et Route2, et Route3 sur LineB est dans la direction inverse. Le réalignement est défini pour se produire le 01/01/2005, lors du réalignement de la moitié de Route1 et de la moitié de Route2.
La partie réalignée se voit attribuer de nouvelles mesures de 0 à 20, de sorte qu’un nouvel itinéraire est créé : RouteNew. RouteNew prévaut sur Route3. La case Recalibrate route downstream (Recalibrer l’itinéraire en aval) n’est pas cochée, mais l’option Reassign to abandoned route (Réattribuer à l’itinéraire abandonné) l’est dans cette mise à jour. Les images et tables ci-dessous présentent les informations sur l’itinéraire avant et après le réalignement.
Remarque :
Vous pouvez inverser la direction des axes médians dans une opération de mise à jour d’itinéraire en utilisant Flip the direction of the centerlines (Inverser la direction des axes médians) 
.
Les images et tables ci-dessous présentent les informations sur l’itinéraire avant et après le réalignement.
Avant le réalignement de l’itinéraire
L’image suivante présente les itinéraires avant le réalignement :
Le tableau suivant contient des détails sur les itinéraires avant le réalignement :
| Nom de l’itinéraire | Nom de la ligne | Ordre de ligne | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|---|---|
| Route1 | LineA | 100 | 01/01/2000 | <Nul> | 0 | 14 |
| Route2 | LineA | 200 | 01/01/2000 | <Nul> | 17 | 28 |
| Route3 | LineB | 100 | 01/01/2000 | <Nul> | 0 | 10 |
Après le réalignement de l’itinéraire
La case Reassign to abandoned route (Réattribuer à l’itinéraire abandonné) étant cochée, les itinéraires et les parties d’itinéraires se trouvant dans la zone de réalignement sont devenus les nouveaux itinéraires abandonnés sur une ligne nommée LineC. Route1_Ab a une mesure de départ de 10 et une mesure d’arrivée de 14. Route2_Ab a une mesure de départ de 17 et une mesure d’arrivée de 20. Ces mesures proviennent des mesures d’origine sur les itinéraires réalignés.
L’image suivante présente les itinéraires après le réalignement :
Le tableau suivant contient des détails sur les itinéraires après le réalignement :
| Nom de l’itinéraire | Nom de la ligne | Ordre de ligne | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée |
|---|---|---|---|---|---|---|
| Route1 | LineA | 100 | 01/01/2000 | 01/01/2005 | 0 | 14 |
| Route1 | LineA | 100 | 01/01/2005 | <Nul> | 0 | 10 |
| RouteNew | LineA | 200 | 01/01/2005 | <Nul> | 0 | 20 |
| Route2 | LineA | 200 | 01/01/2000 | 01/01/2005 | 17 | 28 |
| Route2 | LineA | 300 | 01/01/2005 | <Nul> | 20 | 28 |
| Route3 | LineB | 100 | 01/01/2000 | <Nul> | 0 | 10 |
| Route1_Ab | LineC | 100 | 01/01/2005 | <Nul> | 10 | 14 |
| Route2_Ab | LineC | 200 | 01/01/2005 | <Nul> | 17 | 20 |
Événements avant le réalignement de l’itinéraire
Event1 se trouve sur LineA et sa date de début est le 01/01/2000. L’image suivante présente les itinéraires et l’événement avant le réalignement :
Le tableau suivant contient des détails sur l’événement avant le réalignement :
| ID de l’événement | Date de début | Date de fin | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|---|
| Event1 | 01/01/2000 | <Nul> | Route1 | Route2 |
0 | 28 | Aucune erreur |
Comportement d’événement Couvrir
Si l’événement se trouve dans la zone de réalignement, sa forme change proportionnellement pour couvrir la partie réalignée de l’itinéraire. Les mesures de l’événement sont également mises à jour en fonction de la nouvelle forme.
Si l’événement est créé sur l’itinéraire dominant et que des coïncidences d’itinéraires sont formées par le réalignement, l’événement continue de couvrir la totalité de l’itinéraire dominant. Si l’événement est créé sur l’itinéraire subordonné et que des coïncidences d’itinéraires sont formées par le réalignement, l’événement ne couvre pas le segment d’itinéraire subordonné où se trouve l’itinéraire dominant.
L’opération de mise à jour du réalignement de l’itinéraire avec le comportement d’événement Couvrir a l’effet suivant :
- Event1 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Un nouvel événement est créé sur l’itinéraire postérieur au réalignement, avec une date de réalignement correspondant à la date de début. Comme le nouvel itinéraire, RouteNew, est dominant par rapport à Route3, Event1 continue de couvrir les itinéraires sur LineA. La valeur de sa mesure de départ est toujours 0 sur Route1 et celle de sa mesure d’arrivée est toujours 28 sur Route2, bien que sa forme ait été mise à jour.
L’image suivante présente les itinéraires et l’événement après le réalignement :
Le tableau suivant contient des détails sur l’événement après le réalignement :
| ID de l’événement | Date de début | Date de fin | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|---|
| Event1 | 01/01/2000 | 01/01/2005 | Route1 | Route2 |
0 | 28 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route1 | Route2 |
0 | 28 | Aucune erreur |
Vous avez un commentaire à formuler concernant cette rubrique ?