One of the primary reasons organizations adopt enterprise geodatabase technology is to take advantage of versioned editing. This is a form of editing that makes it possible to perform edits in isolation from the main version of the feature class. After a group of edits has been completed in the edit version, and perhaps run through a quality check, it can be incorporated into the main version. In Lesson 8 you'll see how versioned editing is conducted using Esri tools.

Questions?

If you have any questions now or at any point during this week, please feel free to post them to the Lesson 8 Discussion Forum.

Lesson 8 is one week in length. See the Canvas Calendar for specific due dates. To finish this lesson, you must complete the activities listed below. You may find it useful to print this page out first so that you can follow along with the directions.

1. Download the Lesson 8 data *.
2. Work through Lesson 8.
3. Complete the versioned editing workflow project described on the last page of the lesson.
4. Take Quiz 8.

* - Data acquired from the National Historic GIS (www.nhgis.org), Minnesota Population Center. National Historical Geographic Information System: Version 2.0. Minneapolis, MN: University of Minnesota 2011.

In the last lesson, you digitized streets from a set of Sanborn maps. Perhaps without realizing it, you were performing non-versioned editing. This editing model, also sometimes called the short transaction model, is typical of traditional non-spatial database systems and has the advantage of being simple to implement. It can be preferable to versioned editing in situations where it is important for edits to be available to users immediately or if the data is frequently accessed by non-Esri applications.

However, non-versioned editing has a longer list of limitations and disadvantages that often makes versioned editing the more logical choice. Among these are:

• inability to undo/redo individual edits. This is an even bigger problem in ArcGIS Pro versus ArcMap. In ArcMap, because it employs the concept of an editing session, it is possible to quit out of an editing session without saving, but you lose all edits made since the last save. For example, if you make 9 good edits and make a mistake on the 10th, you either need to end the edit session without saving (and lose all 10 edits) or accept the mistake and go back and correct it. A workaround for this is to save edits frequently. ArcGIS Pro, on the other hand, does not employ editing sessions. Thus, if you make a mistake editing a non-versioned feature class in Pro, you have no way to roll back that edit. You'll have no choice but to correct the error yourself.
• inability to edit complex data (e.g., feature classes participating in a topology or geometric network). Only simple features can be edited.
• locking of features being edited. If a second user attempts to edit the same feature, ArcGIS desktop software will become unresponsive.
• no mechanism for resolving conflicts when multiple users edit the same feature. Non-versioned editing is a "last save wins" environment.

The versioned editing, or long transaction, model addresses all of these issues. Editors of a versioned feature class are able to undo/redo individual edits and can perform edits on either simple or complex data. Different editors can perform edits to the same features because, as the name implies, all of the editors are working off of their own version of the data. As we'll see, mechanisms exist for merging changes made in different versions and resolving conflicts when they crop up.

As you might guess, versioned editing is especially useful for organizations that make frequent and/or complicated edits to their data. Land parcels are a classic example in that they are in a constant state of flux and require a great deal of care to delineate properly.

Versioned editing relies on the usage of delta tables (tables that track changes made to the base feature class). One good reason to avoid using a versioned editing workflow is that non-Esri applications are not built to work with the data in these delta tables. If your organization uses non-Esri tools to access your data, you may need to develop workarounds or live with the limitations of non-versioned editing.

With these introductory notes behind us, let's take a look at how versioned editing works.

Throughout this lesson, we'll use a feature class that stores the boundaries of the United States at the time of its first decennial census in 1790. We'll make edits to this feature class that reflect changes in the state boundaries as new states were admitted to the union.

A. Transferring data from your computer to your Amazon instance

Again, you are going to transfer some data from your machine to your Amazon enterprise geodatabase instance. This time, it will be the US_state_1790 shapefile dataset that you download from the Checklist page.

1. Start your instance using the AWS Console.
2. Open a Remote Desktop Connection to your instance. In doing so, make certain that the box for Drives is checked via Options > Local Resources > More button.
3. In your remote desktop connection window, open File Explorer. (Start button > All Programs > Windows System > File Explorer) and, as a reminder, click This PC to display the drives that are attached to the Windows operating system.
   Under Devices and drives, you should see listed a set of drives (C and D) for your EC2 instance, and you should see the drives that are on your own local computer.
   
   You are going to Copy-Paste a shapefile dataset from your computer to the data folder on the Local Disk (D:) drive on your instance. You might want to open a second File Explorer window.
