Présentation rapide de la révision des conflits

Cette rubrique s'applique uniquement à ArcEditor et ArcInfo.

ArcGIS détecte les conflits lorsque vous effectuez une réconciliation. Les conflits surviennent dans les cas suivants :

• La même entité est actualisée à la fois dans la version actuellement mise à jour et la version cible.
• La même entité est actualisée dans une version et supprimée dans l'autre.
• Une entité ou une classe de relations reliée topologiquement est modifiée dans la version mise à jour et une version cible.

En cas de conflits, ArcGIS les résout en faveur de la représentation de la version mise à jour ou de la version cible, selon votre préférence. Une fois les conflits résolus, vous pouvez les réviser un par un et les modifier si nécessaire. Par exemple, si un conflit est résolu en faveur de la version mise à jour, vous pouvez choisir de la remplacer en faveur de la version cible ou utiliser les outils de mise à jour pour la modifier différemment.

Résolution interactive des conflits

Lorsque vous effectuez une réconciliation et que des conflits sont détectés, vous pouvez choisir de les réviser à l'aide de la boîte de dialogue Conflits. Elle affiche toutes les entités ou lignes des classes en conflit. Elle vous permet également d'effectuer les opérations suivantes :

• Déterminer les champs ou lignes en conflit.
• Visualiser les conflits.
• Résoudre les conflits en désignant la représentation à utiliser pour remplacer des entités ou des attributs.

Détermination des champs ou lignes en conflit

Toutes les classes et entités en conflit sont répertoriées dans la zone de liste affichée dans l'angle supérieur gauche de la boîte de dialogue Conflits. La liste Conflits vous indique le nombre total de conflits qui ont été révisés et le nombre total de conflits dans toutes les classes d'entités. Initialement, ces chiffres sont identiques. Dans l'exemple ci-dessous, deux objets sont en conflit et aucun d'eux n'a été révisé.

Conflicts (2/2)

La zone Conflits affiche une liste des classes d'entités présentant des conflits, suivie du nombre de conflits visités ou remplacés dans la classe d'entités et le nombre de conflits dans la classe d'entités. Dans cet exemple, deux classes d'entités présentent chacune un conflit.

Conflicts (2/2)

   sde.RJP.ponds (1/1)

   sde.RJP.lakes (1/1)

Les identifiants ObjectID des entités en conflit apparaissent sous chaque classe d'entités. Dans cet exemple, il existe un conflit pour l'identifiant ObjectID 30 de la classe d'entités d'étangs (ponds) et un conflit pour l'entité 11 de la classe d'entités de lacs (lakes).

Conflicts (2/2)

   sde.RJP.ponds (1/1)

        30

   sde.RJP.lakes (1/1)

        11

Comme vous pouvez le constater, aucun des objets n'a été visité ni remplacé car le rapport entre le nombre total de conflits révisés et le nombre total des conflits est toujours de (2/2) et (1/1) pour chaque classe d'entités. Vous pouvez également constater qu'aucun des conflits n'a été révisé ni remplacé car tous les identifiants ObjectID et toutes les classes d'entités apparaissent en gras.

Lorsque vous marquez des objets comme visités (voir la section "Marquer comme visité ou Marquer comme non visité" ci-dessous) ou remplacez des objets (voir la section "Résolution des conflits" ci-dessous), le premier nombre entre parenthèses diminue et l'identifiant de l'objet révisé n'apparaît plus en gras. Si tous les identifiants ObjectID d'une classe d'entités ont été marqués comme visités ou remplacés, la classe d'entités n'apparaît plus en gras. Dans l'exemple des étangs et des lacs, si vous marquez l'identifiant ObjectID 30 comme visité, les informations suivantes apparaissent dans la zone de liste de la boîte de dialogue Conflits :

Conflicts (1/2)

   sde.RJP.ponds (0/1)  

        30      

   sde.RJP.lakes (1/1)

        11

Si une deuxième entité d'étang est en conflit, la liste peut se présenter comme suit :

