In a previous blog, A Spatially Enabled Document Management System, I provided a basic overview of Esri Production Mapping’s product library. Now, the next step is to start thinking about the ways in which you could implement product library in your organization. So first, I’d like to focus on the types of editing business rules that can be stored and managed in product library.
“Business rules” is a term we use to refer to the logic you build into Production Mapping to ensure the data and maps produced meet the specifications of your organization or industry. Some of the common types of business rules apply to data validation, symbology, attribute display, and surround elements. The behavior of many tools can be customized in Production Mapping based on how you build your business rules. For example, when editing feature attributes you can validate them against rules you pre-define using Production Mapping. This ensures that only valid data is entered into your GIS. In the following sections we will discuss the types of editing business rules that can be configured with Production Mapping and managed in product library.
Data Models
A data model represents the schema of your production database, which is the database used for editing and cartographic production. The schema of your database may change over time, therefore each edition of the model is managed in product library as a data model version.
The data model version establishes a link between the business rules stored in the product library and the schema of the production database. The tools that read the business rules, like Feature Manager, use this link to determine which rules to use during data editing. You can also use the product library to store business rules for multiple databases with different schemas (i.e. data model versioning).
So, when do you need to manage your data model versions in product library? Only if you wish to take advantage of on-the-fly validation and customized attribute display.
On-the-fly Validation
With Production Mapping, you have the ability to validate the attribution and geometry of features while editing. For those familiar with quality control methodologies, you know that the earlier you detect an error the easier and cheaper it is to fix it. On-the-fly validation is designed to notify editors of potential errors before they even commit their edits to the database.
You might ask – doesn’t the geodatabase offer the same capabilities? For many users, implementing subtypes, domains, topology, and connectivity may be sufficient to ensure their data’s integrity. However, you might have attribution and geometry constraints that cannot be defined within the geodatabase alone. Let me explain using an example of a streets feature class. Typically, all street address numbers are odd numbered on the left side of the street and even numbered on the right side. The starting address on one side of the street should not be higher than the ending value on that same side. Determining even/odd values or specifying that a value in one field should be less than a value in another are not rules that can be built into the geodatabase.
Data Reviewer batch jobs store the validation rules you want to run on your data. These batch jobs must be stored in the product library to utilize on-the-fly validation. Going back to the above example, by storing those rules in product library you can validate that an address value entered into a field is odd at the moment you enter it. Those same validation rules used for editing can also be used when validating the data during the quality control (QC) phase of your workflow.
Custom Attribute Behavior
Field configurations are used to customize how attributes are displayed and populated when edited using Feature Manager. There are 5 key types of customization offered, which includes the following: attribute display, attribute edit control, dissolve settings, additional help, and feature-level metadata. This level of customization is specific to the production database being edited and will therefore require you to create a data model version.
Customizing the attribute display allows you to define how attributes appear in Feature Manager (see Figure 1). For attributes that are mandatory or important you can draw attention by making the field bold. For fields that are not critical or should not be manually populated you can disable or hide them.
The field configurations offer additional controls for use when editing an attribute on top of the standard controls such as a text box or a list. You can create a multi-pick list control that allows you to choose more than one value from a domain. You can also set the field to display a list of values even if a domain is not associated to that field.
The Production Dissolve tool allows you to automatically dissolve touching features based on pre-defined rules that are part of the field configurations. You can choose fields that must match in order for two features to be merged as well as define the values that should be populated in fields where the values do not match. For example, if you want to dissolve building polygons, you can configure rules to specify that two buildings should be combined ONLY if the address matches on both features. For other fields, like building area, you can add the areas of the combined features so that the resulting value in the field is the sum of the original values.
When working with complex data models it’s often difficult to know every field and how they should be populated. With field configurations you can add a text description of a field that will appear in the status bar in the ArcMap window or link a text file to a field with a more detailed description.
Feature-level metadata allows you to define fields on feature classes or tables that you want to automatically populate when a feature or table row is created or modified. For instance, all feature classes could include a CREATE_DATE field containing the date when the feature was created and a MODIFY_DATE field containing the date when the feature was modified. Both fields will be populated automatically based on the systems date and time. Feature-level metadata is defined using the field configurations.
In summary, Production Mapping provides many types of editing business rules; your goal is to identify those that make the most sense for your organization. What we’ve outlined above will give you a great starting point. In a future blog I’ll explore the cartographic business rules you can store and manage in product library.
Content contributed by Amber Bethell