4. Note the two alternatives to this step:
   Browse to the folder on your local computer that contains the US_state_1790 shapefile dataset. Highlight all of the files comprising the shapefile datasets, and click Copy.
   Alternatively, you could highlight the single nhgis0001_shapefile_us_state_1790.zip file (remembering to uncompress it after the transfer).
5. Browse to within the D:/data drive and Paste the shapefile dataset there. If you uploaded the .zip archive, be sure to extract its contents.

B. Register a feature class as versioned

First, you will import the shapefile to your enterprise geodatabase as a feature class, then you'll perform the registration. Throughout this lesson, we'll use the census and Moe users established back in Lesson 6. In an actual implementation of a project like this, you would likely want to load the data via a loader user (like census) and then grant editing privileges to two non-loader users; but for simplicity's sake, we'll just grant editing privileges to Moe and use census as the second editor.

1. In the remote connection window to your instance, open ArcGIS Pro and via the Catalog pane import the US_state_1790 shapefile through the census_egdb connection.
   Note: You are not importing to a feature dataset; right-click on the census_edgb connection and choose Import > Feature Class.
   • For the Output Feature Class, assign a name of us_state_1790.
     
     We're really only interested in storing the state names in this simple scenario, so we'll not import the rest of the non-essential attribute fields. Do the following.
   • In the Field Map area of the dialog, one at a time, select each field except STATENAM, SHAPE_AREA and SHAPE_LEN, and click the X button to remove the selected field from the field map.
   • Click Run to carry out the import. The new feature class will be added to the current map when the import is complete. The layer name should be egdb.CENSUS.US_state_1790.
2. Recalling the steps that should be completed after a new feature class is added to a geodatabase, let's perform an Analyze on it and assign the desired access privileges.
   Run the Analyze Datasets tool on the new feature class (ArcToolbox > Data Management Tools > Geodatabase Administration).
3. We want the Moe user to have the ability to edit this feature class too, so let's set up that privilege.
   Using the Change Privileges tool, grant both view and edit privileges to the us_state_1790 feature class for the user Moe.
4. Now, right-click on egdb.CENSUS.us_state_1790 in the Catalog pane, and select Manage > Register As Versioned.
   • Leave the "Register the selected objects with the option to move edits to base" box unchecked and
   • click OK.

The feature class is now ready for versioned editing. The decision on whether to use a versioned editing workflow is made at the feature class level unless the feature class is part of a feature dataset. In that case, you would register the feature dataset as versioned, and that setting would cascade to all of its feature classes. Note that the setting applies only to feature classes in the feature dataset at that time. If you later add a new feature class to the feature dataset, you'll need to re-execute the Register As Versioned command. Further details in this Tech Support article.

In our scenario, users logged in as census and as Moe are sharing the responsibility for editing the feature class to reflect when states joined the Union. As the project progresses, snapshots at different moments in time can be taken to produce an historical timeline of the country's expansion.

You will simulate these two users performing their edits by launching a separate ArcGIS Pro application window for each. The users want to isolate their work from the base feature class, so they will create their own versions of the feature class.

A. Perform edits as census user

1. In your already open ArcGIS Pro window in your remote connection, in the Display pane, click the List By Data Source button (second from the left). Above the layer name, you should see a heading indicating that you're viewing the DEFAULT version of the feature class.
2. Right-click on this heading and select Manage Versions. A Versions view should appear alongside the Map view, showing that there is currently only one version: DEFAULT.
3. Click the New Version button on the ribbon. A new row will be added to the versions table.
   • Assign the version a Name of Statehood_edits
   • Enter the following Description for the version: census user's statehood edits version
     
     ​The Access options are used to specify who has access to the new version. The Private option means that only the user creating the version will be able to view and edit the version. The Public option means that the version owner and any other database user will be able to view and edit the version. Finally, the Protected option gives other database users the ability to view data through the new version but not perform any edits on it.
      
   • Select the Protected option.
   • Click the Save button on the ribbon to finish creation of this new version.
   • Close the Versions view.
