A quick tour of reviewing conflicts

This topic applies to ArcEditor and ArcInfo only.

ArcGIS detects conflicts when you reconcile. Conflicts occur when

If there are conflicts, ArcGIS resolves them in favor of either the edit version or the target version representation, depending on your preference. Once conflicts are resolved, you can review them one at a time and, if necessary, make any changes. For example, if a conflict is resolved in favor of the edit version, you can choose to replace it in favor of the target version or use the editing tools to modify it in another way.

Interactive conflict resolution

When you reconcile and conflicts are detected, you can choose to review them with the interactive Conflicts dialog box. It contains all the conflict classes and their features or rows in conflict. It also lets you

Determining which fields or rows are in conflict

All conflicting classes and features are shown in the list box in the upper left side of the Conflicts dialog box. This Conflicts list tells you the total number of conflicts that have been reviewed and the total number of conflicts in all feature classes. Initially, these numbers will be the same. In the example below, there is a total of two objects in conflict and neither of them has been reviewed.

Conflicts (2/2)

Under Conflicts is a list of the feature classes that contain conflicts followed by the number of conflicts visited or replaced in the feature class and the number of conflicts in the feature class. In this example, two feature classes each contain one conflict.

Conflicts (2/2)

   sde.RJP.ponds (1/1)

   sde.RJP.lakes (1/1)

Under each feature class, the ObjectIDs for the features in conflict are listed. In this example, there is a conflict for ObjectID 30 in the ponds feature class and a conflict for feature 11 in the lakes feature class.

Conflicts (2/2)

   sde.RJP.ponds (1/1)


   sde.RJP.lakes (1/1)


You can tell that none of the objects has been visited or replaced because the ratio of total reviewed conflicts to total conflicts is still (2/2) and (1/1) for each feature class. You can also tell none of the conflicts has been viewed or replaced because all ObjectIDs and feature classes are in bold.

As you mark objects as visited (see "Mark as Visited or Mark as not visited" below) or replace objects (see the "Resolving conflicts" section below), the first number in parentheses decreases, and the reviewed object ID is no longer in bold. If all ObjectIDs in a feature class have been marked visited or replaced, the feature class itself is no longer in bold. In the ponds and lakes example, if you marked ObjectID30 as visited, you would see the following in the list box of the Conflicts dialog box:

Conflicts (1/2)

   sde.RJP.ponds (0/1)  


   sde.RJP.lakes (1/1)


If there had been a second ponds feature in conflict, the list might look like this:

Conflicts (2/3)

   sde.RJP.ponds (1/2)



   sde.RJP.lakes (1/1)


This list indicates that there is a total of three conflicts as a result of the reconcile, and one of those three has been visited or replaced. The list also shows that 30 is the ObjectID of the conflicting feature that has been visited or replaced, and this feature is in the ponds feature class.

When you select an individual feature in the list, the columns and attributes in the prereconcile, conflict, and common ancestor versions of the feature appear in the list on the right of the Conflicts dialog box.

A red dot to the left of the field name identifies a conflict. For example, if the feature's geometry was edited in each version, a red dot appears next to the Shape field.

Using the Conflict dialog box

If other attribute fields are in conflict, a red dot appears next to them. If a feature has been deleted in either version, <deleted> appears for that version's attribute value.

Having the attributes and values for all representations of a feature in conflict allows you to see how the attribute values differ and helps you choose which representation of the data to preserve.

Viewing conflicts

If you click the Conflict Display button on the dialog box, two representations—the prereconcile and conflict versions—of the conflicting features are displayed at the bottom of the dialog box.

Using the conflict display window

Using the pull-down lists beneath each representation, you can toggle through three different representations of the conflicting features: Pre-Reconcile, Conflict, and Common Ancestor. Note that these will only look different if the features' geometries are in conflict.

Each representation has a toolbar below it that contains tools you can use to navigate and identify the corresponding representation.

You can zoom to a specific version of a conflicting feature on your map by right-clicking it in the list and clicking either Zoom To Pre-Reconcile Version, Zoom To Conflict Version, or Zoom To Common Ancestor Version.

If there are geometry conflicts, you can also see different representations on the map by right-clicking the Shape field in the list box and clicking Display.

Zooming to a conflicting feature

This will open the Conflict Display Settings dialog box. Click the representation you want drawn on the map.

Choosing conflict display settings

After you click OK, the following occurs on the map:

For the conflict display settings checked above, the following is an example of what would be displayed on the map:

