Sometimes the hardest part about using a centralized GIS is just getting started. When attempting to create a new Enterprise GIS data model, there’s a lot of thought and preparation that needs to happen before any of the real work begins. What data am I already tracking? What types of assets am I prepared to track in a centralized GIS? And to take it a step further, what are the logical groupings for these assets? Once the data model questions are answered, you need to create user groups and their corresponding permissions. It turns out, this may not be as trivial a task you think. What users should be able to see the data? Who should be allowed to edit the data? Then comes deciding on who the administrators should be. I won’t even begin to list the decisions that need to be made when determining how end users will interact with the data.

As Theodore Roosevelt put it, “Nothing in this world is worth having or doing unless it means effort, pain, difficulty”. I’m sure Teddy had GIS on his mind when relaying this bit of knowledge. While saying a GIS conversion can cause pain may be an exaggeration, the sentiment applies to our quest of a centralized GIS. There are a plethora of benefits, but since we don’t have all day to list them all, I’ll only name a few… Tracking all of our assets in a consistent model allows us to share our data across our team and allow everyone to be on the same page. If our team has access to the same data, there’s no question as to what assets are where or if the attribution in our dataset lines up with another group’s data. We can manage access to said data from the top down. Depending on the technology your team chooses, we gain access to industry leading tools to manage and manipulate this data as well.

The argument becomes more appealing if we take the alternatives into consideration. Here at SSP, we’ve encountered a great number of solutions for managing GIS data. A common approach we’ve seen is using KML files. Keyhole Markup Language (KML) files are an xml, file based way of sharing geospatial data. While these files are easy to share and edit, managing your GIS this way has it’s disadvantages. It requires sending files in either emails or shared drives to share the data. Even if the KML files are in a shared location on a network, there’s a chance of overwriting the data. Or even worse, losing the data altogether. KML makes for a light and easy way of managing GIS data, but not the most reliable or resilient systems. In a recent project, we had a KML GIS and the opportunity to switch to an Esri enterprise geodatabase. Given the pros and cons, it was an easy call, here’s how we did it.

The first challenge was to decide on what the final product should look like. What are our feature classes, subtypes, domains , etc… To define these, SSP conducted a design workshop where both SSP and the client groups looked at the existing data and decided the best way to model these in an Esri geodatabase. Once the new data model was defined, then the question arises: how does our current data map to this new model? To answer this question, every folder in the KML needed to be related to a feature class in the Esri GIS. After some more time meeting and hashing out these details, the team was ready for the data to be migrated over.

In order to perform the migration in a consistent matter, SSP wrote a script to automate the process. Using Esri’s Python API (ArcPy), SSP was able to write the migration completely in python. The structure of the script loosely follows this high level workflow:

• The script would read from a config file that defined what feature classes needed to be created for the target data model.
• For each feature class, the script had to create the corresponding fields and domains necessary for those fields. The script would then output an empty file geodatabase with the appropriate schema.
• The KML files needed to be converted into Esri feature classes in a local file geodatabase in order to interact with the features using ArcPy.
• Once the KML was converted, the script read from the converted KML feature classes and wrote each feature to the corresponding feature class in the empty file geodatabase.

Once a file geodatabase with the new data model was populated, that file geodatabase could be copied onto a SQL Server instance using ArcGIS Pro. After permissions were applied to the dataset (also using Pro), the enterprise geodatabase was ready to go. I’m glossing over some details, but at a high level, those were the steps to convert a distributed KML file system into a consolidated and centralized GIS.

The said client is now live in production with an Esri GIS. They are using ArcGIS Pro for desktop editing and viewing of data. They’re also using Portal for ArcGIS for creating and sharing content across the team such as web maps. Portal is using IWA (Integrated Windows Authentication) to tie Windows users to Portal users and manage each user’s content access appropriately. Now that they are working with an Esri geodatabase, they not only have the option of leveraging the rest of the ArcGIS platform, but are already enjoying the benefits from utilizing a centralized GIS.