4. Back in the Display pane, right-click on the data source heading above the egdb.CENSUS.us_state_1790 layer again, and this time select Change Version. In the Change Version dialog, you should see that dbo.DEFAULT is the currently active version, but you should also see CENSUS.Statehood_edits listed as a child version of dbo.DEFAULT.
5. Select that Statehood_edits version and click OK. You should see the data source heading in the Display pane change accordingly.
   
   Vermont was the first state after the original 13 to join the Union (in 1791). Its boundaries were already defined as the land between New York and New Hampshire, so no boundary edits are necessary to create it.
   
   The next state to join was Kentucky (in 1792) which was formed from the western part of Virginia. To create Kentucky, we're going to overlay the states layer we worked with earlier in the course and use the present-day boundaries as a guide. If you were carrying out a project like this in a serious manner, you'd probably want to make sure the two layers aligned better than these do, but we're not going to get bogged down in a detail like that in this demo.
   
   Note: Rather than adding and symbolizing the states feature class in the next couple of steps, you can also use the Topographic layer that's automatically added to your Pro project from ArcGIS Online since it also shows the present-day Virginia-Kentucky boundary.
6. To the map, add the states feature class from the egdb.CENSUS.usa_L7 feature dataset that you created back in Lesson 7.
7. Change the symbology of the states layer so that the polygons are hollow and have an outline color that stands out (e.g., red).
8. Change the symbology of the us_state_1790 layer so that it has thick outlines (width = 2). With the states layer drawn on top of the us_state_1790 layer, you should now have a good view of how the states and territories of 1790 were carved up into the states we know today.
9. Zoom in on present-day Kentucky's eastern boundary.
   
   Turn on the labels for the layers if you wish. They ought to default to the fields with the state/territory names in them.
   You may want to close or hide the Catalog pane to increase the size of the map display area.
   
   We're about to add a sketch along that eastern boundary to divide the 1790 Virginia polygon into two pieces, shrinking Virginia and creating Kentucky. The accuracy of this edit has nothing to do with the lesson objective, so I encourage you to be as quick-and-dirty as you like especially given the slow performance you'll encounter.
   
   Speaking of which, let's turn off snapping, as it's likely to only hinder our efforts.
10. Click the Edit tab, from the Snapping menu, toggle off all snapping.
11. The easiest way to perform this edit will be to use the Split Tool. Using this tool requires that we first select the polygon we want to cut.
    
    Turn off the display of the (present-day) states layer for just a moment.
12. Use the Select tool to select the 1790 Virginia polygon.
13. Turn the states layer back on. I instructed you to turn it off to avoid selecting features in that layer.
14. In the Tools button group, activate the Split tool (icon is a line drawn on top of a rectangular polygon). You may need to scroll down through the editing tools to find it.
    
    Read through the next two steps, so you know what you are about to do.
15. Begin your sketch just to the south of where present-day Kentucky, Virginia, and Tennessee come together and add just a few vertices to create a very rough version of Kentucky's eastern border. To make it easier to differentiate this edit from Moe's coming later, do a particularly sloppy job on this edit. The figure below shows how your sketch might look just prior to completion.
    
    
     
16. To finish the sketch line, double-click just to the north of where present-day Kentucky, Ohio, and West Virginia come together. It may take a few seconds for the result to appear. Your sketch should produce a smaller Virginia polygon and a new Kentucky polygon, and both should be selected.
17. Now, click the Attributes button to bring up the attributes of the selected features.
18. Click on each of the feature entries labeled Virginia at the top of the Attributes dialog, and watch the map to determine which one is actually Kentucky (the western-most of the two new polygons).
    Note, too, that the name Virginia has been inherited in the STATENAM field for the two new features.
19. Enter Kentucky as the STATENAM value for the correct feature and click Apply.
20. Save the edit you just made to the Statehood_edits version by clicking the Save button under the Edit tab.
21. Save your overall ArcGIS Pro work to a new project named census.aprx - in the Save dialog, be sure to navigate to the Local Disk (D:) drive and save into the data folder.
22. Close ArcGIS Pro.

B. Perform edits as Moe user

Now you'll play the role of the Moe user. In our scenario, imagine that the census and Moe users didn't coordinate their work very well and Moe thought that creating Kentucky was his responsibility.

1. Re-open ArcGIS Pro to a new project.
2. In the Catalog pane, open your Moe_egdb connection.
3. Drag and drop the us_state_1790 feature class onto the map. Note that Virginia appears in its unaltered 1790 state (i.e., Kentucky does not yet exist). This is because census's changes were isolated from the base us_state_1790 feature class in a separate version. As Moe, you'll now create another new version to isolate Moe's edits from the base feature class.
4. Following the same procedure outlined above for the census user, create a new version for Moe with these settings:
   • Name: Statehood_changes
   • Owner: Moe
   • Parent Version: dbo.DEFAULT
   • Description: Moe user's statehood changes version
   • Access: Protected
