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 Former un nouvel itinéraire
- Un itinéraire est créé en fusionnant les itinéraires source si plusieurs itinéraires sont sélectionnés dans la source.
- Un itinéraire est créé en fractionnant l’itinéraire source si un itinéraire partiel est sélectionné dans la source.
- L’itinéraire est renommé en sélectionnant l’intégralité de l’itinéraire et en indiquant un nouveau nom ou ID d’itinéraire.
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 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 divisés en intervalles par leurs opérations de mise à jour, telles que la réaffectation d’un itinéraire.
Les sections ci-après détaillent deux fonctionnalités de la méthode Form a new route (Former un nouvel itinéraire) : fractionnement et modification du nom. Les fonctionnalités supplémentaires, telles que la fusion, fonctionnent comme la méthode Fusionner avec l’itinéraire adjacent.
Former un nouvel itinéraire en fractionnant un itinéraire existant
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 fractionnée et forme un nouvel itinéraire 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 |
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 |
| RouteNew | 01/01/2005 | <Nul> | 0 | 5 |
É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 manière 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) si un itinéraire est créé en fractionnant l’itinéraire source.
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 de l’itinéraire 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 les événements retirés ne sont pas représentés 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 loc |
|---|---|---|---|---|---|---|
| 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 de l’itinéraire 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. Les mesures ne changeant pas pour le comportement Move (Déplacer), une erreur de localisation existe pour la mesure d’arrivée car 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.
- 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 :
Remarque :
Il est important de noter que les événements retirés ne sont pas représentés 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 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 loc |
|---|---|---|---|---|---|---|
| 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 de l’itinéraire 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 d’Event1 qui se trouvait dans la partie impactée est capturée sur le nouvel itinéraire avec les nouvelles mesures sous-jacentes sur RouteNew. 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 le nouvel itinéraire avec les nouvelles mesures sous-jacentes sur RouteNew. 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 | RouteNew | 01/01/2005 | <Nul> | 0 | 2 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 7 | 10 | Aucune erreur |
| Event2 | RouteNew | 01/01/2005 | <Nul> | 2 | 5 | Aucune erreur |
Former un nouvel itinéraire en renommant un itinéraire existant
Dans cet exemple, les itinéraires sont actifs depuis la réaffectation du 01/01/2000. La réaffectation doit avoir lieu le 01/01/2005, date à laquelle Route1 est renommé RouteNew et ses mesures sont conservées 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 |
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 |
| RouteNew | 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 manière 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) si un itinéraire est créé en renommant un itinéraire source.
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.
L’intégralité de l’itinéraire Route1 étant réaffectée à RouteNew, les deux événements sont retirés.
- Event1 se trouvait intégralement dans la section de mise à jour ; il est retiré à la date de réaffectation.
- Event2 se trouvait intégralement 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 :
Remarque :
Il est important de noter que les événements retirés ne sont pas représentés 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 |
|---|---|---|---|---|---|
| Event1 | Route1 | 01/01/2000 | 01/01/2005 | 0 | 7 |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 7 | 10 |
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 scénario de changement de nom d’itinéraire décrit ci-avant a les effets suivants :
- Event1 se trouvait intégralement 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éé. Une erreur de localisation est générée pour le nouvel événement car l’itinéraire Route1 d’origine n’existe pas depuis le 01/01/2005, un nouvel itinéraire RouteNew l’ayant remplacé. Les mesures restent cependant identiques.
- Event2 se trouvait intégralement 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éé. Une erreur de localisation est générée pour le nouvel événement car l’itinéraire Route1 d’origine n’existe pas depuis le 01/01/2005, un nouvel itinéraire RouteNew l’ayant remplacé. Les mesures restent cependant identiques.
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 | Itinéraire introuvable |
| Event2 | Route1 | 01/01/2005 | <Nul> | 7 | 10 | Itinéraire introuvable |
Remarque :
Les nouveaux itinéraires Event1 et Event2 existent une fois que l’outil Apply Event Behaviors (Appliquer les comportements d’événement) a été exécuté, mais ils ne possèdent pas de forme.
Comportement d’événement Retirer
Les événements intersectant la région de réaffectation sont retirés. L’intégralité de l’itinéraire Route1 étant réaffectée à RouteNew, les deux événements sont retirés.
- Event1 se trouvait intégralement dans la section de mise à jour ; il est retiré à la date de réaffectation.
- Event2 se trouvait intégralement 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 |
|---|---|---|---|---|---|
| Event1 | Route1 | 01/01/2000 | 01/01/2005 | 0 | 7 |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 7 | 10 |
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.
Le scénario de changement de nom d’itinéraire décrit ci-avant a les effets suivants :
- Event1 se trouvait intégralement 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 le nouvel itinéraire avec les nouvelles mesures sous-jacentes sur RouteNew. La localisation géographique de l’événement est conservée.
- Event2 est retiré à la date de la réaffectation puisqu’il se trouvait dans la section de mise à jour. À partir de la date de la réaffectation, un événement est créé et capturé sur le nouvel itinéraire avec les nouvelles mesures sous-jacentes sur RouteNew.
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 | RouteNew | 01/01/2005 | <Nul> | 0 | 7 | Aucune erreur |
| Event2 | Route1 | 01/01/2000 | 01/01/2005 | 7 | 10 | Aucune erreur |
| Event2 | RouteNew | 01/01/2005 | <Nul> | 7 | 10 | 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. Le 01/01/2005, trois réaffectations distinctes doivent avoir lieu.
- La première réaffectation fusionne Route1 et Route2 en un nouvel itinéraire, RouteM.
- La deuxième réaffectation fractionne Route3 à la mesure 28 et crée un itinéraire appelé RouteS à partir de la mesure d’origine 28 à 35 sur Route3 avec les valeurs cible de 0 à 20.
- La troisième réaffectation renomme Route4 en RouteR et conserve les mesures d’origine de Route4.
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 | 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 | 01/01/2005 | 0 | 10 |
| Route2 | LineA | 200 | 01/01/2000 | 01/01/2005 | 12 | 22 |
| RouteM | LineA | 100 | 01/01/2005 | <Nul> | 0 | 20 |
| Route3 | LineA | 300 | 01/01/2000 | 01/01/2005 | 25 | 35 |
| Route3 | LineA | 200 | 01/01/2005 | <Nul> | 25 | 28 |
| RouteS | LineA | 300 | 01/01/2005 | <Nul> | 0 | 20 |
| Route4 | LineA | 400 | 01/01/2000 | 01/01/2005 | 38 | 48 |
| RouteR | LineA | 400 | 01/01/2005 | <Nul> | 38 | 48 |
É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 d’extension 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 les trois réaffectations distinctes décrites 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 la portion de Route3 qui n’a pas été touchée par les trois mises à jour.
L’image suivante présente les itinéraires et l’événement 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 l’événement après la réaffectation si 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 loc |
|---|---|---|---|---|---|---|---|
| Event1 | Route1 | Route4 | 01/01/2000 | 01/01/2005 | 0 | 48 | Aucune erreur |
| Event1 | Route3 | Route3 | 01/01/2005 | <Nul> | 25 | 28 | Aucune erreur |
Comportement Déplacer
Après les trois réaffectations distinctes décrites 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. Il renvoie une erreur de localisation car les itinéraires de départ et d’arrivée (Route1 et Route4) n’existent pas depuis le 01/01/2005.
L’image suivante présente les itinéraires et l’événement après la réaffectation :
Le tableau suivant contient des détails sur l’événement après la réaffectation si le comportement d’événement Move (Déplacer) est configuré :
| 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 | Route4 | 0 | 48 | Aucune erreur |
| Event1 | 01/01/2005 | <Nul> | Route1 | Route4 | 0 | 48 | Itinéraire introuvable |
Remarque :
Le nouvel Event1 existe une fois que l’outil Apply Event Behaviors (Appliquer les comportements d’événement) a été exécuté, mais il ne possède pas de forme.
Comportement Retirer
Après les trois réaffectations distinctes décrites ci-dessus, Event1 se trouvait dans la section de mise à jour. Il est retiré à la date de la réaffectation.
L’image suivante présente les itinéraires et l’événement après la réaffectation :
Le tableau suivant contient des détails sur l’événement après la réaffectation si 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 loc |
|---|---|---|---|---|---|---|---|
| Event1 | Route1 | Route4 | 01/01/2000 | 01/01/2005 | 0 | 48 | Aucune erreur |
Comportement d’événement Capturer
Après les trois réaffectations distinctes décrites 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 l’événement après la réaffectation :
Le tableau suivant contient des détails sur l’événement après la réaffectation si le comportement d’événement Snap (Capturer) 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> | RouteM | RouteR | 0 | 48 | Aucune erreur |
Vous avez un commentaire à formuler concernant cette rubrique ?