We all know that ArcFM™ auto updaters allow for a significant increase in efficiency for users when creating or updating utility maps. I would like to present a short showcase of the true power of auto updaters and how these simple tools can keep your information organized and healthy.

Auto updaters allow a developer to do just about anything with the programming environment provided with ArcGIS and ArcFM™ known as ArcObjects. We can traverse up and down networks, run sophisticated spatial searches, cross-reference any relationships, perform complex validation of data, or even create new features.

Let’s take a look at some examples of auto updaters in action.

The first example in this demonstration are auto updaters that I think are the most interesting and the most useful. These are geometric network traversal auto updaters. Since ArcGIS provides a convenient way of configuring a network of features, we can use this network to keep all necessary information up to date. 

Let’s say we have Service Location point features which are downstream from our Transformer features. Without auto updaters, anytime we add a new Service Location, we have to manually locate the transformer that feeds it. Once it is found, we have to select it and then memorize the arbitrary ID number or write it down (and any other fields needed). Then the user will enter the new values via the attribute viewer for the new Service Location. Imagine doing this every time we add a new point. That’s a lot of time and work! When we introduce auto updaters into the picture, the task just became a lot easier.

Here we have an auto updater that acts as soon as that new feature is plopped down on the map. It instantly traverses up the network and finds the transformer. Then it copies over the ID and any other fields needed (including adding fields together; very useful for text labeling). We now have all of our updated information in the blink of an eye and all the Designer™ had to do was add the feature.

—

The amount of time spent editing increases greatly as more complexity is added in configuring the values. For instance, if we have a tap between multiple overhead lines, we will want to collect information from them. However, this may not be as simple as looking at one feature. Often we will want to compare information from multiple connected conductors, poles or transformers.

This would be very time consuming for someone doing it by hand. However, this is no sweat for our custom auto updater to handle. The program will sweep through the network collecting and comparing information from any number of features that we want in a heartbeat. In the image below, the Aerial Tap feature has automatically grabbed its CU information from its connected feature based on criteria for each field. All while the Designer™ is taking a sip of their coffee.

—

Other times we have features that aren’t connected in a network or don’t have relationships to other features that they need information from. In this case we must determine which features share data by performing a spatial search.  Given the power of GIS, we can use any of the properties of our spatial data to update a feature.

SSP was recently asked how to determine which conductor lines were in parallel. Now this may seem trivial at first, but there are many factors to consider when making this determination. Envision conductor lines coming out of a substation. This can be quite a mess! Defining what lines are in the same span is no longer that easy, especially when striving for a high degree of accuracy.

To solve this issue, we have written intelligent algorithms that, given a conductor, will find other features in its span. This is done by finding the mid-point of the line and searching around that point to a configurable distance. The features within that buffer are then matched within a 20 degree tolerance of the slope of the source line. We then issue a percentage of confidence that this is a parallel line in the same span. If it matches our pre-set level of confidence, we consider it a match. A utility can be sure that the data is being updated on the correct features.               

—

Finally, auto updaters can keep data validated or add restrictions that aren’t otherwise possible. An example of this is adding more complexity to field domains.

Domains are useful for restricting what can be entered into a field and providing a list of options for a user. Yet, domains only provide a single list of values that are pre-determined in the database. What if we want to reference other fields in our feature (or other features) to further determine what should be allowed in the field we are editing? Once again, auto updaters come to the rescue.

No matter the complexity, whether it is an intersection between domain values or making sure a number is unique, it can be done.