Comportement d’événement en cas de réalignement de l’itinéraire

Disponible avec la licence Location Referencing.

pour chaque couche d’événements.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 :

Lorsque 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 étendu 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.

Étant donné que le LRS possède une dimension temporelle, les itinéraires et les événements sont découpés en intervalles temporels par les opérations de mise à jour, telles que la réaffectation d’un itinéraire.

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, dans le cadre duquel le milieu de Route1 est orienté vers un nouvel emplacement, la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) étant cochée. Les images et 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 l’itinéraire avant le réalignement :

Le tableau suivant donne des détails sur l’itinéraire avant le réalignement :

ID d’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

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 :

ID d’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	24

É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	ID d’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 :

Pour toute mise à jour d’itinéraire pour laquelle la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) est cochée, une partie de l’itinéraire en aval de la section mise à jour est recalibrée. Le comportement d’événement Calibrate (Calibrer) est appliqué dans ces sections recalibrées.

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 24 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	ID d’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	24	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 :

L’image suivante présente l’itinéraire et les événements après le réalignement :

Événement	ID d’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	ID d’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 à 24.

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	ID d’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	24	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.

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’L’enregistrement du premier événement a des valeurs de mesure de départ et d’arrivée de 18 à 24 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 6 à 8 sur Route2.

L’image suivante présente l’itinéraire et les événements après le réalignement :

L’image suivante présente l’itinéraire et les événements après le réalignement :

Événement	ID d’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	24	Aucune erreur
Event3	Route2	01/01/2005	<Nul>	6	8	Aucune erreur

Réaligner un réseau linéaire

Si le réseau sélectionné est un réseau linéaire, vous pouvez fournir de nouvelles mesures au segment d’itinéraire dans la zone de réalignement. Les nouvelles mesures 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é.

Dans l’exemple ci-dessous, Route1 appartient à Line1 et est actif depuis le 01/01/2000. Le réalignement est défini pour se produire le 01/01/2005, dans le cadre duquel le milieu de Route1 est orienté vers un nouvel emplacement. Les sous-sections ci-dessous présentent les différents scénarios des mesures de réalignement et de recalibrage. Les images et tableaux ci-dessous présentent les informations sur l’itinéraire et l’événement avant le réalignement.

Avant le réalignement de l’itinéraire

L’image suivante présente l’itinéraire avant le réalignement :

Le tableau ci-dessous donne des détails sur l’itinéraire 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	Line1	100	01/01/2000	<Nul>	0	20

Événements avant le réalignement

Route1 comporte trois événements qui ont tous une date initiale (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 ci-dessous décrivent le rôle joué par les mesures et le recalibrage en aval dans le réalignement lorsque le comportement d’événement Stay Put (Immobile) est configuré.

Remarque :

Dans tous les exemples ci-après, les comportements d’événement de réalignement et de recalibrage sont définis sur Stay Put (Immobile).

Le comportement d’événement de calibrage é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).

Pour examiner les autres comportements d’événement dans le cadre d’un calibrage, consultez la rubrique Comportement d’événement en cas de calibrage de l’itinéraire.

Lorsque des événements sont configurés avec le comportement Stay Put (Immobile) de réalignement, la localisation géographique de l’événement est préservée, mais 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.

Réalignement sans création d’itinéraires et avec recalibrage en aval

Dans ce scénario, la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) est cochée. Le réalignement commence par la mesure 6 et se termine par la mesure 18 sur Route1, une longueur de 4 étant ajoutée compte tenu du changement de forme. La partie réalignée de Route1 n’utilisant pas de nouvelles mesures, elle peut rester calibrée de façon monotone après le réalignement, et aucun itinéraire n’est créé.

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

L’image suivante présente l’itinéraire après le réalignement :

Le tableau ci-dessous contient des détails sur l’itinéraire 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	Line1	100	01/01/2000	01/01/2005	0	20
Route1	Line1	100	01/01/2005	<Nul>	0	24

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 événement est créé sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date initiale. La mesure initiale (From Measure (Mesure de départ)) prend la valeur 0 et la mesure finale (To Measure (Mesure d’arrivée)) la valeur 6 pour s’adapter aux nouvelles mesures de Route1.
• Event2 est retiré à la date de réalignement puisqu’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 événement est créé sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date initiale. La mesure initiale prend la valeur 18 et la mesure finale la valeur 24 pour s’adapter aux nouvelles mesures de Route1.

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 :

