Reflect network changes in diagrams

Introduction

Network diagrams always reflect the network state at the moment they are created. However, as the network changes, previously created network diagrams may no longer reflect the new network state. In previous articles we discussed how changes to the network affect diagrams, as well as how to tell which diagrams can be affected by network changes. In this article, we will explore the different workflows used to ensure that network diagrams reflect these changes.

Attribute changes

Depending on the type of attribute changes made to a network element, saving attribute changes may be immediately visible in open diagrams or require diagram updates.

Diagram feature symbols and labels

Most diagram sublayers have a join to the network source class or network source table they represent, and these joined attributes are often used to symbolize and label diagram features. In cases such as this, any change made on these attributes is immediately reflected on the diagram feature’s symbol or label when saved.

For example, imagine a diagram that symbolizes switches with a particular symbol when they are closed and another symbol when they are open. In this case, switching the position of a switch network device from closed to open (or conversely) and saving the edits will cause the symbol for that switch in any diagram to appear as open. This behavior is shown in the video below:

Diagram contents

Attribute changes primarily affect the related network class or table being edited, but these edits can often have downstream impacts. When the modified attribute is part of an attribute rule, this can trigger changes to other attributes or features.  If the change is made to a network attribute, validating the network topology to update the attribute changes in the network topology can also have larger impacts on the network area presented in the diagrams. This is especially true for diagrams based on templates configured with Trace rules that reference an edited attribute.

For example, imagine a diagram template configured to run a downstream Trace rule, stopping when it encounters an open switch. If you make an edit to open a switch, any diagrams created using that downstream trace rule may be affected by your change. You can see an example of this behavior in the video below where opening the switch and validating the edits changes the contents of the diagram once the diagram is updated:

As explained in the previous section, when the symbol used to represent the switch in the diagram varies according to the switch position, this change is immediately reflected in the diagram when saving edits. However, you won’t see the full impact of this change on the diagram until you validate the network topology and update the diagram to reflect changes made to the network topology in the diagram graph. In the above case, re-running the downstream trace when updating the diagram no longer traces network elements beyond the newly opened switch, and results in these network elements being removed from the diagram. In the example diagram above, over 700 network elements are removed from the diagram after it has been updated.

Attribute changes workflow

The following chart briefly summarizes the workflows outlined in the sections above:

To summarize, when attribute changes impact network elements and these edits are saved,  diagram feature symbols and labels based on the modified attributes are immediately reflected in the open diagrams. If the diagrams are built using Trace rules (*) and edits are made which impact the trace result, the diagram graphs can change.

NOTE: You must validate the network topology and save the updated network topology before running diagram updates.

Adds and deletes

Now that we’ve discussed how network diagrams respond to attribute changes, let’s look at how they respond to creating new features or deleting existing features. Deletions of network elements are reflected in open diagrams once they have been saved. Adding network elements, however, require additional steps to update existing diagrams.

Deleting network elements

In a diagram in which each feature represents a network element, it’s easy to see the impact of deleting network elements. Indeed, diagram features representing deleted network elements disappear from open network diagrams as soon as the edits are saved. This is due to the join between the network source class or table for each diagram sublayer. However, the diagram statistics will not reflect the delete until you update the diagram and the corresponding diagram features are removed from the database.

The following video shows the same sample diagram as in the previous scenario. We zoomed in on a network area where three houses have been demolished. The utility network doesn’t yet reflect these changes. So, we delete the three corresponding service locations and the service lines that connect them to a transformer. Once those edits are saved, the corresponding diagram features disappear from the open diagram. However, the diagram statistics remain unchanged. We then validate the network topology, save our edits, and update the diagram so the six newly deleted network elements are fully removed from the diagram and the change is referenced in the diagram statistics.

In this scenario, where the changes only affect end points, the diagram update only reflects the statistical changes and has no further impact on the diagram content. Deleting a feature such as a conductor would have had more impact in our sample diagram graph after its update because no network elements beyond this deleted feature would have been traced when the trace rule was run,  causing these network elements to be removed from the updated diagram.

Deleting workflow

The following chart briefly summarizes the previous section:

When saving network element deletes, diagram features representing the deleted network elements disappear from the open diagrams. Diagram updates clean the diagram feature classes for that diagram and reflect these changes in diagram statistics. If the diagrams are built using Trace rules (*) the update process can modify the diagram graph.

