Helping Mappers Get it Right
Helping Mappers Get it Right
By Tom DeWitte and Tom Coolidge
Correctly mapping a buried pipe network is difficult. Everyone in your organization depends on the information to be “right.” The geometry must be right, the location must be right, the attributes must be right, and the connectivity and flow must be right. If any of these information components are wrong, your organization incurs inefficiencies, extra expenses, and potential damage to your pipe network.
The mapper is the person within the organization typically responsible for creating and maintaining this information. Every day, they come to work and face the challenge of consistently entering a large amount of information correctly—information that the entire organization depends upon to perform its own jobs. To succeed at this challenge, mappers need software tools to allow them to enter this information consistently, accurately, and efficiently.
Within ArcGIS, many configurations are available to help the mapper enter and update this information correctly the first time. Some of these capabilities are real-time data quality control, and some are validations to be checked after feature editing but before posting. Let’s look at the tools and capabilities available to help mappers create the pipe network information correctly the first time.
Getting the Geometry Right
Getting the Geometry right is critical to ArcGIS tracing and for hydraulic engineers who import the geometry into their modeling software, such as DNV’s Synergi Gas product. Both ArcGIS tracing and hydraulic modeling software require polylines that are not self-closing and do not have multiple vertices occupying the same coordinate location. Additionally, a polyline representing a pipe segment should never have a cutback of less than 60 degrees.
Implementing rules to prevent these types of misconfigured polylines is easy within ArcGIS Pro. A pulldown listing of ready-to-use geometry rules is provided for a geodatabase administrator to select and apply to the desired polyline featureclass.
With these geodatabase configurations in place, the mapper will receive real-time feedback when they attempt to create an invalid geometry.
Implementing the attribute rule constraint denying polylines with a cutback of less than 60 degrees, blocks this new feature from being completed.
Getting the Connectivity Right
Getting the connectivity right is also critical for any use case that requires tracing or an understanding of flow direction. Common use cases requiring connectivity are:
-Hydraulic modeling
-Emergency isolation tracing
-Cathodic protection management
Within pipe utilities such as gas, water, and district energy, there is another aspect of connectivity that the mapper also needs to consider. That is the correct assembly of the pipe network itself. There are many combinations of connectivity that are invalid. For example, it is not valid for a gas service line to tap directly off a gas transmission line. Nor is it considered valid for a cathodic protection rectifier to be connected to a plastic pipe segment. Metallic-only fittings, such as screws, flanges, and weldolets, should not be directly connected to plastic pipe segments.
The Esri-provided data models include a rulebase that defines valid connectivity between assets. Mappers using ArcGIS Pro get rule-based snapping tips to show them the valid connection options. This real-time guidance is a display mechanism to help mappers get it right the first time.
When a mapper attempts to connect two assets together incorrectly, the snapping tips will not display. For example, in this example, a steel pipe is incorrectly attempting to be connected to a plastic pipe.
When the mapper correctly attempts to connect a plastic distribution pipe segment to another plastic distribution pipe segment, the snapping tip displays to indicate the valid connection.
Getting the Attributes Right – Calculations
Mappers are continually asked to enter an ever-increasing amount of information about the asset. Implementing attribute rule calculations into the geodatabase is a great way to automate the input of the information and improve its accuracy.
Decoding barcodes is a great example of the power of automation while also improving the quality of the data. In this example, an arcade script was written to automatically populate the data fields: nominal diameter, wall thickness, material, manufacturer, manufacture date, manufacturer lot number, and material component type.
That is seven data fields automatically populated from one data field.
For the mapper, life is simplified by having this very detailed information auto-populated.
Getting the Attributes Right – Picklists
Most data fields that a mapper is asked to populate have a finite number of valid values. Fields like diameter, material, component type, and even wall thickness have a limited number of valid values. The geodatabase provides two related mechanisms to allow administrators to have ArGIS provide a picklist from which the mapper can choose. Coded-value domains, and contingent values are these two mechanisms.
Coded-value domains enable an administrator to create a pre-defined list of values from which the mapper can choose. This eliminates misspellings, inconsistent capitalization, and inconsistent abbreviation mistakes that are common with freeform data entry.
When applied to a data field, the mapper will be restricted to selecting a value from the list. There is no override option.
Contingent values enhance coded-value domains with a dynamic filtering capability that is based on another data field’s value within the record. For the mapper, selecting a coded-value domain value in one data field, such as asset type = Coated Steel,
will automatically filter the coded-value domain list of values in another data field, such as pipe material grade.
This real-time dynamic filtering can be defined as the unique combination of values across two, three, four, or more data fields.
Getting the Attributes Right – Required Field Constraints
Geodatabase attribute rule constraints can also be configured to prevent the submission of an edit unless specified conditions are met. A common example is required fields. In this example, an arcade script was written and applied as an attribute rule constraint. This attribute rule script requires that a tee cannot be submitted unless the data fields; diameter, diameter2, wallthickness, wallthickness2 are populated.
More advanced logic can be applied to have conditional required fields based on values of other data fields in the same record.
With this type of logic in place, mappers will be reminded at the point of submitting the record when a required data field has not been populated.
Getting the Attributes Right – Validations
Not all business rule logic can be consistently and correctly applied at the record submission stage. Some business logic needs to wait until the full set of edits for a construction project or repair has been applied. This delayed application of business rules is called validations.
Validation checks are initiated by the user with the Validate tool or automatically as a nightly batch process.
Common pipe network examples of validations are:
-verifying against the utility network rule base,
- verifying that the excess flow valve is coincident to a service pipe,
-verifying that the valve diameter is the same as the coincident pipe diameter.
These types of multi-feature data quality checks help mappers find mistakes that would be missed with simpler business rule logic applications.
Getting it Right
The geospatial data created and maintained by mappers is critical to the safe and reliable operation of the pipe network. Everyone in the pipe organization, from finance to engineering to field operations, depends on the geospatial data to be correct. The mappers maintaining this enterprise-level data source need robust and multi-tiered business rules to help them enter this information correctly the first time. ArcGIS is the system to provide these capabilities and to aid the mapper in getting it right the first time.
PLEASE NOTE: The postings on this site are our own and don’t necessarily represent Esri’s position, strategies, or opinions.