5. Change to this new version, again following the same procedure you used above.
6. Now, follow the same Split tool steps you went through as census to create Kentucky from the western part of Virginia.  Sketch the boundary a bit more accurately, though don't go overboard. Just enough that you'll be able to tell at a glance that it differs from the census user's version.
7. In addition, our confused Moe is under the impression that the feature class should contain only states (no territories).
   
   Delete the Northwest Territory (present-day Ohio, Indiana, Illinois, Michigan, and Wisconsin) and the Southwest Territory (present-day Tennessee) polygon features.
8. Save your edits to Moe's Statehood_changes version.
9. Save your work to a new project called Moe.aprx and close ArcGIS Pro.

C. How version edits are stored

Now, let's take a look at how the edits you just made are stored in the geodatabase.

1. Open SQL Server Management Studio.
2. Navigate to the tables in the egdb database (Databases > egdb > Tables).
3. Open the SDE_table_registry table -- to do so, you'll need to right-click and choose Select Top 1000 Rows from the context menu -- and find the row for the us_state_1790 table. Make a note of the registration_id for that table. Mine is likely to be different from yours, so I can't say what it should be for you.
   
   Close the table.
4. Now, in the egdb Tables listing, locate the 'a#' table and 'D#' table associated with us_state_1790:
   If the registration_id you found in the previous step was 11, for example, the two tables would be named census.a11 and census.D11, respectively. These are the delta tables that were mentioned back in the Introduction.
   
   The 'a#' table stores features that have been added to the base feature class and the 'D#' table stores features that have been deleted. Why no 'e' table (for edits) you may ask? Features that are edited result in a new row in the 'D' table (recording the deletion of the original feature) and a new row in the 'a' table (recording the new state of the feature — we get to a discussion below regarding 'state').
5. Open the census.US_STATE_1790 table and note the OBJECTIDs of Virginia (6), Southwest Territory (11) and Northwest Territory (15).
6. Now, open the 'D#' table and note that it includes rows recording the deletions of the Southwest and Northwest Territories. It also includes two rows associated with deletion of the old version of Virginia (one by each user).
7. Open the 'a#' table, and note that it includes two pairs of Kentucky/Virginia additions (again, one by each user). The Virginia polygons are the new shapes to replace its old shapes.

When asked to display a version, Esri's software is programmed to start with the parent DEFAULT version of the feature class and incorporate the changes recorded in the delta tables. This process relies on the concept of a feature class state. Every edit made to a feature class version produces a new state with states being tracked using sequential ID values. For example, the first edit to a new version will produce state #1.

The SDE_versions table stores the names and IDs for all of the geodatabase’s versions. It is there that you’ll find the Statehood_edits and Statehood_changes versions created earlier. Other tables used in conjunction with the delta tables to track feature class changes are SDE_states and SDE_state_lineages. The details of how this process works are a bit complicated, so we won’t dig into them. If you’re curious to learn more, you can read through Esri’s Geodatabase system tables in SQL Server documentation page.

D. Switching to another version

It is sometimes necessary to switch the version of the feature class you're currently viewing to some other version you have permission to view. For example, the census user would be able to switch to the DEFAULT version or to the Statehood_changes version (created by Moe). We already saw how to change to a new version immediately after creating it, but let's drive home the point that the version can be changed later as well.

1. Back in your remote connection window, re-open your census.aprx project.
2. Click on the List By Source button in the Display pane. You should see that the us_state_1790 layer is now listed under a heading that says Statehood_edits, indicating that you're viewing that version of the feature class.
3. Right-click on that heading and select Change Version.
4. In the Change Version dialog, select the DEFAULT version and click OK. Your map should change to no longer show Kentucky as part of the us_states_1790 layer, since that change is part of the Statehood_edits version and has not been propagated to the DEFAULT version yet.
   
   You could also switch to the Statehood_changes version, though you would not be able to perform edits on that version since it is owned by Moe and had its permissions set to Protected.
5. Switch back to the Statehood_edits version before moving on.

E. Viewing version differences

A useful way to inspect changes that exist between two feature class versions is to open the Version Changes view.

