We may take advantage of a data-source matrix to identify to help identify what our data would look like once it’s been brought in and finalized.įor example, we might identify that the Electric Support Poles in our source data are Structure Junctions in the Utility Network. This is where we can revisit our data models and remove any legacy fields that are no longer maintained or add new fields to features for future planning. What fields do we need to migrate, and what are they now? Is there any additional information that we may need that we need to calculate or change during the import? Do we have any static and reliably-unique fields we can use to easily identify matching features with?īroadly speaking, having an end-goal definition of what the data will look like is a fundamental aspect of the design simply because it defines the components of the migration that may need to be changed to fit the data we are working with. The general gist of how this data is translated requires that we ask a few questions about the format of the data now, and how it needs to be defined in the Utility Network.
This blog will cover the steps that we took at a high-level to accomplish the task, and any observations or issues we encountered during development. The task can be daunting at first, but by using the ArcPy library and the ArcGIS Server feature services, we can easily design a straightforward process that can be used for many different sources of data beyond PLSCADD. A recent project of mine involved taking data created in PLS-CADD projects and transferring it to an existing Utility Network implementation to import new features and update the features that were already in the GIS.
Migrating data into a Utility Network environment may seem like a challenging experience, but the process can be streamlined with Python.
0 kommentar(er)