É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	24	Aucune erreur

Réalignement avec création d’itinéraires et recalibrage en aval

Dans ce scénario, la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) est cochée. Le réalignement commence par la mesure 6 et se termine par la mesure 18 sur Route1, une longueur de 4 étant ajoutée compte tenu du changement de forme. Toutefois, la partie réalignée de Route1 comporte de nouvelles mesures comprises entre 0 et 12. Dans ce cas, Route1 ne pouvant pas rester calibré de façon monotone après le réalignement, un itinéraire est créé. Le nouvel itinéraire est nommé RouteNew.

La case Recalibrate route downstream (Recalibrer l’itinéraire en aval) étant cochée, RouteNew est recalibré en aval et remplace la partie en aval d’origine de Route1. Les nouvelles mesures de RouteNew sont déterminées par la longueur du réalignement.

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

L’image suivante présente les itinéraires après le réalignement :

Les tableaux ci-dessous contiennent 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	Line1	100	01/01/2000	01/01/2005	0	20
Route1	Line1	100	01/01/2005	<Nul>	0	6
RouteNew	Line1	200	01/01/2005	<Nul>	0	18

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 événement est créé sur Route1 postérieur au réalignement, la date de réalignement correspondant à la date initiale. La mesure initiale prend la valeur 0 et la mesure finale la valeur 6 pour s’adapter aux nouvelles mesures de Route1.
• Event2 est retiré à la date de réalignement puisqu’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. RouteNew ayant remplacé Route1 à l’emplacement d’Event3, Event3 ne peut pas être créé lorsque le comportement Stay Put (Immobile) de calibrage est appliqué.

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 :

É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

Remarque :

Pour les événements de maintien sur les itinéraires en aval du réalignement, les itinéraires ne doivent pas être retirés.

Réalignement avec création d’itinéraires et sans recalibrage en aval

Dans ce scénario, la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) n’est pas cochée. Le réalignement commence par la mesure 6 et se termine par la mesure 12 sur Route1. Toutefois, le réalignement est réalisé dans le sens inverse des axes médians choisis. Dans ce cas, Route1 ne peut pas rester calibré de façon monotone après le réalignement, car la partie réalignée est inversée, un itinéraire étant donc créé. Le nouvel itinéraire est nommé RouteNew. RouteNew comporte une mesure de départ de 12, car le réalignement commence par la mesure 12 sur Route1, et une mesure de fin de 24, car la longueur du réalignement est 12.

La case Recalibrate route downstream (Recalibrer l’itinéraire en aval) n’étant pas cochée, la partie droite de Route1 est devenue un nouvel itinéraire (Route1b). Route1b comporte une mesure de départ de 12, car la partie aval commence par la mesure d’origine 12 sur Route1, et une mesure de fin de 18, car la longueur de la branche droite est de 6.

Le tableau suivant présente l’opération de mise à jour impliquée dans la mise à jour de l’itinéraire, ainsi que son comportement d’événement associé :

Opération de mise à jour	Comportement d’événement
Réaligner	Immobile

L’image suivante présente les itinéraires après le réalignement :

Le tableau ci-dessous 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	Line1	100	01/01/2000	01/01/2005	0	20
Route1	Line1	100	01/01/2005	<Nul>	0	6
RouteNew	Line1	200	01/01/2005	<Nul>	12	24
Route1	Line1	300	01/01/2005	<Nul>	12	18

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 événement est créé sur Route1 postérieur au réalignement, la date de réalignement correspondant à la date initiale. La mesure initiale prend la valeur 0 et la mesure finale la valeur 6 pour s’adapter aux nouvelles mesures de Route1.
• Event2 est retiré à la date de réalignement puisqu’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. Route1b ayant remplacé Route1 à l’emplacement d’Event3, Event3 ne peut pas être créé lorsque le comportement Stay Put (Immobile) de calibrage est appliqué.

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 :

