How GeoData Modeler Eliminates Data Model Confusion in Utility Organizations
Pop quiz: where is your data model documented?
If the answer is “in a spreadsheet that Dave started in 2019,” or “partly in ArcCatalog and partly in a SharePoint folder that nobody can find,” or, my personal favorite, “in Greg’s head, and Greg retired last March,” then congratulations. You’re in excellent company. This is one of the most common problems in utility GIS, and also one of the most expensive ones that nobody talks about.
The data model is the foundation of everything your GIS does. Every map, every trace, every integration with outage management or asset management or customer information systems depends on the schema being correct and everyone understanding what’s in it. When that foundation is documented in scattered, outdated, or conflicting sources (or not documented at all!) the downstream effects ripple through the entire organization.
And somehow, this keeps being treated as a “we’ll get to it” problem.
The Real Cost of “Which Version Is Correct?”
Here’s a scenario that plays out constantly at utilities of every size. Your GIS team makes a schema change in the development environment — adds a new domain value, modifies a field alias, adjusts a subtype configuration. The change gets tested, promoted to QA, and eventually pushed to production. Standard stuff.
Except the contractor doing your data conversion is working from a spec document that’s two changes behind. Your application developer is referencing an export from ArcCatalog that was generated before the last maintenance window. Your business analyst has a requirements spreadsheet that lists the proposed changes but doesn’t reflect which ones were implemented. And your new GIS technician is looking at training materials that haven’t been updated since before COVID-19.
Nobody is wrong, exactly. They’re all working from documentation that was accurate at some point. The problem is that “some point” isn’t the same point for any of them.
The result is mismatched integrations, failed data loads, misdefined symbology, invalid attribute values that pass QA in one environment and fail in another, and a slow-building erosion of confidence in the data. People start building workarounds. They hardcode values instead of referencing domains. They maintain their own private spreadsheets. And every one of these “solutions” becomes its own little source of drift.
This isn’t a GIS problem. It’s a configuration management problem, and it has real costs in terms of rework, project delays, and hours spent reconciling differences that shouldn’t exist.
The Contractor and Consultant Problem
If schema confusion is expensive internally, it gets worse when external teams are involved. And in utility GIS, external teams are almost always involved.
Data conversion vendors need to know exactly what they’re loading into. Application developers building integrations need the current schema, not the one from last quarter. Consultants brought in for migration planning need to understand what’s in the data model, sure, but also how it compares across your development, test, and production environments.
Every time you onboard a new contractor or consultant, someone on your team spends hours (or days) pulling together documentation, answering questions about which fields are active, which domains are current, and whether the QA database matches production. It’s the equivalent of giving someone a map and then immediately telling them not to trust the legend.
And when those external teams deliver work based on outdated documentation? That’s when data loads fail, integrations break, and the project timeline takes a hit that somehow nobody saw coming.
What “Single Source of Truth” Actually Looks Like
GeoData Modeler was built specifically to solve this problem. It connects directly to your geodatabase and generates a complete, current report of the schema. It shows every table, column, domain, subtype, relationship, and configuration property in a multi-tabbed Excel spreadsheet that your entire organization can use.
That last part is the key. This isn’t a tool that only your DBA can interpret. The Excel format means your business analysts can sort and filter. Your project managers can review. Your training team can reference it for materials. Your contractors can get a complete, accurate picture of the data model without someone from your team spending a week compiling it manually.
Here’s what it does in practice:
Baseline Reporting gives you a complete snapshot of a geodatabase at any point in time. This is your starting point. The definitive record of what the data model looks like right now. For the ArcGIS Pro environment, that includes Utility Network properties: domain networks, tiers, rules, edge connectivity, subnetwork asset properties, attribute rules, and contingent values. It’s the kind of comprehensive documentation that everyone agrees they should have and nobody has time to create manually.
Schema Comparison is where things get really powerful. GeoData Modeler compares two geodatabases (or a geodatabase against a baseline report) and generates a delta spreadsheet that shows exactly what’s different. Adds, deletes, property changes, previous values for auditing. In minutes, not days. Overnight, without supervision, on a schedule.
If you’re managing multiple environments (development, test, UAT, production), this is how you confirm that the change you promoted landed correctly. Even minor discrepancies in Utility Network rules can significantly impact editing and network topology management, so catching them before they cause problems in production isn’t optional.
Automated Update Scripts take the deltas one step further. GeoData Modeler generates Python scripts based on the differences between compared databases, so the same update can be applied consistently across every environment. Development, test, UAT, production — same script, same result, same confidence that your schemas are in sync.
Anomaly Detection catches the things that manual inspection misses: inconsistent field aliases, field and domain type mismatches, invalid or orphaned configurations. These are the issues that aren’t caught until something breaks downstream, and by then, figuring out which anomaly caused the break is its own project.
What This Looks Like in the Real World
Scott Ewart, the GIS Lead at Peoples Natural Gas — a utility serving approximately 700,000 homes and businesses — put it pretty directly: “We use this day-to-day to help other departments within the company know our data schema for integration. This is also the go-to source for any questions that arise related to our data model.”
That phrase “go-to source” is doing a lot of work in that sentence. It means when another department asks what does this field mean? or what are the valid values for this attribute?, there’s one place to look and it’s current. No emails. No hunting through folders. No calling Greg (he retired, remember?).
Ewart also highlighted the comparison capability: “Being able to take new data models and compare them to our existing data model is a huge benefit. This has saved us a lot of time trying to understand the changes and then pick the changes that need to be implemented.”
And on the promotion workflow: “Making the changes in our QA instance and testing everything before pushing that to production is a big win. Knowing we have field consistency across all tables is also very helpful.”
At Madison Gas and Electric, the story is similar. They integrated GeoData Modeler into their schema update routines to ensure updates deploy consistently across environments. As their Supervisor of Distribution Systems Technology put it, the product “builds confidence in our deployments and has saved us countless hours of ad-hoc testing and manual comparisons between environments.”
Countless hours of ad-hoc testing. That’s a polite way of saying “we used to spend a staggering amount of time doing something that should be automated.”
Why This Matters More During Migration
All of the above is valuable for day-to-day operations. But during a Utility Network migration, having a single source of truth for your data model shifts from “very helpful” to “absolutely critical.”
The Utility Network introduces significant new schema complexity such as asset groups, asset types, association rules, terminal configurations, subnetwork definitions. Your team needs to understand not just what migrated, but how the new model is structured and configured. And they need that understanding to be consistent across every person touching the data.
GeoData Modeler’s Utility Network reporting covers the full scope: UN domain networks, tiers, rules, edge connectivity, and subnetwork asset properties. It becomes the documentation layer that keeps your entire team, from internal staff, contractors, consultants, and decision-makers, aligned on what the new data model contains. No surprises.
When you combine that with GeoData Sentry’s ongoing data quality validation, you’ve got a complete picture. Modeler tells you what the data model should look like, and Sentry tells you whether the data inside it actually complies.
The Bottom Line
Data model documentation is one of those things that’s easy to deprioritize because the consequences of not having it are diffuse. Nobody files a trouble ticket that says “our schema documentation is outdated.” Instead, you get a steady trickle of errors and failures that drains productivity across the organization.
GeoData Modeler turns data model documentation from a manual, perpetually-out-of-date chore into an automated, repeatable process that produces a single, current, shareable source of truth. For utilities managing complex geodatabases across multiple environments — especially those heading toward or already living in the Utility Network — it’s the difference between hoping everyone’s on the same page and knowing they are.
Greg would be so proud of you.
See what your data model actually looks like — request a GeoData Modeler demo using your own data or download a free trial to put it through its paces.