Displaying the conflict versions

If only Draw current version is checked on the Conflict Display Settings dialog box, the following is an example of what would be displayed on the map:

Displaying the current version

After you have viewed the conflicts, you can mark them as visited or choose a replacement option to resolve the conflict.

Mark as Visited or Mark as not visited

As mentioned in the "Determining which fields or rows are in conflict" section, you can mark a feature as visited. This indicates that you have reviewed the conflict but do not want to choose a replacement option at this time. You can keep track of which features in the list you have reviewed because those marked as visited are no longer shown in bold.

If you decide you want to come back to a feature conflict later, you can right-click the ObjectID in the Conflicts list and click Mark as not visited. This causes the feature to be shown in bold again.

Resolving conflicts

Conflicts in geometric networks

When you edit network features, changes to the geometric network and to the logical network may create conflicts.

For example, when you add a service to a main, the main will not be physically split in the geometric network but will be split in the logical network. Therefore, while you have not directly edited the main's geometry, it has been edited logically. If the target version you are reconciling has also modified the main, the new service you inserted will create a conflict with the main.

Reviewing a conflict involving geometric network feature classes requires understanding how the Replace With command on the Conflicts dialog box updates the existing network topology present in the edit session.

In the service main example, two users modified the water main—one by changing an attribute and the other by connecting a new service. Reviewing the conflict merely requires investigating the differences and seeing that the conflict is valid, and no further action is required. Since the main contains the correct attribute for the diameter, the new service is correctly connected to the main. But there are cases when resolving conflicts involving a junction feature class also updates the connected network edge.

Conflicts in feature-linked annotation

Working with feature-linked annotation requires that you remember one rule: when replacing a feature that has feature-linked annotation, both the feature and the annotation are replaced with the new feature and annotation. Therefore, you may have to further edit the new annotation to avoid ending up with two annotations.

For example, you may encounter a conflict in which you have moved a feature and repositioned its annotation. The conflict version has performed the same edit, moving the feature and rotating the annotation. If you decide to replace the feature with the conflict version's feature, the existing feature-linked annotation is deleted, the conflict feature is inserted, and a new annotation is created. You will then need to edit the new annotation by moving and rotating it as necessary.

Or you might encounter a conflict in which another editor has deleted a feature in the DEFAULT version of the geodatabase, which also deletes its associated feature-linked annotation. In a child version of the geodatabase, you edit the annotation that was just deleted. When you reconcile, if you decide to replace the feature with the edit version, the feature that had been deleted in the DEFAULT version and its associated linked annotation will be replaced, and you will get the annotation from your edit session, thereby leaving you with two annotations for the same feature.

Conflicts in relationships

Relationships have dependencies similar to feature-linked annotation. Deleting a feature from an origin relationship class may trigger a message to delete a feature from the destination relationship class. Therefore, be aware of the ramifications of simply replacing conflicts involving feature classes that participate in relationship classes.

The following is an example of a conflict that can arise between relationship classes:

Another example is the following:

In this last example, if the second editor chose to replace all conflicts with the edit session representations, the pole and transformer deleted during your edit session will be re-created, and the transformer from the second editor's session will be created, thus leaving you with two transformers. You may not be able to detect this looking at the map, because the transformers will be one on top of the other; however, there will be two records for the transformer in the attribute table.

Conflicts in topologies

Because features in feature classes that participate in a topology can share geometry with other features, the process of reviewing conflicts between versions of topological feature classes is different from replacing conflicts with simple feature classes. It is also different from the process used to replace conflicts with geometric networks, relationship classes, and feature-linked annotation.

When a feature class that participates in a topology is edited, other topologically related features may be simultaneously changed. The changed features may belong to the same feature class or to one or more other feature classes. To manage the process of detecting new topology errors that may have been introduced by edits, topologies record where edits have been made as dirty areas. Editing features in a topology creates dirty areas in the topology.

New topology errors may occur when edited parent and child versions are reconciled, even when the dirty areas within each version have been validated and are free of errors. To detect such topology errors, the dirty areas in a child version are all returned to dirty status after changes from the parent version are brought into it during a reconcile. After the reconcile, these areas can be revalidated, and any errors will be detected.

Reconciling two versions that do not contain active dirty areas may still result in dirty areas. Any dirty area that has been present in the child version, whether it has been validated or not, will be a dirty area after the versions are reconciled. In general, when reconciling a version

Related Topics