CU to Spec Mapping

CU to Spec Mapping is the process by which rules are generated to map CUs to the appropriate spec. Your implementation team has a specialized tool to perform this action. While the CU to Spec Mapping export functionality is visible, there is no functional need to check this option. See Prepare for Work Management System Integration.

The Workflow Resources check boxes are not filtered by any Equipment Types also checked. In other words, if you have poles checked and Export Type CU to Spec Mapping checked, your Excel tab of relationships still contains all the relationships in the system (it is not filtered to only show poles), and you get a separate tab showing all the pole equipment specifications (specs). In short, whatever you check creates its own Excel tab within the same exported Excel table.

What Does CU to Spec Mapping Look Like in the Excel Table?

In the exported Excel table, the Spec to CU Relationship tab includes the following columns:

• ID: This is the GUID for the relationship itself.

• Order: This field is optional, but it lets you determine the order in which specs should be compared and assigned. It accepts numeric values, starting at 0 and ending at the highest number required. For example, let’s say you have 12 attribute combinations for transformers. As a transformer is coming into the design, its attributes are compared to these 12 combinations, but which attribute combination should be compared to the GIS feature first? Second? Third? That is what the Order column dictates. See the next section below for more information if you choose not to use the Order column.

  NOTE: If you choose to populate the Order field, the attribute sets do not have to be in any particular top-to-bottom order in the Excel table. The Order field overrides the literal top-to-bottom order of rows. However, we recommend sorting by Feature Layer and Order before Importing the table. That way, you can easily scan through your attribute combinations and double-check your order to ensure there are no duplicate entries before importing.

  • The numeric value of 0 is the first attribute set compared. The set with 0 also becomes the default spec for that feature type. For example, let’s keep the same scenario going with 12 attribute combinations for transformers. Let’s say a transformer comes into the design, and it is compared to all 12 sets. However, none of the sets match the attributes for the transformer feature. In this case, it would “fall back” to the set with the value of 0 in the Order column. It takes on the “default” spec.

    NOTE: If you are seeing high numbers of imported features represented by the "default" spec, check the mapping first to see if it is correct. If it is correct, then consider correcting the GIS data to match the mapping rules.

  • The numeric values of 1 – n (the highest value), determine the comparison order after the default. The number of sets vary by customer.

  • The order value does not need to be unique.

  • If you would rather it not fall back to the default spec, then create a generic, “catch all” mapping as the nth or highest number per feature type. In this manner, unmatched features fall into the generic spec as opposed to receiving the default spec.

• Feature Layer: This is the name of the feature layer as defined in your feature service. It is not the table name in the geodatabase.

• Feature Attributes: This column establishes the rules for attributes stored at the feature class level. If the attributes you are using come from a domain in the geodatabase, you must use the coded values of that domain, not the descriptions of that domain.

• Spec ID: This is the GUID for the equipment spec. This spec GUID can be found by exporting the Equipment Type from the Catalog. These IDs can appear in the table multiple times because multiple attribute definitions can map to the same spec ID.