FAQ: Why is a reconcile conflict not raised when merging splits to a simple edge feature?
Why is a reconcile conflict not raised when merging splits to a simple edge feature?
When a simple edge feature in a geometric network is intersected by another feature, it is replaced by two new edges that are connected at the point of intersection. This is normal behavior, but under certain circumstances it can lead to unintended results if the data is stored in a versioned geodatabase. For example, two users may be editing the same network feature class in ArcMap but in different versions. They split the same simple edge feature by adding a junction to it. Afterwards, they attempt to merge their edits by reconciling and posting their versions to a common parent version.
One might expect that since their edits were performed on the same edge feature, a reconcile conflict would be raised when the second editor reconciles their version. However, for reasons explained below, a reconcile conflict does not occur in this scenario. One might also expect that when the edits are merged, the original edge is replaced by three colinear features joined at the two junctions. This appears to be the case. However, the actual result is a series of overlapping edges that form a closed loop.
To better understand why this is happening, consider the following example. The two simple edge features displayed below in Figure 1 are labeled with their ObjectID values. Split the edge with ObjectID = 400 with junction features at two different locations. Each split is performed in separate edit versions, named Version1 and Version2. Afterward, merge the edits in those versions by reconciling and posting them to their common parent and examine the result.
Figure 1. The original unedited feature with ObjectID = 400.
First, switch to Version1 and split the edge with a node. Note that the original feature with ObjectID = 400 is now replaced by two new features having ObjectID's of 409 and 410.
Figure 2. The result of the edit performed in Version1.
Next switch to Version2, which still has the original edge with ObjectID = 400, and split that edge at another location. Note that the original feature has been replaced in Version2 with two new features having ObjectID's of 411 and 412.
Figure 3. The result of the edit performed in Version2.
Now merge the edits in Version1 and Version2 by reconciling and posting them to their common parent version. The result is displayed in Figure 4. It may appear as though the original feature with ObjectID = 400 was replaced by three new edges that are connected at the two junctions; however, look again at the labels. They indicate that there are four features instead of three.
Figure 4. The result of merging the edits in Version1 and Version2.
To better understand how the four features overlap one another, compare Figure 2 and Figure 3. The four new features resulting from the splits in both versions are preserved when those edits are merged together. So the edge in Figure 2 with ObjectID = 410 completely overlaps the edge with ObjectID = 412 in Figure 3, and partially overlaps the edge with ObjectID = 411. Conversely, the edge with ObjectID = 411 in Figure 2 completely overlaps the edge with ObjectID = 409 and partially overlaps the edge with ObjectID = 410.
While this result is probably not what was intended and is generally undesirable, it is to be expected for this and similar workflows. To avoid this, verify that all of the geometry edits to be performed on given simple edge feature are performed within a single version. Do not attempt to merge multiple geometry edits to a simple edge feature through the reconcile and post procedures.