Zones à valider dans les classes d'entités versionnées

Disponible avec une licence Standard ou Advanced.

Plusieurs éditeurs peuvent modifier simultanément un jeu de classes d’entités et sa topologie.

• Chaque éditeur suit un processus permettant de valider sa topologie modifiée et de rechercher et corriger les erreurs (ou de les définir comme exceptions) pour la version de mise à jour.
• En règle générale, plusieurs versions de mise à jour sont fusionnées dans une version commune (habituellement désignée sous le nom de version par défaut).
• De nouvelles erreurs topologiques peuvent survenir lors de la réconciliation de versions et lorsque des conflits potentiels ont lieu, même si chaque version de mise à jour a été validée et est exempte d’erreurs.
• Pour gérer ces erreurs, les topologies versionnées disposent d'un mode de gestion des erreurs particulier et de règles de détection des conflits propres qui influent sur le processus de réconciliation.

Les sections suivantes décrivent les résultats de la réconciliation des zones à valider, erreurs, exceptions et conflits potentiels. Dans chaque cas, les résultats reposent sur une réconciliation dans laquelle une version parent (version par défaut) et une version enfant ont toutes les deux été mises à jour depuis la création de la version enfant. Si la version parent (version par défaut) n’est pas mise à jour avant la réconciliation de la version enfant, les résultats de la réconciliation correspondent au contenu de la version enfant. Dans chaque exemple, la version 2 est créée en tant qu’enfant de la version 1 (version par défaut). Les deux versions sont ensuite mises à jour de la manière décrite dans l’exemple. Ensuite, la version 2 (version par défaut) est réconciliée avec la version 1. Pour les illustrations des exemples suivants, utilisez ce qui suit comme légende :

Remarque :

Dans le versionnement de branche, dans les exemples suivants, la version 1 est la version par défaut et la version 2 un enfant de la version par défaut.

Exemple 1

• Les zones à valider présentes dans la version parent (version par défaut) ou enfant qui n’existaient pas avant la création de la version parent (version par défaut) et de la version enfant resteront à valider à la suite de la réconciliation.

  

• Les zones à valider qui étaient présentes dans la version parent (version par défaut) et validées dans la version enfant deviennent des zones à valider à la suite de la réconciliation.

  

• Les zones à valider introduites et validées dans la version parent (version par défaut), qu’elles étaient ou non présentes dans la version enfant, restent validées à la suite de la réconciliation.

  

Comme illustré ci-dessus, l’état d’origine du parent (version par défaut) (aucune zone à valider) est conservé après la réconciliation. Toutefois, d'autres zones à valider peuvent être créées à la suite des mises à jour apportées à la version enfant.

Les exemples 2 et 3 ci-dessous illustrent d’autres scénarios dans lesquels les zones à valider introduites et validées dans la version parent (version par défaut) restent validées à la suite de la réconciliation.

Exemple 2

Exemple 3

Les mises à jour apportées aux entités topologiques dans la version enfant génèrent une zone à valider après la réconciliation, même si la zone à valider provenant de la mise à jour est validée dans la version enfant. Cela est également le cas lorsque la mise à jour d'origine n'a pas entraîné de zone à valider, par exemple une mise à jour attributaire. Cela est illustré dans les exemples ci-dessous.

Remarque :

Dans l'exemple suivant, la version 1 et la version 2 ont toutes les deux été mises à jour. Toutefois, la forme du polygone dans l'exemple a uniquement été modifié dans la version 2.

Exemple 4 :

Exemple 5 :