Dirty areas and versioning of network datasets

Available with Network Analyst license.

A number of editors can simultaneously edit the source features of a network dataset stored in a workgroup or enterprise geodatabase. This topic and the various diagrams within it show what happens with dirty areas of network datasets when versions are reconciled.

There are a few main points to keep in mind before you begin working with network datasets in a workgroup or enterprise geodatabase; they include the following:

• Source features of a network dataset need to be registered as versioned before you can make any edits to them.

  Legacy:

  Prior to ArcGIS 10, network datasets could not be versioned. This meant that source feature classes could be edited as if they were simple feature classes. That is, the source feature classes could be registered as versioned and edited with the ability to undo and redo edits, or left as nonversioned data and edited without the ability to undo and redo edits.

  With the release of ArcGIS 10, however, you no longer have the ability to edit source features without registering them as versioned.

• When a network dataset is registered as versioned, schema changes cannot be made. You must unregister the network dataset as versioned before you can make schema changes. (Schema changes include adding or removing sources; changing connectivity rules, policies, or elevation settings; adding, removing, or changing attributes or attribute evaluators; and changing the settings of driving directions.)

• You can delete a network dataset irrespective of whether it is registered as versioned.

For completeness, the conceptual graphics in this topic show the entire process from creating the parent and the child, to reconciling and posting any edits and builds. Yet, you won't always start from the inception of a parent version, so you can think of any step where a child version is created as the moment when an existing child version and its parent share the same state.

Although the graphics show how to post a built network dataset to a parent version, it is perfectly valid to post the network with dirty areas. Note that in this case, however, you would probably want someone who has edit privileges with the parent version to eventually build the network dataset.

The following legend will help you understand the diagrams:

Reconciling and posting without source feature edits

This section describes how dirty areas behave in different versioning scenarios involving editing, building, reconciling, and posting network datasets. These scenarios exclude editing of the source features from the process (the next section includes editing). The purpose is to give you a basic understanding of which workflows result in built network datasets that are free of any dirty areas.

Scenario 1: Dirty area introduced and built in parent version

Assume the child version inherits a dirty area from the parent version. Next, the network dataset is built in the parent version. Finally, the child version performs a reconcile operation. The dirty area is removed in the child version (assuming no other edits were made).

Scenario 2: Dirty area introduced in parent version and built in child version

This scenario is similar to the last in that the child version inherits a dirty area from the parent version. Next, however, the network is built in the child version, not the parent. Reconciling after the build operation reintroduces the dirty areas from the parent. To post a built network to the parent, the child version needs to be rebuilt before posting.

Scenario 3: Dirty area introduced in parent version and built in both child and parent versions

This scenario is a combination of the last two. The child inherits the dirty areas from the parent version again. The child and the parent are built separately before reconciling. The reconcile process leaves the child in a clean state.

Reconciling and posting with source feature edits

The previous scenarios focused on building network datasets without editing source features. In the following scenarios, edits are made to source features, and the resulting dirty areas are removed.

Scenario 4: Editing different source features in the parent and child

The network is built before the child is created in this scenario. After the child is created, the streets source feature class is edited to add streets to the south side of the map. Meanwhile, the parent is edited to add streets to the north side. The two versions now have dirty areas at opposite ends of the map. The reconcile process transfers the edits and the associated dirty areas into the child version. There, the network is built so that it can be posted to the parent without any dirty areas.

Dive-in:

The network dataset in the diagram above wasn't built in either the parent or child versions immediately before reconciling. Yet, if it had been built in both versions at that time, reconciling would have reintroduced the dirty area on the south side of the map, as shown in the graphic below. The reason for this is the reconcile process makes the parent's state visible within the child version so that the merge process can occur. Since the child edits are new to the parent, the connectivity of those edits need to be rebuilt with the reconciled parent data.

Scenario 5: New source features that intersect across the parent and child versions

This scenario demonstrates another reason why the network dataset must be rebuilt after making edits to the child and parent source features. Here, the edits made in the parent and child versions intersect. Even though the network is clean in their respective versions, reconciling introduces a dirty area because the connectivity of the intersecting features still needs to be determined.