With the release of Pro 2.4, we continue to expand upon the tools available to help model and design your data. In this blog, we’ll review contingent values in case you missed them in the previous release, discuss some benefits they provide, and how they differ from and complement the functionality provided by domains and subtypes. We will also review new features that improve usability and highlight capabilities under development for future releases.
Let’s Review
The suite of tools available to design and ensure the creation of quality data in ArcGIS Pro includes items such as domains, subtypes and default values, network topology, attribute rules, and now contingent values.
First introduced with ArcGIS Pro 2.3, contingent values offer another means to help maintain data quality upon entry, much like domains and subtypes. Contingent values provide new capabilities to create dependencies between fields with domains.
Contingent Values Expand Domain Capabilities
Domains provide the foundation upon which contingent values are built by implementing filtering on fields to force selection from a pre-defined list of values; contingent values expand upon this by introducing logic which defines contingencies between fields to reduce the list of choices presented based upon selections elsewhere. More simply put, domains restrict data entry for a single field, whereas contingent values build upon this to accomplish the same for multiple related fields.
Field groups, created within the Contingent Values view, make this filtering possible. Field groups link multiple fields and allow any number of valid combinations to be defined between them.
Context Please…
As an example, consider someone entering data collected from a recent field survey. In this scenario, field observations are enriched through the addition of scientific classification details. We have a subtype field to apply specific symbology and defaults based upon whether the animal is a mammal, bird, reptile, etc. and a field group comprised of fields to capture information such as the general type, order, family, and species of each.
When choosing the Bird subtype, the editor is presented with the contingent values defined for this subtype which then filters the valid options for the type, class order, family, and species as a result.
Let’s take a look at how this works conceptually and within ArcGIS Pro when selecting “Rail” from Type within the Bird subtype
To summarize
With contingent values configured for a set of fields within a field group, the selection made in one field determines the choices presented in the other fields. When editing, instead of seeing the entire list of values within the domain, you will see only valid options defined as contingent values for the chosen attribute.
Additional benefits
Contingent values provide other benefits beyond simply restricting editing options to improve data quality. Contingent values can help reduce the level of decision making during editing, making the process faster and more efficient. This functionality also provides the ability to retire values, exposing the capability to display valid historical data in places such as the attributes pane without providing the option within the picklist. This capability is useful when a value remains valid for existing features but is no longer in use such as asbestos as a building material.
How do these differ from Subtypes?
Like subtypes, contingent values allow for abstraction at the domain level; however, contingent values take this abstraction much further by restricting the options available within the picklist.
Envision a scenario where you have a feature class of city streets categorized using three subtypes for local, collector, and arterial streets. The subtype is valuable to provide one level of abstraction and define different default values for speed limit (such as 25 miles per hour for local streets); however, there is nothing that would prevent an editor from choosing a value other than the default (perhaps setting this to 70 miles per hour). While other values may be technically allowed within the domain, they would be invalid in actual usage for this road type. Applying contingent values in this scenario improves upon the logic to constrain the options available for the subtype’s speed limit and prevent edits such as this from occurring. Additionally, validation is present during data entry to alert the editor to the presence of invalid values, which highlights impacted fields and disables the option to save.
What’s new for contingent values in ArcGIS Pro 2.4?
Improved User Experience with Export/Import GP Tools – Within ArcGIS Pro 2.4 you can now export and import contingent values and fields groups using the Export and Import Contingent Values geoprocessing tools. These new tools are useful for backing up or sharing your data with others, editing the .csv directly to make changes, or for migrating changes into production without introducing unnecessary locks.
On the horizon – what’s next?
There are many exciting developments on the horizon to build and improve upon the capabilities provided with contingent values beyond 2.4. Here are a few of the items being worked on for future releases:
Import/Export from ribbon – Support for the import and export of contingent values to a .csv file will be made available from the Contingent Values ribbon within the ArcGIS Pro user interface.
Enable the option to disable restrictive contingent values – Currently, with ArcGIS Pro 2.4, all field groups created are restrictive by default. This means that values entered on fields participating in a field group are restricted to those specified as contingent values. Any values not defined as valid combinations within the field group cannot be saved.
An upcoming option will provide the ability to disable the restrictive setting on new and existing field groups to allow the ability to input and save values on a field even when they are not specified as contingent values within the field group. This option enables the advantages of value filtering provided by contingent values without the associated data quality safeguards by allowing override of the defined contingencies. Less restrictive contingent values could be useful in situations where actual observations or data could potentially conflict with the contingent values defined for a field. Going back to the wildlife field survey example, imagine a Yellow Rail was observed during the trip; while the Yellow Rail is not native to the area of study and not an option defined within the field group, based on the collected observation you could override this and select the value from within the assigned domain.
Auto-populate contingent values – A future release will introduce new capabilities to automatically generate all available contingent value combinations within a field group when a single path is configured between fields. This functionality will help improve the speed and efficiency of some editing workflows. Using the wildlife survey example again, consider the ability to enter the species of a bird, and have the remaining fields auto-populate afterward, such as the bird’s family and order. Likewise, if capturing data about the sighting location and working within a known survey grid, this information could be used to automatically populate the zip code, city, county, state, and district fields based upon the contingent values as each grid would have only a single zip code defined as a contingent value.
Support for contingent values in Runtime – We plan to expose contingent values through Runtime in a future release so that Runtime clients can read and open datasets with contingent values and expose them, paving the way for expanded usage in editor apps beyond ArcGIS Pro.
We’re curious to know if you’ve started using contingent values and in what interesting ways they’ve improved your workflows. Make a plan to give them a try if you haven’t already. Let us know how you use them and what you think about contingent values by joining the discussion on GeoNet.
Commenting is not enabled for this article.