Disponible avec la licence Location Referencing.
Lors de la réaffectation d’un itinéraire, les événements sont impactés dans la section de mise à jour, ainsi qu’en amont et en aval de la réaffectation, selon le comportement d’événement configuré pour la couche d’événements concernée.
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 :
La méthode de réaffectation, la mise à jour de l’itinéraire et les comportements d’événement sont décrits ci-dessous.
Méthode Fusionner avec l’itinéraire adjacent
Dans cette méthode de réaffectation de l’itinéraire, une partie d’un itinéraire, l’intégralité de l’itinéraire ou plusieurs itinéraires peuvent être réaffectés et fusionnés avec l’itinéraire adjacent.
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éaffectation de l’itinéraire :
Le tableau suivant décrit la façon dont l’opération de mise à jour de la réaffectation impacte les événements en aval et en amont en fonction du comportement d’événement configuré :
| Comportement | Événements en amont de la réaffectation | Événements formant une intersection avec la réaffectation | Événements en aval de la réaffectation |
|---|---|---|---|
Immobile | Aucune action | Événement Retirer. Les événements linéaires traversant la région mise à jour sont 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 | La forme est remodelée, au besoin, selon la nouvelle localisation des mesures d’itinéraire. | La forme est remodelée selon la 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. Les événements linéaires traversant la région de réaffectation ne sont pas divisés. | 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 | La localisation géographique (x,y) reste identique. L’événement migre vers l’itinéraire réaffecté. Les événements linéaires traversant la région mise à jour sont divisés. | 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 dans 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 de la fusion avec l’itinéraire adjacent
Dans cet exemple, les itinéraires sont actifs à partir du 01/01/2000. La réaffectation doit avoir lieu le 01/01/2005 au moment où la deuxième moitié de Route1 est fusionnée avec Route2 en 2005. Les graphiques et les tableaux ci-dessous présentent les informations sur l’itinéraire avant et après la réaffectation.
Avant réaffectation de l’itinéraire
L’image suivante présente les itinéraires avant la réaffectation :
Le tableau suivant contient des détails sur les itinéraires avant la réaffectation :
| 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 | 5 |
Après réaffectation de l’itinéraire
L’image suivante présente les itinéraires après la réaffectation :
Le tableau suivant contient des détails sur les itinéraires après la réaffectation :
| 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 | 10 |
| Route1 | 01/01/2005 | <Nul> | 0 | 5 |
| Route2 | 01/01/2000 | 01/01/2005 | 0 | 5 |
| Route2 | 01/01/2005 | <Nul> | 0 | 10 |
Événements avant la réaffectation
L’image suivante présente les itinéraires et les événements avant la réaffectation :
Le tableau suivant contient des détails sur les événements avant la réaffectation :
| É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 | 7 |
| Event2 | Route1 | 01/01/2000 | <Nul> | 7 | 10 |
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 en dehors de la région réaffectée est préservée, les mesures peuvent changer. L’événement peut également être divisé s’il traverse la région réaffectée. Des parties de la région réaffectée sont retirées.
La réaffectation décrite ci-dessus a les effets suivants :
- Event1 se trouvait en partie dans la section de mise à jour. Il est retiré à la date de la réaffectation et un événement est créé sur la partie non impactée avec la date de la réaffectation comme date de début. La mesure d’arrivée est modifiée pour prendre en compte la nouvelle mesure finale (5) de Route1.
- Event2 est retiré à la date de la réaffectation, car il se trouvait intégralement dans la section de mise à jour.
L’image suivante présente les itinéraires et les événements après la réaffectation :
Remarque :
Il est important de noter que l’événement retiré n’est pas représenté dans le graphique ci-dessus.
Le tableau suivant contient des détails sur les événements après la réaffectation lorsque le comportement d’événement Stay Put (Immobile) est configuré :
| É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 | 7 | Aucune erreur |
| Event1 | Route1 | 01/01/2005 | <Nul> | 0 | 5 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 7 | 10 | 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.
La réaffectation décrite ci-dessus a les effets suivants :
- Event1 se trouvait en partie dans la section de mise à jour. Il est retiré à la date de la réaffectation et un événement dont la date de début correspond à la date de réaffectation est créé sur la partie non impactée. Comme les mesures ne changent pas pour le comportement Déplacer, une erreur de localisation existe pour la mesure d’arrivée étant donné que la mesure 7 n’existe plus sur Route1.
- Event2 est retiré à la date de la réaffectation puisqu’il se trouvait dans la section de mise à jour. À la date de la réaffectation, un événement est créé. Comme les mesures restent identiques, le nouvel événement produit hérite de l’erreur de localisation puisque les mesures de départ et d’arrivée sont introuvables sur Route1.
L’image suivante présente les itinéraires et les événements après la réaffectation :
Le tableau suivant contient des détails sur les événements après la réaffectation lorsque le comportement d’événement Move (Déplacer) est configuré :
| É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 | 7 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 7 | 10 | Aucune erreur |
| Event1 | Route1 | 01/01/2005 | <Nul> | 0 | 7 | Correspondance partielle pour la mesure d’arrivée |
| Event2 | Route1 | 01/01/2005 | <Nul> | 7 | 10 | Étendue de mesure hors de la plage de mesures d’itinéraire |
Remarque :
Le nouvel Event2 existe une fois l’outil Appliquer le comportement d’événement exécuté mais n’a pas de forme.
Comportement d’événement Retirer
Les événements intersectant la région de réaffectation sont retirés. Les deux événements sont retirés.
- Event1 se trouvait dans la section de mise à jour ; il est retiré à la date de réaffectation.
- Event2 se trouvait dans la section de mise à jour , il est retiré à la date de réaffectation.
L’image suivante présente les itinéraires et les événements après la réaffectation :
Le tableau suivant contient des détails sur les événements après la réaffectation lorsque le comportement d’événement Retire (Retirer) est configuré :
| É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 | 7 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 7 | 10 | Aucune erreur |
Comportement d’événement Capturer
Même si la localisation géographique de l’événement et préservée en capturant l’itinéraire sur lequel il a été réaffecté, les mesures peuvent changer. L’événement peut également être divisé s’il traverse la région réaffectée.
La réaffectation décrite ci-dessus a les effets suivants :
- Event1 se trouvait en partie dans la section de mise à jour. Il est retiré à la date de la réaffectation et un événement dont la date de début correspond à la date de réaffectation est créé sur la partie non impactée de Route1.
- La partie de Event1 qui se trouvait dans la partie impactée est capturée sur le nouvel itinéraire avec les nouvelles mesures sous-jacentes sur Route2. Sa date de début correspond à la date de réaffectation.
- Event2 est retiré à la date de la réaffectation puisqu’il se trouvait dans la section de mise à jour. À partir de date de la réaffectation, un événement est créé et capturé sur l’itinéraire avec les nouvelles mesures sous-jacentes sur Route2. Sa date de début correspond à la date de réaffectation.
L’image suivante présente les itinéraires et les événements après la réaffectation :
Le tableau suivant contient des détails sur les événements après la réaffectation lorsque le comportement d’événement Snap (Capture) est configuré :
| É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 | 7 | Aucune erreur |
| Event1 | Route1 | 01/01/2005 | <Nul> | 0 | 5 | Aucune erreur |
| Event1 | Route2 | 01/01/2005 | <Nul> | 0 | 2 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 7 | 10 | Aucune erreur |
| Event2 | Route2 | 01/01/2005 | <Nul> | 2 | 5 | Aucune erreur |
Résultats détaillés pour les itinéraires d’un réseau linéaire comportant des événements qui couvrent des itinéraires
Dans cet exemple, quatre itinéraires figurent sur la même ligne et sont actifs à partir du 01/01/2000. La réaffectation doit avoir lieu le 01/01/2005 au moment où l’intégralité de Route3 est fusionnée avec Route4 en 2005. La case Recalibrate route downstream (Recalibrer l’itinéraire en aval) est cochée. Les graphiques et les tables ci-dessous illustrent les informations sur l’itinéraire avant et après la réaffectation.
Avant réaffectation de l’itinéraire
L’image suivante présente les itinéraires avant la réaffectation :
Le tableau suivant contient des détails sur les itinéraires avant la réaffectation :
| 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 réaffectation de l’itinéraire
L’image suivante présente les itinéraires après la réaffectation :
Le tableau suivant contient des détails sur les itinéraires après la réaffectation :
| 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 | 01/01/2005 | 25 | 35 |
| Route4 | LineA | 400 | 01/01/2000 | 01/01/2005 | 38 | 48 |
| Route4 | LineA | 300 | 01/01/2005 | <Nul> | 25 | 45 |
Événements avant la réaffectation
L’image suivante présente les itinéraires et l’événement avant la réaffectation :
Le tableau suivant contient des détails sur l’événement avant la réaffectation :
| 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 | Route4 | 0 | 48 |
Les sections suivantes décrivent la façon dont les règles de comportement d’événement sont appliquées lorsque les itinéraires d’une ligne d’un réseau linéaire sont réaffectés.
Comportement Immobile
Après la réaffectation décrite ci-dessus, Event1 fait partie de la section de mise à jour. Il est retiré à la date de la réaffectation et un événement dont la date de début correspond à la date de réaffectation est créé. Le nouvel événement se trouve uniquement sur Route1 et Route2 qui n’ont pas été touchés par la mise à jour.
L’image suivante présente les itinéraires et les événements après la réaffectation :
Remarque :
Il est important de noter que l’événement retiré n’est pas représenté dans le graphique ci-dessus.
Le tableau suivant contient des détails sur les événements après la réaffectation lorsque le comportement d’événement Stay Put (Immobile) est configuré :
| Événement | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|---|
| Event1 | Route1 | Route4 | 01/01/2000 | 01/01/2005 | 0 | 48 | Aucune erreur |
| Event1 | Route1 | Route2 | 01/01/2005 | <Nul> | 0 | 22 | Aucune erreur |
Comportement Déplacer
Après la réaffectation décrite ci-dessus, Event1 se trouvait partiellement dans la section de mise à jour. Il est retiré à la date de la réaffectation et un événement dont la date de début correspond à la date de réaffectation est créé. Le comportement Déplacer n’autorise pas le remplacement des ID d’itinéraire de départ et d’itinéraire d’arrivée ni des mesures de l’événement. Une erreur de localisation existe pour la mesure d’arrivée étant donné que la mesure 48 n’existe plus sur Route4.
L’image suivante présente les itinéraires et les événements après la réaffectation :
Le tableau suivant contient des détails sur les événements après la réaffectation lorsque le comportement d’événement Move (Déplacer) est configuré :
| ID de l’événement | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|---|
| Event1 | Route1 | Route4 | 01/01/2000 | 01/01/2005 | 0 | 48 | Aucune erreur |
| Event1 | Route1 | Route4 | 01/01/2005 | <Nul> | 0 | 48 | Correspondance partielle pour la mesure d’arrivée |
Comportement Retirer
Les événements intersectant la région de réaffectation sont retirés. Event1 se trouvait dans la section de mise à jour ; il est retiré à la date de réaffectation.
L’image suivante présente les itinéraires et les événements après la réaffectation :
Le tableau suivant contient des détails sur les événements après la réaffectation lorsque le comportement d’événement Retire (Retirer) est configuré :
| Événement | Nom de l’itinéraire de départ | Nom de l’itinéraire d’arrivée | Date de début | Date de fin | Mesure de départ | Mesure d’arrivée | Erreur de localisation |
|---|---|---|---|---|---|---|---|
| Event1 | Route1 | Route4 | 01/01/2000 | 01/01/2005 | 0 | 48 | Aucune erreur |
Comportement d’événement Capturer
Après la réaffectation décrite ci-dessus, Event1 se trouvait dans la section de mise à jour. Il est retiré à la date de la réaffectation et un événement dont la date de début correspond à la date de réaffectation est créé sur les nouveaux itinéraires à l’aide des nouvelles mesures sous-jacentes afin de préserver sa localisation géographique.
L’image suivante présente les itinéraires et les événements après la réaffectation :
Le tableau suivant contient des détails sur les événements après la réaffectation lorsque le comportement d’événement Snap (Capture) est configuré :
| É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 | Route4 | 0 | 48 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route1 | Route4 | 0 | 45 | Aucune erreur |
Vous avez un commentaire à formuler concernant cette rubrique ?