Conflicts (2/3)

   sde.RJP.ponds (1/2)

        5  

        30    

   sde.RJP.lakes (1/1)

        11

Cette liste indique qu'il existe trois conflits à la suite de la réconciliation et qu'un de ces conflits a été visité ou remplacé. La liste indique également que la valeur 30 représente l'identifiant ObjectID de l'entité en conflit qui a été visitée ou remplacée, et que cette entité figure dans la classe d'entités d'étangs.

Lorsque vous sélectionnez une entité individuelle dans la liste, les colonnes et les attributs des versions Mise à jour, Conflit et Ascendant commun de l'entité s'affichent à droite de la liste dans la boîte de dialogue Conflits.

• La version Mise à jour représente les mises à jour que vous avez effectuées au niveau de l'entité et de ses attributs.
• La version Conflit représente l'entité et ses attributs mis à jour et réconciliés par un autre utilisateur.
• La version Ascendant commun représente l'entité et ses attributs tels qu'ils figurent dans la base de données (l'état de l'entité et des attributs avant les modifications).

Un point rouge à gauche d'un nom de champ signale un conflit. Par exemple, si la géométrie de l'entité a été modifiée dans chaque version, un point rouge apparaît à côté du champ Forme.

Un point rouge apparaît en regard des autres champs attributaires en conflit. Si une entité a été supprimée dans l'une des versions, la mention <Supprimé> apparaît comme valeur attributaire de la version.

Les attributs et valeurs de toutes les représentations d'une entité en conflit vous permettent de visualiser comment les valeurs attributaires diffèrent, et vous aident à sélectionner la représentation des données à préserver.

Visualisation des conflits

Si vous cliquez sur le bouton Affichage des conflits de la boîte de dialogue, deux représentations (la version Mise à jour et la version Conflit) des entités en conflit apparaissent au bas de la boîte de dialogue.

Vous pouvez utiliser les listes déroulantes sous chaque représentation pour parcourir les trois représentations des entités en conflit : Mise à jour, Conflit et Ascendant commun. Notez que ces représentations diffèrent uniquement si les géométries des entités sont en conflit.

Une barre d'outils en bas de chaque représentation propose des outils permettant de parcourir et d'identifier la représentation correspondante.

Vous pouvez examiner en détail une version spécifique d'une entité en conflit sur votre carte en cliquant dans la liste à l'aide du bouton droit, puis en sélectionnant Zoom sur la version mise à jour, Zoom sur la version conflictuelle ou Zoom sur la version ascendant.

En cas de conflits au niveau de la géométrie, vous pouvez également afficher d'autres représentations sur la carte en cliquant avec le bouton droit dans le champ Forme de la zone de liste, puis en sélectionnant Afficher.

La boîte de dialogue Paramètres d'affichage des conflits s'affiche. Cliquez sur la représentation que vous souhaitez afficher sur la carte.

Après avoir cliqué sur OK, voici ce qui se passe sur la carte :

• La représentation de la version Conflit (cible) apparaît en rouge.
• La représentation mise à jour apparaît en vert.
• La représentation de la version Ascendant commun apparaît en bleu.

Si les options sont cochées comme dans la boîte de dialogue Paramètres d'affichage des conflits ci-dessus, les éléments suivants apparaissent sur la carte :

Si seule l'option Afficher la version actuelle est sélectionnée dans la boîte de dialogue Paramètres d'affichage des conflits, les éléments suivants apparaissent sur la carte :

Après avoir révisé les conflits, vous pouvez les marquer comme visités ou choisir une option de remplacement afin de résoudre le conflit.

Marquer comme visité ou Marquer comme non visité

Comme indiqué dans la section "Détermination des champs ou lignes en conflit", vous pouvez marquer une entité comme visitée. Vous indiquez ainsi que vous avez révisé le conflit mais que ne souhaitez pas choisir une option de remplacement pour l'instant. Vous pouvez effectuer le suivi des entités que vous avez révisées car celles marquées comme visitées n'apparaissent plus en gras dans la liste.

