How are conflicts in topology, geometric networks, relationships, and feature-linked annotation handled?

Answer

Note:
This article pertains to ArcGIS versions 9.x and 10.0 only. Later versions of ArcGIS may contain different functionality, as well as different names and locations for menus, commands and geoprocessing tools.

There are several scenarios where conflicts can occur even when the attribute values are the same in each version. Conflicts occur when the same feature, topologically-related feature, or relationship is modified in two versions: the current version being edited and a target version.

There are two categories of conflicts:

• when the same feature has been updated in each version
• when the same feature has been updated in one version and deleted in the other.

Below are several scenarios where conflicts can occur within topology, relationships, or geometric networks where length and area values could be the same in each version. The descriptions are detailed below and may provide insight into why conflicts are occurring:

Conflicts in topology

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 primary and secondary 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 areas in a secondary version are all returned to dirty status after changes from the primary version are brought into it during a reconcile. After the reconcile, these areas can be revalidated and any errors 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 secondary version, whether it has been validated or not, is a dirty area after the versions are reconciled. In general, when reconciling a version:

• Any dirty area the secondary version inherited from the primary version, whether it is validated in the secondary version or not, is a dirty area after the reconcile.
• Any dirty area that was created due to a feature that was created, updated, or deleted in the secondary version, whether it is validated or not, is a dirty area after the reconcile.

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.

As an example of when a conflict can arise between relationship classes:

1. Update the Origin Class Primary field, breaking the relationship in version A.
2. At the same time, update the destination class-related feature in version B.

Since the destination class is dependent on the origin class, a conflict is detected when reconciling the versions.

Another scenario:

During an edit session in the electric utilities feature dataset, a pole is deleted that has a composite relationship to a transformer causing the related transformer to be deleted.

At the same time, in another edit session, a second editor updates the attributes of the same transformer that had just been deleted in the previous edit session by deleting its related pole.

When the edits are reconciled, an update-delete conflict is detected.

In this example, if the second editor choses to replace all conflicts with the edit session representations, the pole and transformer deleted during the edit session is re-created and the transformer from the second editor's session is created, resulting in two transformers. This may not be apparent by looking at the map, because the transformers are one on top of the other; however, there are two records for the transformer in the attribute table.

Conflicts in geometric networks

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

For example, when adding a service to a main, the main is not physically split in the geometric network but is split in the logical network. Therefore, while the main's geometry has not been directly edited, it has been edited logically. If the target version being reconciled has also modified the main, the new service inserted creates a conflict with the main.

Reviewing a conflict involving geometric network feature classes requires understanding how the Replace With command in the Conflict Resolution 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 remembering 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, further editing of the new annotation may be required, or it results in having two annotations.

For example, a conflict may be encountered in which a feature has been moved and its annotation has been repositioned. The conflict version has performed the same edit: moving the feature and rotating the annotation. If the feature is replaced with the conflict version's feature, the existing feature-linked annotation is deleted, the conflict feature is inserted, and a new annotation is created. Then, the new annotation needs to be edited by moving and rotating it as necessary.

Or a conflict may be encountered 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 secondary version of the geodatabase, the annotation that was just deleted is edited. When reconciling, if the feature is replaced with the edit version, the feature that had been deleted in the DEFAULT version and its associated linked annotation is replaced. Plus, the annotation from the edit session is returned, thereby leaving two annotations for the same feature.

Deleting, modifying, or adding a feature in a version before a reconcile may generate a conflict with another version where this feature exists.