Présentation rapide de la révision des conflits

Cette rubrique s'applique uniquement à ArcGIS for Desktop Standard et ArcGIS for Desktop Advanced.

ArcGIS détecte les conflits lorsque vous réconciliez la version que vous mettez à jour avec une version cible. Des conflits surviennent dans les instances suivantes :

• 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'ID d'objet 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, le nom de la classe d'entités n'apparaît plus en gras. Dans l'exemple des étangs et des lacs, si vous marquez l'identifiant d'objet 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

Lorsque vous résolvez des conflits, vous choisissez la représentation des entités et des attributs que vous souhaitez conserver. Quelle que soit la version en faveur de laquelle vous souhaitez effectuer une réconciliation (version cible ou mise à jour), vous pouvez spécifier la représentation à conserver : mise à jour (telle qu'elle apparaissait dans votre version avant la réconciliation), conflictuelle (telle qu'elle apparaît dans les modifications apportées par un autre éditeur) ou ascendant commun (telle que l'entité ou l'attribut apparaît dans la version cible).

Il existe cinq options de remplacement différentes permettant de résoudre des conflits :

• Remplacement d'attribut

  Cette méthode est appliquée au niveau du champ. Si les attributs présentent des conflits, vous pouvez simplement remplacer la valeur attributaire dans la version actuelle par la valeur d'une représentation Mise jour, Conflit ou Ascendant commun. Pour ce faire, cliquez avec le bouton droit sur l'attribut en conflit, puis sélectionnez l'option de votre choix dans le menu contextuel.

• remplacement d'entité

  Cette méthode est appliquée au niveau de la ligne. Vous pouvez remplacer une entité complète par la représentation de l'entité de la version Mise à jour, Conflit ou Ascendant commun. Cela signifie que tous les champs en conflit seront remplacés.

• Remplacement au niveau de la classe

  Vous pouvez choisir de remplacer la représentation actuelle de la classe d'entités complète à l'aide d'une version Mise à jour, Conflit ou Ascendant commun afin de résoudre le conflit. Cette méthode remplace l'ensemble des entités et attributs conflictuels en une seule fois, ce qui vous permet d'actualiser et de remplacer rapidement les entités conflictuelles. Si la liste Conflits contient plusieurs entités, toutes ces entités sont remplacées par la version de votre choix.

  Pour choisir une option de remplacement au niveau de la classe, cliquez avec le bouton droit sur le nom de la classe d'entités dans la liste Conflits, puis sélectionnez la version que vous souhaitez utiliser.

• Remplacement complet

  Il s'agit d'un remplacement au niveau de la racine L'utilisation de cette option de remplacement remplace toutes les entités et classes d'entités en conflit de la liste par la représentation sélectionnée. Si plusieurs classes d'entités et objets sont en conflit, ils sont tous remplacés par la version de votre choix.

  Cliquez avec le bouton droit sur le nom de la classe d'entité dans la liste des conflits, puis choisissez la version à utiliser pour remplacer tous les conflits.

• 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 la combinaison des géométries soit possible, toute tentative de combinaison se soldera par un échec. Dans ce cas, le message d'erreur suivant est affiché :

  "Erreur détectée lors de la combinaison des géométries. Impossible de combiner les deux géométries. Les régions mises à jour se chevauchent."

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 classes d'entités 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 général, lors de la réconciliation d'une version, les éléments suivants sont vrais :

• Les zones à valider que la version enfant a héritées 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.

Conflits dans les jeux de données réseau

La mise à jour d'une classe d'entités qui fait partie d'un jeu de données réseau risque de modifier la connectivité, c'est-à-dire la connexion des éléments du réseau entre eux. (Les éléments du réseau peuvent représenter des rues, des ponts, et ainsi de suite.) En outre, plusieurs classes d'entités peuvent participer à un jeu de données réseau, de sorte que la modification d'une classe d'entités source peut modifier la connectivité d'éléments du réseau générée d'autres classes d'entités source.

Comme plusieurs classes d'entités peuvent participer à un jeu de données réseau et la connectivité est basée en partie sur les relations géométriques, le processus de révision des conflits dans les jeux de données réseau est très similaire à celui des topologies. Une illustration simple de ce phénomène est que les jeux de données réseau utilisent également des zones à valider, mais ils sont utilisés pour gérer le processus de détection des changements de connectivité et non des erreurs topologiques.

Pour en savoir plus sur la modification de jeux de données réseau