Recently, there was a question about how to use attribute rules to prevent containment associations based on distance for utility network features. Containment associations help to identify assets that are contained within other assets—such as a fuse device within a fuse bank assembly. This question is particularly interesting for several reasons:
One, associations do not have to be colocated, which means they don’t have to share the same spatial location. Two, it identifies the need to improve data quality beyond what the system identifies as data quality issues. Attribute rules provide a way to do platform-wide checks for data editing workflows by extending editing capabilities. Another reason is that utilities tend to have a large team of data editors, so using attribute rules to extend editing capabilities can be useful in the context of improving data quality. Lastly, not all data quality checks are appropriate to include as a part of the utility network dataset. In other words, some checks and balances are built directly into the utility network, such as network topology errors that are discovered during validation of the network topology.
However, the distance check on containment associations is outside the scope of the system check. Therefore, the utility network does not enforce any sort of distance constraints on containers and their content. In this example, the goal of creating rules is to allow utility network features to abide by a set of business validation logic to ensure the data remains clean, or as clean as possible. This post will show how to use attribute rules to enforce a distance constraint on utility network association features and test those rules by performing edits to verify the expected behavior during an update event.
Assembly-Device use case
In most use cases, features that are related in a network are, typically, spatially close. For example, fuses (device class) are contained within the fuse bank (assembly class) or transformers (devices) within a transformer bank (assembly). There are no constraints for the maximum distance that can separate two associated records, which means “close” proximity could be 100 miles, but this is not something we would realistically expect, therefore we should prevent edits that are too far apart. So, we can introduce a little more logic when we modify associations by adding a constraint attribute rule. The reason we introduce the constraint rule is because when we update the association status, in other words, modify association, it impacts both the container and the content participating in that association. Therefore, we add an attribute rule to the update event for both the assembly and device classes.
Constraint attribute rule example
In our example here, we are going to create an attribute rule that prevents an association from being created if the distance between the features is too large (for example, 3,000 feet). We will do this between the assembly class and the device class—the transformer bank (assembly) and transformer (device). The basic logic of the edit is to create a containment relationship between assembly and device. When using the modify associations pane, this edit will cause an update event to fire on the device and the assembly. We then capture this event and do the association query using FeatureSet functions to find the container and/or content, calculate the distance, and if the distance is too large, the edit will fail. This is a constraint attribute rule.
Here’s how this is done:
Testing Edge Cases
To test the rule, we’ll use two edge cases. The first edge case is one assembly with multiple valid contents; in this case, the edits should apply. And the second case is to modify associations using one valid content and one invalid content; however, in the test case, one edit should apply and the other should return the attribute rule error.
So, what happens if we move the assembly feature far away from its contents (or containing devices)?
The current constraint rule on the device will not catch this edit. Therefore, we need to add the constraint rule on the update event for the assembly features. This is essentially the same rule we created for the device features to identify the container, but instead we are identifying the contents of the container feature.
Now, how do we catch bad cases that are already in the system?
For example, bad cases can come from existing data loading, and these cases will not be caught by constraint rules. In this case, we can add the same rule as a validation rule and create error features on the assembly/device classes that are too far apart.
This simple example was intentionally designed to be straightforward to show how to perform a distance check on feature associations attribute rules. However, for the device class, it only checks for the containment associations, and on the assembly class, it only checks for the content associations. Therefore, the constraint rule shown here is limited to the container and content association types, but ideally, if we needed to expand the rule to evaluate other types of associations such as attachments, we could. Check out the FeatureSetByAssociation using Utility Network post for more examples of attribute rules with different association types.
Article Discussion: