There has been a lot of excitement around upcoming attribute rules’ functionality and Arcade expressions.  In this blog, we will talk about attribute rules, a little bit of history on the ideas behind its development, and new features that are coming soon.

In this blog, we will talk about the history and development of attribute rules as well as review new features.

A brief history of improving data quality in ArcGIS

Over the years, a lot of endeavors were undertaken to improve the data quality of the GIS system. Geodatabase domains helped reduce erroneous entries through picklist instead of free typing. Default values on fields simplified the editing process. With subtypes, a field can have a different default value and domain based on which subtype the feature belongs to. Editing templates drastically simplified the editing experience, allowing users to pick a pre-defined editing template and create a feature with predefined attributes. Group and pre-set templates helped bring together multiple templates allowing users to create multiple features with one click.

With Attribute Assistant and Data Reviewer, users were able to create rules to auto-populate attributes and create errors for invalid entries. This allowed users to be much more productive by employing parameters to improve the quality of the data. However, Data Reviewer and Attribute Assistant functionalities are only enforced while editing through the application (in ArcMap and ArcGIS Pro). Edits that came through other applications such as web or mobile apps like ArcGIS Collector have the potential to avoid proper validation; creating a situation where bad quality data can still make it into the geodatabase.

Esri decided to push the evaluation logic deep down at the lowest level where all client edits eventually end up; within the geodatabase. This resulted in the evolution of attribute rules. Attribute rules are scripts that a user can define on datasets. They trigger automatically with incoming edits and can be used to constrain the attribute values allowed on fields or perform a calculation to derive a field’s value. They can also be run on-demand to calculate values and also create errors for features that violate any rules (new at ArcGIS Pro 2.3/ArcGIS Enterprise 10.7). This can be done after editing or perhaps as a nightly job.

Attribute rules are designed to run on the entire ArcGIS ecosystem. This is possible with the new Arcade scripting language which provides a richer and more extensible experience of the Esri GIS platform. Arcade enables enhanced labeling, popups, defined symbol sets, display settings, and now, improved attribute rules. Arcade runs on any environment, desktop, server, web, mobile, and much more. It is continuously evolving as a scripting language. Learn more about Arcade here.

Here some examples of attribute rules.

What’s new for Attribute Rules

In ArcGIS Pro 2.2, users can create attribute rules that fire on edit events such as insert, update or delete operations. These rules are referred to as immediate rules which are either constraint or calculation. Constraint rules can block the edit if the rule’s script is evaluated to false. Calculation rules can evaluate its script and persist the result in an attribute on an edited feature. These rules are only limited to the edited feature; i.e. users cannot access features from other layers or even other features from the same layer.

The ArcGIS Pro 2.3 and ArcGIS Enterprise 10.7 release includes the following enhancement to attribute rules:

• New Arcade functionality
• New rule types
• Improved user experience.

New Arcade functionality

In ArcGIS Pro 2.3, the Arcade language is expanded to include a FeatureSet type which allows attribute rules to access other features. This approach unlocks the potential for creating various rules, such as ‘don’t create parcels that intersect other parcels’; ‘auto-populate the project attribute from its nearest feature’; or ‘calculate the rotation angle of a valve based on the pipe it is created for’.

New rule types and Validation server capability

In ArcGIS Pro 2.3/ArcGIS Enterprise 10.7, batch calculation and validation attribute rule types are added. These rule types are evaluated via feature services that include the Validation capability. The Validation capability can be enabled on a feature service starting at ArcGIS Enterprise 10.7. This will enable evaluation of batch calculation rules and validation rules on the server. As you might imagine, this functionality is a longer topic, so I will write a follow-up blog with greater detail.

Note: Creating Batch attribute rules (validation and batch calculation) will add the ValidationStatus field that will be used to track the state of the feature. Batch rules are only available for server-side evaluation with ArcGIS Enterprise 10.7 and cannot be published or evaluated on earlier releases.

Validation Rules

Validation attribute rules can be created and evaluated on demand to create errors for features that violate the rule. An example of a validation rule could be to create an error if the number of wires contained within a duct exceeded the maximum wires capacity of the duct.

Batch Calculation Rules

Calculation rules can also be run on batch mode at a user-defined time.  Users who have authored compute-intensive scripts that don’t necessarily scale when running in immediate mode can specifically take advantage of the batch mode. Having these rules fire on demand asynchronously on the server can offload and increase the throughput of editing. Batch rules (especially validation rules) can evaluate and create errors for those features that do not satisfy the user rule. So instead of preventing the user from entering bad data, users can make the edits, and a batch process will execute all rules and flag all offending features as errors.

An example of a batch calculation rule could be calculating the total kVA in a substation by summing all containing transformers.

There are trade-offs to be considered when choosing between immediate and batch rules.  Immediate attribute rules improve the quality of the data as users make edits by preventing bad data from being entered, but you must consider the throughput resulting from the compute cost of the rules. More complex rules will logically have a higher compute cost. Batch attribute rules won’t have an immediate effect on editing performance but will allow any data to go in.  At a later time, the evaluation process will flag ‘bad’ features as errors.  When that occurs, another workflow can be used to resolve those errors.

Improved User Experience

With ArcGIS Pro 2.3 we have enhanced the user experience for authoring attribute rules. Users can view properties for existing rules and author attribute rules more intuitively. The error inspector is also redesigned to support evaluating attribute rules and displaying validation errors.

The Attribute Rules view and ribbon are available in ArcGIS Pro 2.3 to work with existing rules for a dataset and to author attribute rules.

What’s Next for Attribute Rules?

We are not done yet! This project is exciting with a lot of things coming beyond 2.3 and 10.7; here are some of the items we are working on for the coming releases.

Support attribute rules on file geodatabases – We will provide support for adding and executing immediate attribute rules (calculation and constraint) on file geodatabases.

Prevent posting errors marked as ‘Severe’ – Another upcoming option is the ability to tag errors with severity (1-5 scale) to prevent users ever posting to DEFAULT any features that have a severity of 1.

New evaluation types – The validation server for 10.7 supports evaluating Calculation and Validation rules. In future releases, we will augment the server to evaluate many other geodatabase elements such as domains, contingent values, subtypes and relationships.