What's it like to use the Utility Network

Editor's Notes

• #4: Intermountain REA is an Electric Coop serving central Colorado. We serve 152,000 meters from Urban to Rural and Mountains to Plains, basically all types of geography in our system.
• #5: The current projects the GIS department is working on include our AMI vendor selection and fast paced rollout, CIS upgrades including the addition of a Mobile Work Force system, and Reconciling Pole and Joint use inventory of 3 separate projects and 4 different sources of data. Specific to the Utility Network, we are working on implementing Data Reviewer and Portal.
• #6: Data Reviewer, we are building up the rules and cleaning up the reported errors for things like Orphaned relationships, Geometry errors, proper subtypes and general attribute values. We are trying to build a clean consistent base of data to start our migration from.
• #7: ArcGIS Portal is required for the Utility Network. We don’t have that in place right now. Next week we will be sitting down with Esri to go over all the architecture required to implement ArcGIS Enterprise. This will be looked at as if it is a new GIS implementation. It’s our opportunity to build the GIS to fit the future needs of the company as well as the future requirements of technology. This rollout should be completed this fall. Some of the more technical decisions we will be making will be in regard to security and firewall protocols, GIS served from AWS, and whether we stick with Oracle or migrate to SQL Server.
• #8: As we complete what we are currently working on, we will move toward other steps to prepare for the ne GIS and Utility Network. We will get Beta loaded up again and will begin very thorough testing. We have committed to Esri that we will perform thorough testing and provide frequent scheduled feedback. I have one person who will spend most of her time learning, testing, and becoming IREA’s Utility Network expert. We will draw feeders from scratch as if we didn’t have any data in GIS yet and we will convert a few feeders form the current network, all in an attempt to understand how we want to model our networks in the future. We will spend a lot of time designing and testing integrations and working with those vendors to help them know how we need to integrate the new models.
• #9: In addition to gaining that expertise with the Utility Network, we will also be developing the rest of the IREA staff in preparation for the new GIS methodologies. Training GIS staff on Pro and publishing, training business users on Portal and AGOL, and generally getting our hands on the new ways of do the same job they do today with those new methodologies. IREA uses Schneider Electric’s Designer software. We know that in it’s current form, Designer will not be available to the Utility Network. So we are looking at that change on the horizon as well. As expected, there are many options that are starting to appear. The GIS department will assist the Design group in evaluating these options and finding the product with the best value and business fit for IREA.
• #10: At IREA, we have spent a little bit of time understanding how our data will migrate. We currently use the MultiSpeak model and we have stuck pretty close to this standard over the years. If you recall, this model has different feature classes for each device and line type location which is then broken down into multiple subtype and includes relationships for the individual components at that location, Banks vs. Units.
• #11: That results in a data tree of a Feature Class with related Object Class records underneath. In the case of an OH transformer, we have a bank numbered 46397 and related to that we have 3 object class records that have manufacturer and serial number. 4 records, 2 tables (not counting the A & D tables for editing and you can only symbolize on the 1 feature class record.
• #12: The same transformer in the Utility Network would look like this. Under one device table in the Distribution Tier and Feeder 2037 subnetwork you would have two asset groups, Banks and individual transformers. They would be related data wise with an field we add for Bank_ID. In the network they are related with a containment association. We would still have 4 records but all in one table and much easier to symbolize on the units. No more relationship classes or complicated joins to work with this data.
• #13: Lines would be similar. What may be concerning about this is the number of fields that would be needed to accommodate all the data for all the device types you currently have and then the fact that all devices would be in the same table. I think of this format similar to data warehousing. We are transforming from GIS data collection and editing to GIS data dissemination and analysis, moving from a write intensive system to a read intensive system. This flatter table format is quicker at reading because there are fewer joins.
• #14: For IREA, our current network devices would migrate to 215 fields in the new Utility Network table. Our record counts in the Devices table would be a million records while our lines table would have 1.1 million records and our structure network would result in a half million records. While those numbers sound large, they are actually quite manageable when there are no joins or relates to worry about. I will note though, these table will grow fairly quickly because versioning will also be stored in these same tables. But this is only a concern for physical storage space as the queries won’t slow down.
• #17: Want to make it easier on the easier. Not as many context sensitive items.
• #18: Containment view 3-phase secondary tapped off of 3-phase primary For each phase: arrestors -> fuse -> transformer
• #20: Take questions and wrap it up.