É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

Réaligner dans un réseau linéaire avec événements étendus

Les sections suivantes décrivent la façon dont les règles de comportement d’événement sont appliquées et couvrent des itinéraires lorsqu’un itinéraire d’une ligne d’un réseau linéaire est réalignée.

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. Les sous-sections ci-dessous présentent des scénarios avec différentes options Recalibrate route downstream (Recalibrer l’itinéraire en aval) et Reassign to abandoned route (Réattribuer aux itinéraires abandonnés). Dans cette section, les graphiques et tableaux présentent les informations sur l’itinéraire et l’événement avant 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	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

É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 Apply Event Behaviors (Appliquer les comportements d’événement) dans des scénarios avec différentes options Recalibrate route downstream (Recalibrer l’itinéraire en aval) et Reassign to abandoned route (Réattribuer aux itinéraires abandonnés).

Scénario de réalignement avec abandon dans un réseau linéaire avec événements étendus et comportement d’événement Stay Put (Immobile).

Si le réseau sélectionné est un réseau linéaire, vous pouvez réattribuer la partie 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éaffectation. Pour transférer les événements vers l’itinéraire abandonné, configurez le comportement Snap (Capturer) pour le type de mise à jour de l’itinéraire réaffecté.

Dans cet exemple, les événements sont configurés avec le comportement d’événement Stay Put (Immobile) de réalignement, le comportement d’événement Snap (Capturer) de réaffectation et le comportement d’événement Stay Put (Immobile) de calibrage. Dans cette mise à jour, les options Recalibrate route downstream (Recalibrer l’itinéraire en aval) et Reassign to abandoned route (Réattribuer aux itinéraires abandonnés) sont cochées.

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 de calibrage é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).

Pour explorer d’autres comportements d’événement pour la réattribution et le calibrage, consultez les rubriques Comportement d’événement en cas de réaffectation de l’itinéraire et Comportement d’événement en cas de calibrage de l’itinéraire.

Après le réalignement de l’itinéraire

L’option Reassign to abandoned route (Réattribuer aux itinéraires abandonnés) étant cochée, les itinéraires et les parties d’itinéraires se trouvant dans la zone de réalignement sont devenus de nouveaux itinéraires abandonnés sur une ligne nommée LineB. Route2_Ab comporte une mesure de départ de 17 et une mesure de fin de 22. Route3_Ab comporte une mesure de départ de 25 et une mesure de fin de 35. Route4_Ab comporte une mesure de départ de 38 et une mesure de fin de 43. Ces mesures proviennent des mesures d’origine sur les itinéraires réalignés.

Route2 devient le seul itinéraire dans la zone de réalignement, car le réalignement commence sur Route2. La case Recalibrate route downstream (Recalibrer l’itinéraire en aval) étant cochée, Route2 est recalibré en aval et retire le Route4 d’origine. Les nouvelles mesures de Route2 sont déterminées par la longueur du réalignement.

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
Calibrer	Immobile

L’image suivante présente les itinéraires après le réalignement :

Le tableau ci-dessous 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	50
Route3	LineA	300	01/01/2000	01/01/2005	25	35
Route4	LineA	400	01/01/2000	01/01/2005	38	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