1. Click on the Statehood_edits heading in the Display pane again. You should see a Versioning tab appear in the ribbon along the top of the application.
2. Click on the Versioning tab, then on the Version Changes button. This will open a new view labeled Differences alongside the Map view.
   
   Under the Target Version tab, you'll see DEFAULT listed, since that is the parent version to Statehood_edits.
3. Click on the Differences tab. You should see an egdb.census.us_state_1790 heading with 2 in parentheses (indicating the number of differences between the Statehood_edits version and its parent DEFAULT version.
4. Expand the listing beneath that heading. Version differences are broken down into Insert, Update, and Delete (in this case, just Insert and Update).
5. Expand the Insert listing, then click on the one item that appears in the list (representing Kentucky).
   To the right, you should see a column listing properties (attributes), a column that displays the feature's attribute values according to the Current (Statehood_edits) version, and a column that displays the attribute values according to the Target (DEFAULT) version (in this case blank, since this is a feature that's not present in DEFAULT).
6. Expand the Update listing, then click on the one item that appears in the list. To the right, you should see that the feature with an OBJECTID of 6 in both the Current and Target versions was updated. (This is the Virginia feature.)
7. Close the Differences view.
8. Save your census.aprx project and close ArcGIS Pro.

At some point, you'll want to merge the changes you've made in your isolated version with the base feature class, perhaps after performing a QA/QC check. That's the topic of the next section.

Credit for all screenshots: © Penn State is licensed under CC BY-NC-SA 4.0

When a feature class is registered as versioned, the dbo superuser is made owner of the DEFAULT version, and permission to work with that version is set to Public. The Public permission setting means that any other user can both view and edit the DEFAULT version. This type of permission may not be ideal, though, particularly if you want to avoid mistaken edits from being propagated to the base feature class. One way to safeguard against this happening is to set permission on the DEFAULT version to Protected. This allows anyone to create their own child versions based on DEFAULT, but only the dbo user can post changes to the DEFAULT version.

A. Changing permissions on the DEFAULT version

As the dbo user is the owner of the DEFAULT version, only the dbo user can change permission on that version. So the first step we'll need to take to alter permissions is to open up a connection through the dbo user.

1. In a remote desktop connection to your instance, open ArcGIS Pro to a new project.
2. Create a new connection to the database through the dbo user called dbo_egdb. (Recall, this is done using Operating system authentication.)
3. Through the dbo_egdb connection, add the us_state_1790 feature class to the map. You should be viewing the feature class through its DEFAULT version, which you can confirm by clicking the List By Source button in the Display pane.
4. Right-click on the dbo.DEFAULT heading above the us_state_1790 layer entry and select Manage Versions. Each of the three versions of the us_state_1790 feature class should be listed.
5. Select the DEFAULT version, and note that the Access on the DEFAULT version is set to Public.
6. Change the Access from Public to Protected.
7. Save the change you just made.
8. Close the Versions view.

B. Reconciling and posting the census user's changes

Synchronizing the changes between two versions of the same feature class requires the passing of edits in two directions. These transfers happen through operations called reconcile and post:

• reconcile - edits that exist in the parent version but not the child version get transferred from the parent to the child
• post - edits that exist in the child version but not the parent version get transferred from the child to the parent

Both reconcile and post operations must be carried out while viewing the child version.

1. Click on the DEFAULT heading in the Display pane to highlight/select it.
2. Click the Change Version button under the Versioning tab and select the Statehood_edits version.
   Click OK. You should see the Virginia/Kentucky split in this version.
3. Click the Reconcile button under the Versioning tab. In the Reconcile dialog, you should see that DEFAULT is already selected as the Target Version. You are also presented with questions on how you want to deal with conflicts between the two versions. A conflict occurs when the same feature has been updated in both the edit and target versions.
   
   The first of these questions asks whether you want to resolve conflicts in favor of the target version or the edit version. Let's stick with the default (in favor of the edit version). If conflicts are found, we'll have an opportunity to review them and settle the conflict however we like anyway.
   
   The second question asks whether you want to define conflicts by object/row or by attribute/column. Let's go with by object. The by column option might be used in a situation in which one user was responsible for making geometry edits and another user for attribute edits.
4. Click OK to initiate the Reconcile between the Statehood_edits and DEFAULT versions. In this case, no changes will be transferred from DEFAULT to Statehood_edits since DEFAULT has not changed since Statehood_edits was first created.
   
   After the Reconcile is complete, the Post button (on the ribbon next to Reconcile) is enabled.