Si vous décidez de revenir ultérieurement sur un conflit d'entité, cliquez avec le bouton droit sur l'identifiant ObjectID dans la liste Conflits, puis sélectionnez Marquer comme non visité. L'entité s'affiche de nouveau en gras.

Résolution des conflits

• Remplacement d'attribut
• remplacement d'entité
• Remplacement au niveau de la classe
• Remplacement complet
• Combinaison de géométries

  Cette opération se produit au niveau du champ et est associée expressément à l'attribut Forme. L'option de combinaison des géométries est disponible lorsqu'il existe un conflit avec le champ Shape. Si deux éditeurs mettent à jour la géométrie de la même entité, mais ne modifient pas la même zone de cette entité, ils ont la possibilité de résoudre le conflit en combinant des géométries et en acceptant les deux mises à jour.

  L'option de combinaison des géométries est disponible uniquement dans le menu contextuel du champ Shape.
  Une fois les géométries combinées, vous obtenez une entité contenant les mises à jour effectuées par les deux éditeurs :
  Si les mises à jour effectuées par un éditeur partagent une région qui a également été mise à jour par un autre éditeur, leurs zones modifiées se chevauchent. Bien que l'option de combinaison des géométries soit peut-être disponible, toute tentative de combinaison se soldera par un échec. Dans ce cas, le message d'erreur suivant est affiché :

Conflits dans des réseaux géométriques

Lorsque vous mettez à jour les entités d'un réseau, les modifications apportées tant au réseau géométrique qu'au réseau logique risquent de créer des conflits.

Par exemple, lorsque vous ajoutez un service à une canalisation, cette dernière n'est pas fractionnée physiquement dans le réseau géométrique mais dans le réseau logique. Par conséquent, même si vous n'avez pas mis à jour la géométrie de la canalisation directement, elle a été mise à jour logiquement. Si la version cible que vous réconciliez a également modifié la canalisation, le nouveau service que vous insérez entraînera un conflit avec la canalisation.

Pour réviser un conflit entre des classes d'entités du réseau géométrique, vous devez comprendre comment la commande "Remplacer par" de la boîte de dialogue Conflits procède pour mettre à jour la topologie du réseau existant présente dans la session de mise à jour.

Dans l'exemple de canalisation, deux utilisateurs modifiaient la canalisation, l'un en changeant un attribut et l'autre en branchant un nouveau service. Une révision peut être nécessaire pour vérifier les différences et décider si le conflit est valide et si aucune résolution n'est requise. Puisque l'attribut de diamètre de la canalisation est correct, le nouveau service est correctement branché sur la canalisation. Cependant, dans certains cas, la résolution de conflits impliquant une classe d'entités jonctions met également à jour le tronçon du réseau connecté.

Conflits dans des annotations liées aux entités

Lorsque vous travaillez avec des annotations liées aux entités, vous devez vous rappeler une règle : quand vous remplacez une entité qui a des annotations liées aux entités, l'entité et l'annotation sont remplacées par la nouvelle entité et la nouvelle annotation. En conséquence, vous serez peut-être amené à poursuivre la mise à jour de la nouvelle annotation pour éviter de vous retrouver avec deux annotations.

Par exemple, vous pourriez rencontrer un conflit lors du déplacement d'une entité et du repositionnement de son annotation. La version conflictuelle a effectué la même mise à jour, c'est-à-dire le déplacement de l'entité et le pivotement de l'annotation. Si vous décidez de remplacer l'entité par celle de la version Conflit, l'annotation liée à une entité existante est supprimée, l'entité en conflit est insérée, et une nouvelle annotation est créée. Vous devez ensuite poursuivre la mise à jour de la nouvelle annotation en la déplaçant ou la pivotant si nécessaire.