Comportement d’événement Stay Put (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 Snap (Capturer) est défini comme étant le comportement d’événement de réattribution, les événements et parties d’événements se trouvant dans la zone de réalignement capturent l’itinéraire abandonné pour préserver leurs emplacements géographiques.

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érieur au réalignement, la date de réalignement correspondant à la date initiale. Le comportement d’événement de réattribution étant appliqué avant le comportement d’événement de réalignement, la partie d’Event1 se trouvant dans la partie 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 l’application du comportement d’événement Stay Put (Immobile) de réalignement. Lorsque le comportement d’événement Stay Put (Immobile) de réalignement est appliqué, il n’est pas nécessaire de modifier les mesures de cet événement pour préserver sa localisation géographique. Dès lors, 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 de fin 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 de fin 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. Le comportement d’événement de réattribution étant appliqué en premier, la partie d’Event2 se trouvant dans la partie 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 se trouvait en aval du réalignement ne peut pas être créée lorsque le comportement Stay Put (Immobile) de calibrage est appliqué, car Route2 a remplacé Route4 à cet emplacement. Par conséquent, un seul nouvel enregistrement d’événement pour Event2 commence à la mesure 30 sur Route3_Ab et se termine à la mesure 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

Scénario de réalignement sans abandon dans un réseau linéaire avec événements étendus.

Les sections suivantes décrivent les comportements d’événement Cover (Couvrir) et Snap (Capturer) de réalignement pour l’opération de réalignement d’itinéraire ci-dessus. L’option Recalibrate route downstream (Recalibrer l’itinéraire en aval) est cochée et l’option Reassign to abandoned route (Réattribuer aux itinéraires abandonnés) ne l’est pas. Par conséquent, les itinéraires dans la zone de réalignement sont retirés sans être réattribués à une ligne d’abandon.

Les événements sont configurés avec le comportement d’événement Stay Put (Immobile) de calibrage.

Remarque :

Le comportement d’événement de calibrage é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).

Pour voir d’autres comportements d’événement dans le cadre d’un calibrage, consultez la rubrique Comportement d’événement en cas de calibrage de l’itinéraire.

Après le réalignement de l’itinéraire

Route2 devient le seul itinéraire dans la zone de réalignement, car le réalignement commence sur Route2. La case Recalibrate route downstream (Recalibrer l’itinéraire en aval) étant cochée, Route2 est recalibré en aval et retire le Route4 d’origine. Les nouvelles mesures de Route2 sont déterminées par la longueur du réalignement. Aucun itinéraire abandonné n’est créé étant donné que l’option Reassign to abandoned route (Réattribuer aux itinéraires abandonnés) n’est pas cochée.

L’image suivante présente les itinéraires après le réalignement :

Le tableau ci-dessous 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	50
Route3	LineA	300	01/01/2000	01/01/2005	25	35
Route4	LineA	400	01/01/2000	01/01/2005	38	48

Les sections suivantes décrivent la façon dont les règles de comportement d’événement Cover (Couvrir) et Snap (Capturer) de réalignement sont appliquées après l’exécution de l’outil Apply Event Behaviors (Appliquer les comportements d’événement) dans ce scénario de réalignement d’itinéraire.

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. Pour les événements se trouvant dans la partie en aval du réalignement, le comportement d’événement de calibrage est appliqué.

Remarque :

Utilisez le comportement d’événement de réalignement Cover (Couvrir) si les événements doivent rester sur les parties d’itinéraire réalignées. Cover (Couvrir) est le seul comportement d’événement qui empêche 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
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 événement est créé sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date initiale. 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. Le nouvel Event1 comporte une mesure de départ de 0 sur Route1 et une mesure de fin de 31 sur Route2.
• Event2 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Un événement est créé sur l’itinéraire postérieur au réalignement, la date de réalignement correspondant à la date initiale. Une partie de l’événement se trouvant dans la zone de réalignement, cette partie d’Event2 est rallongée proportionnellement pour couvrir la longueur augmentée de l’itinéraire en raison du réalignement. Le nouvel Event2 comporte une mesure de départ de 31 sur Route2 et une mesure de fin de 50 sur Route2.

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	31	Aucune erreur
Event2	01/01/2000	01/01/2005	Route3	Route4	30	48	Aucune erreur
Event2	01/01/2005	<Nul>	Route2	Route2	31	50	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.

Pour les événements se trouvant dans la partie en aval du réalignement, le comportement d’événement de calibrage est appliqué.

Dans cet exemple, Route5 coïncide avec les itinéraires sur LineA. Route5 est sur LineB, dans la direction inverse. Sa mesure de départ a pour valeur 0 et sa mesure d’arrivée 40.

Remarque :

