Méthode Fusionner avec l’itinéraire adjacent

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 :

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.

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 :

Sections en amont et en aval du scénario de réaffectation d’itinéraire avec une section mise à jour entre elles

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 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 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 :

Les itinéraires avant la réaffectation avec un itinéraire source à fusionner dans l’itinéraire cible, dans la deuxième moitié de l’itinéraire.

Le tableau suivant contient des détails sur les itinéraires avant la réaffectation :

Nom de l’itinéraireDate de débutDate de finMesure de départMesure 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 :

Les itinéraires après réaffectation avec la fusion des itinéraires source et cible

Le tableau suivant contient des détails sur les itinéraires après la réaffectation :

Nom de l’itinéraireDate de débutDate de finMesure de départMesure 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 :

Les itinéraires et les événements après réaffectation avec la fusion des itinéraires source et cible

Le tableau suivant contient des détails sur les événements avant la réaffectation :

ÉvénementNom de l’itinéraireDate de débutDate de finMesure de départMesure 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 :

Les itinéraires et les événements après la réaffectation, Event1 étant partiellement retiré et Event2 étant retiré

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énementNom de l’itinéraireDate de débutDate de finMesure de départMesure d’arrivéeErreur 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 :

Les itinéraires et les événements après la réaffectation, Event1 est partiellement et détient une erreur de localisation, et Event2 est mis à jour avec une erreur de localisation

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énementNom de l’itinéraireDate de débutDate de finMesure de départMesure d’arrivéeErreur 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 :

Les itinéraires et les événements après la réaffectation, Event1 et Event2 étant retirés

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énementNom de l’itinéraireDate de débutDate de finMesure de départMesure d’arrivéeErreur 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 :

Les itinéraires et les événements après la réaffectation, l’événement Event1 initial étant retiré, les nouveaux enregistrements d’Event1 sont créés selon les nouvelles mesures ; l’événement Event2 initial étant retiré, un nouvel enregistrement est créé selon les nouvelles mesures.

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énementNom de l’itinéraireDate de débutDate de finMesure de départMesure d’arrivéeErreur 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 :

Les quatre itinéraires avant réaffectation avec la fusion de Route3 et de Route4

Le tableau suivant contient des détails sur les itinéraires avant la réaffectation :

Nom de l’itinéraireNom de la ligneOrdre de ligneDate de débutDate de finMesure de départMesure 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 :

Les trois itinéraires après réaffectation avec la fusion de Route3 et de Route4

Le tableau suivant contient des détails sur les itinéraires après la réaffectation :

Nom de l’itinéraireNom de la ligneOrdre de ligneDate de débutDate de finMesure de départMesure 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 :

Les quatre itinéraires et les événements avant réaffectation avec la fusion de Route3 et de Route4

Le tableau suivant contient des détails sur l’événement avant la réaffectation :

ID de l’événementDate de débutDate de finNom de l’itinéraire de départNom de l’itinéraire d’arrivéeMesure de départMesure 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 :

Les trois itinéraires et les événements après la réaffectation, Event1 se trouvant seulement sur Route 1 et Route2

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énementNom de l’itinéraire de départNom de l’itinéraire d’arrivéeDate de débutDate de finMesure de départMesure d’arrivéeErreur 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 :

Les trois itinéraires et les événements après la réaffectation, Event1 étant généré et dessiné avec une erreur de localisation

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énementNom de l’itinéraire de départNom de l’itinéraire d’arrivéeDate de débutDate de finMesure de départMesure d’arrivéeErreur 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 :

Les trois itinéraires et aucun événement après la réaffectation, Event1 étant retiré

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énementNom de l’itinéraire de départNom de l’itinéraire d’arrivéeDate de débutDate de finMesure de départMesure d’arrivéeErreur 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 :

Les trois itinéraires et l’événement Event1 mis à jour selon les nouvelles mesures 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énementDate de débutDate de finNom de l’itinéraire de départNom de l’itinéraire d’arrivéeMesure de départMesure d’arrivéeErreur 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