The Northern Indiana Public Service Company (NIPSCO) had begun the process of building a new GIS data model that incorporated ESRI Shapefile layer technology. The existing system had stored data in AutoCAD drawings and layers. No direct method was available to successfully translate and migrate graphical and attribute data from the AutoCAD drawings to a predefined geodatabase data model. NIPSCO had asked Great Arc to develop a workflow that would produce multiple shapefiles for features in the Land, Gas, and Electric data models, as well as migrate the feature attribute data into the new data model.

The first task in the migration process was to extract the AutoCAD data layers to a personal geodatabase format. Great Arc developed a tool called InfoBuilder that extracts data from specified AutoCAD layers, and exports that data to a target shapefile. This process requires a user to select the specific AutoCAD layers and entity types to be extracted and to map them to the appropriate destination fields in the target shapefile. Feature types such as polygons, lines, points, and text can be placed into separate shapefiles using this tool.

The goal of this first task was to match the data fields and field types found in the data model provided to Great Arc by NIPSCO and their associates. In order to achieve this association correctly, a spreadsheet matrix of the data model was also provided. This matrix was used as a guide in the InfoBuilder process to correctly export out the necessary data layers and fields, as well as define the field types and lengths to match the schema of the geodatabase. Discrepancies in field sizes or types can cause errors.

Once the spatial and attribute data had been exported into shapefiles, the next step was to import the data into the appropriate feature classes of the personal geodatabase. Using ESRI’s ArcMap software, existing tools within the software were used to associate shapefile data fields to the feature class data fields. Once the shapefile data fields and the feature class data fields were mapped, the ArcMap software was used to import the data to the geodatabase. The appropriate projection for the geodatabase was then assigned (Indiana State Plane West Feet – NAD-83).

The next step in the migration process was data pre-processing. The new data model presented some new fields that did not exist in the old model, and called for data format changes from the old GIS. Pre-processing on the data imported into the personal geodatabase was needed in order to populate these new fields based on specific criteria defined by other fields or multiple fields. Flag fields, subtype codes, domain codes, and date formats are some examples of field manipulations that were done using a custom-built VB.NET application.

The loading of data into the pre-defined feature classes and tables was done using the Load Objects tool inside ArcMap. This was a multi-step process due to record conflicts that would occur if critical fields were not populated first. Once the critical data fields were loaded successfully, remaining data was loaded into the data model using the custom VB.NET application used in data pre-processing. The application uses a series of Update queries that can assure the population of necessary fields based on existing field attributes. Any records that were unsuccessfully populated were then flagged and noted for further review.

Once the data for Land, Gas, and Electric was loaded into the data model, feature class relationships needed to be established for Gas and Electric features. These relationships are critical for feature connectivity. Examples include Casings to Gas Mains, or Support Structures to Transformer Banks. Using a custom-built VB.NET application to create these relationships, reports were then created that show any features where a relationship could not be determined and where further analysis would be needed. A custom ArcObjects application was built for the analysis and cleanup of feature-to-feature relationships.

Part of the data migration process involved object table loading. A VB.NET application was built to append Landbase object data records to the existing land feature class records. The population of two key fields was critical in order for a relationship to be made back the source data. Having correctly populated these fields, our application could then load the remaining fields into these newly migrated records based on the key fields.

A different method was needed for Electric object table loading. It involved loading data from three different sources: Outfield, Legacy Outfield, and EDFS data. In order to complete this step, pre-processing of data in the existing feature classes was necessary to ensure that critical key fields were populated. The VB.NET application was used to report any key fields not populated, which would require further analysis.