Pour avoir davantage d’exemples d’itinéraires concurrents, consultez la section Comportements d’événement de réalignement détaillé avec les itinéraires concurrents.

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érieur au réalignement, la date de réalignement correspondant à la date initiale. En effet, il existe un itinéraire concurrent dans la section de réalignement, et la partie d’Event1 dans la section de réalignement effectue la capture sur Route5 (l’itinéraire concurrent) après le retrait. Il est également inversé pour tenir compte de la direction de Route5. Par conséquent, Event1 est divisé en deux parties pour préserver sa localisation géographique. L’enregistrement du premier événement a 0 pour valeur de mesure initiale sur Route1 et 17 pour valeur de mesure finale sur Route2. L’enregistrement du deuxième événement effectue la capture sur Route5 et a pour valeur de mesure initiale 15 sur Route5 et pour valeur de mesure finale 25 sur Route5.
• Event2 est retiré à la date du réalignement, car il se trouve en partie dans la section de mise à jour. Le comportement d’événement de réattribution étant appliqué en premier, la partie d’Event2 se trouvant dans la partie de réalignement se sépare de l’Event2 d’origine et effectue la capture sur l’itinéraire concurrent Route5. Il est également inversé pour tenir compte de la direction de Route5. L’autre partie d’Event2 qui se trouvait en aval du réalignement ne peut pas être créée lorsque le comportement Stay Put (Immobile) de calibrage est appliqué, car Route2 a remplacé Route4 à cet emplacement. Par conséquent, un seul nouvel enregistrement d’événement pour Event2 commence à la mesure 5 sur Route5 et se termine à la mesure 15 sur Route5.

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>	Route5	Route5	15	25	Aucune erreur
Event2	01/01/2000	01/01/2005	Route3	Route4	30	48	Aucune erreur
Event2	01/01/2005	<Nul>	Route5	Route5	5	15	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 case Recalibrate route downstream (Recalibrer l’itinéraire en aval) est 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 :

ID d’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 :

ID d’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	40
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	ID d’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 :

Pour toute mise à jour d’itinéraire pour laquelle la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) est cochée, une partie de l’itinéraire en aval de la section mise à jour est recalibrée. Le comportement d’événement Calibrate (Calibrer) est appliqué dans ces sections recalibrées.

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. ’enregistrement de l’événement en amont a pour mesure de départ la valeur 0 et pour mesure d’arrivée la valeur 15 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 25 et pour mesure d’arrivée la valeur 40 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	ID d’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	15	Aucune erreur
Event1	Route2	01/01/2005	<Nul>	25	40	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 10 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 30 et pour mesure d’arrivée la valeur 40 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	ID d’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	10	Aucune erreur
Event1	Route2	01/01/2005	<Nul>	30	40	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.

Route1 devient le seul itinéraire sur LineA dans la zone de réalignement, car le réalignement commence sur Route1. La case Recalibrate route downstream (Recalibrer l’itinéraire en aval) étant cochée, Route1 est recalibré en aval et retire le Route2 d’origine. Les nouvelles mesures de Route1 sont déterminées par la longueur du réalignement. Aucun itinéraire abandonné n’est créé étant donné que l’option Reassign to abandoned route (Réattribuer aux itinéraires abandonnés) n’est pas cochée.

Route1 est mieux classé que Route3 après le réalignement.

Remarque :

Vous pouvez inverser le sens des axes médians dans une opération de mise à jour d’itinéraire à l’aide du bouton 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

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	35
Route2	LineA	200	01/01/2000	01/01/2005	17	28
Route3	LineB	100	01/01/2000	<Nul>	0	10

É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.

Remarque :

Pour tout itinéraire pour lequel la case Recalibrate route downstream (Recalibrer l’itinéraire en aval) est cochée, une partie de l’itinéraire en aval de la section mise à jour est recalibrée. Le comportement d’événement Calibrate (Calibrer) est appliqué dans ces sections recalibré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	Couverture
Calibrer	Immobile

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 Route1 est dominant par rapport à Route3, Event1 continue de couvrir la totalité de Route1. La valeur de sa mesure de départ passe à 0 et celle de sa mesure d’arrivée passe à 35 sur Route1.

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	Route1	0	35	Aucune erreur