5. Click the Post button. The Post button will become disabled when the process is complete. The edits that were made to the Statehood_edits version (the Kentucky-Virginia split) will be transferred to DEFAULT. (You could confirm this by switching back to the DEFAULT version.)
   
   You'll now perform a reconcile and a post between Moe's edits (stored in the Statehood_changes version) and DEFAULT.

C. Reconciling and posting Moe's changes

1. Again, click on the version heading above the layer's entry in the Display pane.
2. Click the Change Version button on the ribbon under the Versioning tab.
3. In the Change Version dialog, switch to the Statehood_changes version, and click OK.
   
   When the Statehood_changes version is mapped, you should see the Northwest and Southwest Territories disappear (they were deleted in this version) and a more accurate eastern boundary for Kentucky.
4. Click Reconcile, and as you did above, choose to resolve conflicts in favor of the edit version and by object. Click OK to initiate the reconcile process.
   In this case, the Reconcile operation will find changes to transfer from DEFAULT to the Statehood_changes version, since DEFAULT was just updated with edits made by the census user.
   
   As the software attempts to transfer those changes to the Statehood_changes version, you'll see that it detects conflicts.
5. In the Reconcile dialog, click Yes to review the conflicts.
   
   Note that a similar view to what we experimented with earlier appears, with a list of conflicts on the left and a table providing data such as shape area/length for the two conflicting versions of the object on the right. In the bottom of the view, a Conflict Display can be expanded to display the selected conflicting geometries in map form.
   
   There is a single conflict in this case — Update-Update (1).
6. Expand the Update-Update list, and click on the feature ID of 6.
   Note that the conflicting properties (in this case, the Shape) are shown with red highlighting.
   
   The dialog shows Property values for four different representations of the conflicting feature:
   • Current- this is how the feature is currently going to be resolved. If you chose to resolve in favor of the edit version, the values in this column will be the same as those in the next column.
   • Pre-Reconcile - this is how the feature is stored in the edit version (i.e., as it was drawn by Moe).
   • Target- this is how the feature is stored in the DEFAULT version.
   • Common Ancestor - this is how the feature looked before any edits were made.
7. If you haven't already done so, expand the Conflict Display. After a moment, you'll see a side-by-side comparison of the Current and Target representations. One could use the tools beneath each map to inspect each representation in an attempt to decide how to resolve the conflict.
8. Moe created the Virginia/Kentucky boundary more carefully, so we want to accept his edit.
   
   Back in the table that lists which properties have conflicts, right-click on the Shape Property and note there are options for replacing the value of the Shape attribute with the Pre-Reconcile version, the Target version, or the Common Ancestor version. There is also a "split the difference" option (Merge Geometries).
   
   Select the Replace With Pre-Reconcile Version option. (There will be no noticeable change in the Conflicts view.)
   
   Close the Conflicts view.
   
   If there were more Conflicts (1/X), you would navigate to the next one and repeat the review process. In this case, there was only one so we can close the Conflicts view.
   
   Looking again at the map, you'll probably notice a problem. There are now two Virginia/Kentucky boundaries appearing -- one from each of the editors. There's actually an explanation for what's happened here. We just reconciled Moe's version against the DEFAULT version -- i.e., said to transfer features from DEFAULT to Moe's version. The Virginia polygon appeared in the Conflicts view because that feature (having OBJECTID of 6 in both versions) was different. We said to go with Moe's version of Virginia, and if you have Virginia selected you should see that the selection symbol follows Moe's boundary, not the census user's. But what's happened is the census user's Kentucky polygon has been added to Moe's version because Moe's Kentucky feature has a different OBJECTID than the census user's (418 vs. 18 when I went through this process). Ideally, we would have seen the Kentucky polygons in the conflict list as well, but we couldn't because the conflict detection algorithm compares geometries that share the same OBJECTID.
   
   Why did the two Kentucky features have different OBJECTIDs? Well, if you think this through, there's not really any way for the software to know that the two editors were creating the same new feature. OBJECTID is the primary key in the us_state_1790 table, so all new features are given a unique OBJECTID value.
   
   So, we'll need to clean up this unwanted Kentucky feature before Posting changes to DEFAULT.
9. Open the us_state_1790 attribute table and scroll to the bottom. You should see the two Kentucky features.
10. Select the features one at a time until you've determined which is the unwanted one.
11. With that feature selected, hit the Delete key on your keyboard.
    
    With that unwanted Kentucky removed, you're now ready to post Moe's changes to DEFAULT.
