I’m often asked, “So what are the differences between the Geometric Network and the Utility Network?” That question usually makes me take a long pause because it’s not a quick or easy answer. When asked to write this blog post, it took me awhile to figure out where to start. As I stared out my office window, I saw the answer!
What you see here are the two trucks I own. On the left is a 2019 Ford Ranger. On the right is a 2001 Ford Ranger. Both are trucks. Both have engines and wheels. Both will get you where you want to go. But underneath the hood, things are a lot different. The 2001 doesn’t have things common for today: backup camera, onboard telemetry, phone integration, Wi-Fi, and the list goes on. The 2001 has a much bigger engine than the 2019, but the 2001 absolutely eats gas. The 2019 has a turbocharger to enhance the smaller engine and provide better performance. The 2019 is rife with features and functions that the 2001 can only dream of having through aftermarket parts. Coincidentally, they are basically the same year vintages of the UN and the GN, respectively. Both are designed to model networks, but they do it in much different ways. Let’s run down the list of the differences.
Data Schema
The GN allowed you to assemble a network from as many point and polygon feature classes as you wanted. While it was great to logically break apart data, it was very difficult for Esri to know or develop the technology because there was no consistency in how people were building their networks. One utility may build a GN with ten tables, and the one next door was using 100 tables.
With the UN, you are given a prescribed set of tables that you must fit your networked features into:
You can’t add tables to the UN, nor can you change those table names. Now, understand when I say you can’t add tables, I mean you cannot make any additional tables actively participate in the network topology. You can still have ancillary tables in your database and build relationships between the UN and said tables. You can still model your land base, inspection data, work management data, etc. however, you see fit. They just will not natively be used in the UN. You also can modify the individual attributes of those tables as you see fit for your business processes and needs.
Yes, this is one of the most significant changes to the UN that you have to get used to. The GN was really like my 2001 Ranger: I could work and tinker under the hood quite a bit. The 2019 Ranger and the UN? It’s not as easy. The tech is just different.
System Architecture
The GN was built around the technology indicative of the late 90s/early 2000s: desktop-to-database connectivity. The desktop did most of the heavy lifting and thinking (and no, I won’t go into the SDE server). While web-based functions and features were starting to come around, the GN was not natively built for it. It was built to run and be managed in ArcMap.
The UN was built with web-based services at the forefront of its operations. While ArcPro is the main editing application, it still needs to consume UN data from a web service. It would help if you had an ArcEnterprise platform established with ArcServer and Portal both running. While there are variations and caveats to that requirement, it holds true for most organizations using GIS as an enterprise system. Even the integrations are intended to be built around web services.
The GN was never meant to be consumed by anything but ArcMap. The UN is application agnostic. It can be consumed by ArcPro, desktop applications, web applications, mobile applications, and other enterprise systems. Basically, anything that can consume REST or GeoJSON services:
To me, this is the game changer of the UN for all utilities. The data is just the data. While it requires the ArcEnterprise to serve out, it does not require any special software or licensing to read or use. An editing license would be required to write data back to the UN web service, but again: the data is the data. If you can insert it back in the format the UN is expecting, you don’t need a super complicated custom interface to make any business process work!
Functionality
The final major difference between the GN and the UN is the built-in functionality that the UN brings to the table. You have to remember that the Geometric Network, as it was released in the late 90s, was not only meant for utilities. It was meant for any dataset that users required a topology model to conduct analysis. This generic technology could easily be adopted by water and gas. Still, electric and telecom companies almost require you to buy third-party software to run on top of ArcMap to model the intricacies of those particular commodities accurately. Even then, third-party software packages provided additional functionality that the basic GN could not, such as subnetwork management.
Subnetwork Management
If you’re confused by that term, subnetwork management is what the UN calls circuit/feeder management (in electric or telecom) or zone management (in gas or water). For electric, you definitely needed a third-party tool to manage a circuit or feeder effectively. For gas and water, you could get away with the basic GN functions to manage zones, but it was enhanced with (again) third-party tools. In the UN, the tools and functions to fully manage this critical item are built into the package. While some third-party tools can further enhance the UN subnetwork management experience, they are definitely not considered required by any means. The UN also provides something that very few people were able to accomplish successfully with the GN: support multiple tiers of infrastructure in one model, such as transmission and distribution!
3-D Modeling & Diagrams
There are other items that were additional costs in the past that are now included: 3-D modeling and diagrams (or schematic representations). 3-D modeling in the GN world required the purchase of the 3-D Analyst ArcMap extension from Esri, and even then, the GN was not designed to take advantage of true 3-D analysis. For diagrams, you had to purchase the Schematics ArcMap extension. Those features are built-in and included in the price of a UN editor license!
Connectivity
One last bit of major functionality changes between the UN and the GN: you no longer are required to have features on the map spatially coincident for connectivity! You can create rules that allow you to establish connectivity between different features on the map that are nowhere near or close to one another and still have all the subnetwork management and analysis tools work. While there are pros and cons to this, it does give you a greater level of control over how your map looks and how your topology operates.
The Utility Network, as it is named, was designed from the start with utility business processes in mind. Esri did not want you to have to find a third-party tool to model your networks. They provided support for auto-populating data and connectivity rules. They provided data propagation for circuit and zone names. For electric specifically, they included phase propagation tools.
There is so much to the UN in terms of possibilities and functionality that I definitely cannot list them all here.
The Past vs the Future
I can definitely make my 2001 Ford Ranger similar to the 2019 Ford Ranger. I can buy aftermarket parts, swap out the engine, and replace lots of components, and I could probably succeed in surpassing what the 2019 model can do. But at what cost? Is it worth it for a vehicle that is approaching 25 years of age? And yes, I can work on my 2001 myself a lot easier than I can in 2019. That doesn’t mean it’s a good investment for me to hot rod the 2001. That’s the thing with the Geometric Network: we all figured out how it worked and how to work it. I should hope so: we’ve had 25 years with it!
But at some point, it makes sense to move to something current. Something that was built around how the world operates today. We’ve invested a lot of time and effort in bringing up the GN. How about moving to a platform that starts a lot closer as a foundation to what we’ve spent all that time building up: the Utility Network.