NOTE: You must validate the network topology and save the updated network index before running diagram updates.

Adding network elements

While attribute changes or network element deletes can have a direct impact on diagrams at the time the changes are saved, adding elements to the network is not reflected in diagrams until you complete additional workflow steps. This requires validating the network topology for the extent of edits  so they are updated in the network topology for inclusion in the diagram content.

The workflow to include newly created network elements in a diagram depends on the way its diagram template is configured.

The Update Diagram process retrieves the network elements initially used to generate the diagram and applies the sequence of rules configured on the template to rebuild its content from this retrieved input. If these rules query and add network elements to the diagram graph, and the new network elements can be queried at the time the rules operate, these new network elements will appear in the diagram after the update. Examples of diagram rules that can query and add network elements to the diagram graph are Trace, Expand Containers, Spatial Query, Add Connectivity Associations, or Add Structural Attachments rules.

If none of these rules exist in the template’s rule sequence, new network elements cannot be added to the diagram using the Update diagram command. In this case, you can instead select the new network elements you want to add to the diagram and use the Append to Diagram command. The Append to Diagram process retrieves the network elements initially used to generate the diagram and merge them with your selected network elements. It then applies the sequence of rules configured on the template to rebuild its content from this merge input. Note that in this situation, even if you force the rebuilt diagram to include the new input, the resulting rebuilt diagram may not show these new network elements. Indeed, depending on the rule sequence configured on the template, these elements can be discarded or aggregated during the diagram building.

The following examples use the three sample diagrams shown in the video below.

• The sample diagram called SpatiallyQueryContents is based on a custom template configured using Spatial Query rules to retrieve all network features within stations. This diagram was created from the single polygon ‘Kedvale Ave Station’ selected as an input.
• The diagram called ExpandContainers is based on the default ExpandContainers template. This template is configured to add all contents related to any containers in a diagram. This diagram was created from the single polygon ‘Kedvale Ave Station’ selected as an input. Since all network features within ‘Kedvale Ave Station’ are also explicitly set as contents of this station, the graphs of the SpatiallyQueryContents and ExpandContainers diagrams are the same.
• The third diagram called Basic uses the default Basic template. This diagram shows the 39 network features that were selected as input for its creation. These 39 input network features are ‘Kedvale Ave Station’ itself and all its related contents. The Basic diagram graph is the same as the two other diagrams.

Next, we created a device inside the ‘Kedvale Ave Station’ polygon and analyzed the impact on the three sample diagrams. The video below shows the workflow steps in greater details:

Once this new device is updated in the network topology, the Update Diagram command was applied to each sample diagram. QuerySpatiallyContents is the only sample diagram showing the newly created device after its update. This is because the update process restarted from the single initial input polygon ‘Kedvale Ave Station’ and runs the Spatial Query rules set on the template. These rules allowed the update to detect the new device inside ‘Kedvale Ave Station’ and add it to the diagram.

Even if the new device was created inside the station, this was not sufficient to retrieve and include it when updating the ExpandContainers diagram. This template includes all the content of containers, and because the new device isn’t  set as a content of the ‘Kedvale Ave Station’ polygon, it is not detected during the update.

For the third diagram Basic, the update process restarted from the 39 network features that were selected as input for its creation. Since there is no diagram rule on the template that allows querying the new device, the updated diagram doesn’t reflect this change. The only way to add this new device to this diagram is to use the Append To Diagram command.

Adds workflow

The following chart briefly summarizes the sections detailed above:

To summarize, the addition of new network elements has no impact on existing diagrams when edits are saved. However, if you update diagrams built from rules that can query and add network elements to the diagram graph (**), the diagram contents and their statistics can change.

You can also select the newly created network elements and run the Append to Diagram function to add them to diagrams.

NOTE: You must validate the network topology and save edits to the updated network topology before running updates or appending new network elements to diagrams.

TIP: The best diagram templates are those configured with rules that automatically query and add newly created network elements to your diagrams when updating. This makes it easy to reflect network changes by clicking on Update Diagram.

Conclusion

In this article, you learned how attribute changes, deleted network elements, and newly created network elements can be reflected in diagrams. You also learned how the rules configured on the diagram template determine which workflow you use to include the network changes in diagrams. To refresh your knowledge of diagram template configuration, you can read the Best practices to configure great diagram templates blog article.