12. Return to the Versioning tab and click the Post button.
    
    The two territories that were part of the original feature class (in the DEFAULT version) have now been removed as a result of this post. And the Kentucky and Virginia features that had been posted to DEFAULT by the census user have been replaced by Moe's.
    
    Note: In a scenario like this, setting up topology rules (e.g., no overlapping polygons) in addition to using versioning might be needed to avoid problems!

D. Reconcile census user's version against DEFAULT again

To summarize, in Part B, you performed a reconcile and a post between the census user's version and DEFAULT. Then, in Part C, you performed a reconcile and a post between Moe's version and DEFAULT. In Part C, edits made by census have been propagated to Moe's version -- and were rejected -- by virtue of the fact that census had just posted changes to DEFAULT. However, at this point, the changes that were made by Moe have not been propagated to the census user's version. To do that, the census user would need to (a) do another reconcile, or (b) delete the Statehood_edits version and re-create it.
Let's go with option a.

1. Switch the feature class version again to Statehood_edits.
2. Perform a Reconcile. Because we now know that the DEFAULT version contains the desired geometries, choose to resolve conflicts in favor of the target version. You should see that all of the edits that were made in Moe's version are now propagated to the census user's version. There is no need to do a Post at this point, since there are no edits that weren't already posted in Part B.
3. Save your edits.

A few final points on versioned editing:

• You might find it worthwhile to go through a similar "two users performing the same edit" exercise, but simply editing existing features. For example, you might turn on Map Topology as discussed in Lesson 5, and make further edits to the Kentucky-Virginia boundary, moving some of the vertices to alter the shapes of both polygons. Then go through the Reconcile-Post process and resolve the conflicts however you see fit. You'll find that because your modifications involve only existing features, the conflict resolution process will go more smoothly, not requiring the sort of "manual intervention" we went through with our splitting Virginia exercise.
• That said, even if the Reconcile-Post process went smoothly for all editing scenarios, it's still recommended that you try to avoid having to resolve conflicting edits altogether by setting up clearly divided areas of responsibility for the various members of your editing team.
• If you do incorporate versioned editing into your workflow, note that the size of the delta tables can have a significant impact on performance (e.g., feature drawing and querying). For this reason, it is important to regularly compress the database (the Compress tool is documented at Compress (Data Management) [https://pro.arcgis.com/en/pro-app/tool-reference/data-management/compress.htm]) and update the database statistics as discussed in the previous lesson. Further information on versioned editing workflows can be found in this Esri white paper: Versioning Flows [http://downloads.esri.com/support/whitepapers/ao_/Versioning_Workflows_2.pdf].

Through this short tutorial, you've seen how an organization can carry out edits to its data in a way that balances the need for preserving data integrity with the need to keep the data as up-to-date as possible.

Move on to the next page to access the graded activity for this lesson.

Credit for all screenshots: © Penn State is licensed under CC BY-NC-SA 4.0

A. Project Overview

In the last project, you digitized streets in Charlottesville, VA circa 1920 using a set of Sanborn maps. For Project 8, I’d like you to return to the Sanborn map scenario. Imagine that you've been tasked with leading a team of four editors in capturing the building footprints found on Sanborn maps for a different point in time (say 1950). Your job for Project 8 is to draft a workflow that outlines how you and your team will digitize the building features using versioned editing. Describe how you would lead the development of this 1950 buildings feature class as the dbo superuser. Include in your workflow all of the steps you would follow from the initial creation of the feature class to the incorporation of each editor’s work into the final product. Assume that there are 30 individual scanned map sheets, like the four you saw in Lesson 7, and that your company has told the client that it will take a total of 2000 person-hours to perform the digitizing and to compile the attribute data from all 30 maps. In other words, each editor will have to engage in multiple data-entry sessions.

Note: Recall that you were given the 1920 building footprints in shapefile format for Project 7. You may assume that this dataset is available to you in Project 8 as well.

B. Deliverables

This project is one week in length. Please refer to the Canvas Calendar for the due date.

1. Submit a workflow that includes all of the steps you see as necessary to complete the described project. Your submission will be graded as follows:
   • Quality of workflow: 70 of 100 points
   • Quality of write-up, in terms of grammar, spelling, and flow: 30 of 100 points
2. Complete the Lesson 8 quiz.