Implementing a geodatabase for local government, Part 2

Preparing the geodatabase for data editing

Recall from the previous module that Sue, a GIS consultant from OMH Inc., is in the process of implementing a pilot geodatabase for the city of Rome (fictional city) in southern California. The city wants to migrate its GIS and CAD data to the geodatabase data model so that multiple departments can more easily share common data and so the city will be able to minimize costs related to maintaining and storing duplicate spatial datasets.

At this point in the project, Sue has determined the spatial references for the data that will be stored in the pilot personal geodatabase. Initially, she had planned to create one personal geodatabase with separate feature datasets for each of the participating city departments. She is now considering additional database design issues:

• Certain datasets should be organized based on their topological relationships to other datasets. For example, changes to the polygon features in the city boundaries layer may affect the geometry of certain features in the zoning and subdivisions layers. But having all department datasets participate in the same topology may not be wise, as making edits to one feature class can affect all other feature classes in the topology. In some cases, the department may not want edits made to all feature classes.
• The organizational structure represented by the city departments is important, however. It is preferable that certain departments have sole responsibility for maintaining certain datasets, and other departments should be able to access, but not edit, that data. For example, the Planning Department is responsible for the city boundaries, subdivisions, and zoning layers, while Public Works is responsible for the water and sewer system layers.

Sue could go forward with her plan to store all the data needed for the pilot project in one personal geodatabase, organizing topologically associated data into several feature datasets and creating common, standalone basemap feature classes and nonspatial tables. However, only one person at a time can edit data stored in a personal geodatabase, which could negatively impact the normal workflow of the Planning and Public Works departments. It is also possible that the required data might exceed the personal geodatabase size limitation (2 gigabytes).

If only one department is using a personal geodatabase, edit access can be limited to specific staff. If more than one department has edit access to a single personal geodatabase, conficts are more likely.

If Sue were going to implement a multiuser geodatabase for the pilot project, the size of the geodatabase would not be an issue. She could also set permissions to different parts of the geodatabase so that each department had edit access only to the feature classes and feature datasets for which they were responsible.

With a multiuser geodatabase, she could create versions of the geodatabase which department staff could check out, edit, then check back in. If editing conflicts arose, each user or an ArcSDE® administrative user would reconcile any differences in the versioned edits back into the master geodatabase.

In a multiuser geodatabase environment, different pieces of the geodatabase can be versioned. Editing permissions are tightly controlled and all edits must be reconciled before becoming part of the master geodatabases.

The city is not ready to implement a multiuser geodatabase, however, and for the pilot project it isn't necessary. Sue knows that she can migrate the data from the personal geodatabase to a multiuser geodatabase after the pilot project has been implemented and evaluated. She decides to create several personal geodatabases that will be assigned to different city departments.

For the Planning Department, Sue will create a personal geodatabase named Planning and it will contain a feature dataset named Boundaries. The Boundaries feature dataset will contain all the feature classes and relationships having to do with subdivisions as well as all the feature classes and relationships built on subdivision geometry, such as city boundaries and zoning.

When a personal geodatabase is created for separate departments or staff, a common structure with the same spatial reference should be maintained. Components of the personal geodatabases can be migrated to a multiuser geodatabase at a later date.

Creating personal geodatabases for each department will allow Sue to control access to specific data and allow each department to manage the editing process.