Vous risquez également de rencontrer un conflit dans lequel un autre éditeur a supprimé une entité dans la version DEFAULT de la géodatabase, entraînant la suppression de son annotation. Dans une version enfant de la géodatabase, vous mettez à jour l'annotation qui vient d'être supprimée. Lors de la réconciliation, si vous décidez de remplacer l'entité par la version mise à jour, l'entité qui avait été supprimée de la version DEFAULT et son annotation liée associée sera remplacée, puis vous récupérez l'annotation de votre session de mise à jour pour vous retrouver ainsi avec deux annotations pour la même entité.

Conflits dans des relations

Les relations ont des dépendances similaires avec les annotations liées aux entités. La suppression d'une entité d'une classe de relations source risque de déclencher un message entraînant la suppression d'une entité de la classe de relations destinataire. Soyez conscients des ramifications lorsque vous décidez d'effectuer un remplacement lors de conflit impliquant des classes d'entités qui font partie de classes de relations.

Voici un exemple de conflit susceptible de survenir entre des classes de relations :

• Vous actualisez le champ principal de la classe d'origine, rompant ainsi la relation dans la version A.
• En même temps, vous actualisez l'entité reliée de la classe de destination dans la version B.
• La classe de destination étant dépendante de la classe d'origine, un conflit est détecté lorsque vous réconciliez les versions.

Voici un autre exemple :

• Dans votre jeu de données d'entité d'installations électriques, vous supprimez un pylône relié à un transformateur, ce qui entraîne la suppression de celui-ci.
• Dans une autre session de mise à jour simultanée, un éditeur modifie les attributs du transformateur que vous venez de supprimer en supprimant son pylône associé.
• Une fois les modifications réconciliées, un conflit actualisation/mise à jour est détecté.

Dans ce dernier exemple, si le second éditeur choisit de remplacer tous les conflits par les représentations de la session de mise à jour, le pylône et le transformateur supprimés lors de votre session de mise à jour seront recréés, et le transformateur de la session du second éditeur sera créé : vous vous retrouvez donc avec deux transformateurs. Vous risquez de ne pas pouvoir détecter ce conflit sur la carte car les transformateurs seront superposés, mais la table attributaire contiendra deux enregistrements pour le transformateur.

Conflits dans des topologies

Dans la mesure où les entités des classes d'entités participant à une topologie peuvent partager leur géométrie avec d'autres entités, la révision des conflits entre versions de classes d'entités topologiques diffère de la révision des conflits de classes d'entités simples. Elle diffère également du remplacement des conflits de réseaux géométriques, de classes de relations et d'annotations liées à des entités.

Lorsqu'une classe d'entités participant à une topologie est éditée, d'autres entités topologiquement liées peuvent être simultanément changées. Les entités changées peuvent appartenir à la même classe d'entités ou à une ou plusieurs autres classes d'entités. Pour gérer le processus de détection des nouvelles erreurs de topologie éventuellement survenues suite à des modifications, les topologies enregistrent en tant que zones à valider les emplacements où ces modifications ont été effectuées. La modification d'entités d'une topologie crée des zones à valider dans la topologie.

De nouvelles erreurs topologiques peuvent survenir lors de la réconciliation de versions parent et enfant, même lorsque les zones à valider au sein de chaque version sont validées et exemptes d'erreurs. Pour détecter de telles erreurs topologiques, toutes les zones à valider dans une version enfant retrouvent leur statut à valider après que les modifications issues de la version parent ont été appliquées à cette version enfant lors d'une réconciliation. Après la réconciliation, ces zones peuvent être revalidées et toutes les erreurs sont alors détectées.

Réconcilier deux versions ne présentant pas de zones à valider actives peut encore engendrer des zones à valider. Les zones à valider qui figuraient dans la version enfant, qu'elles aient été validées ou non, seront des zones à valider une fois les versions réconciliées. En règle générale, lors de la réconciliation d'une version :

• Les zones à valider que la version enfant a hérité de la version parent, qu'elles soient validées ou non dans la version enfant, seront des zones à valider après la réconciliation.
• Les zones à valider qui ont été créées pour des entités conçues, mises à jour ou supprimées dans la version enfant, qu'elles soient validées ou non, seront des zones à valider après la réconciliation.