GIS Resources

If you check the GIS Resources box for Feature to Spec Mapping or Neutral Spec Mapping, the application exports the attribute sets that inform the “rules” for dynamic spec assignment (or “specs on the fly”) to an Excel table.

First, it is helpful to understand what these spec mappings accomplish. A “spec” is a term that describes the electrical specifications of a component, which are required for calculations and data fidelity. Specs are associated with CUs, so that the calculations and data fidelity are available for newly-added components in the design. This CU mapping occurs in the Spec to CU Relationship table.

But, what about the existing features that are brought into the design from the GIS? They are not CUs, and thus the Spec to CU Relationship table does not apply to them. How do the existing features receive a spec ID? That’s where these GIS Resource spec mapping tables come into play. The tables are used to assign the spec ID “on the fly” as the design components are extracted from the GIS and brought into the design via the Edge service.

What Do GIS Resources Look Like in the Excel Table?

In the GIS Resources Excel table, you supply the “rules” by mapping attribute fields to spec IDs. These inform the application which GIS fields to use when it assigns the spec ID to existing features being brought into the design.

For example, these are the fields that might be used to inform a transformer spec (this is just an example and customer fields vary):

This information is condensed into a single cell in the spec mapping Excel table:

RATEDKVA:15,HIGHSIDEVOLTAGE:12.5,LOWSIDEVOLTAGE:120/240,HIGHSIDECONFIGURATION:LG,LOWSIDECONFIGURATION:SP,PHASEDESIGNATION:1|2|4

That combination of attributes receives a spec ID in GUID format. As features are brought into the design, any transformer (in this example) that meets the above criteria receives that spec ID. Any transformer that does not would then be compared to other attribute combinations in GIS Resources. There would likely be several different combinations of attributes that inform an ID, and transformers would continue to be categorized by the service. Typically, a generic ID is applied if no other spec IDs matched the set of attributes for the transformer.

In the exported Excel table, the spec mapping tab includes the following columns:

• ID: This is a GUID for the mapping itself. It is not the spec ID, which has its own column.

  IMPORTANT: When bulk importing new feature to spec mappings, the ID is optional. If left blank, the application generates a new one upon import. In other words, you are not responsible for generating new GUIDs for new mappings. However, if using the Export/Import tools to either update or delete mappings, then the ID is required so the application knows which mappings to update or delete. The IDs are not case sensitive.

• 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.

  TIP: 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.

    TIP: 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.

  • 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.

• Related Object Attributes: This column establishes the rules for attributes stored at the related object class level.

  IMPORTANT:

  • Customers’ fields and where they store data vary. Some customers might store an attribute at the feature class level, and other customers might store the same field at the related object class level. Thus, the Excel table has two columns to accommodate either situation.

  • For the related object tables, the Schema must include the field that stores the relationship foreign key, which is the GUID of the parent feature class. This is how the service knows where to look when gathering attributes for dynamic spec assignment.

• 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.

When creating the concatenated list of attributes for Feature Attributes or Related Object Attributes, keep the following in mind:

• GIS Resources cannot import more than one field from the feature service into a single Designer XI component attribute.

• The format is {Esri Field}:{Value}. For example, RatedkVA:15. The “Field” is found in the “Fields” section of the feature layer in your feature service.

• The fields are comma delimited.

• 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.

• For null attributes, type a comma immediately after the colon (no space in between). For example, LowSideVoltage:, would apply to a feature where low side voltage was null.

• Do not use spaces.

• Use the bar | symbol as an “or” statement. For example, Subtype:1|2|4 would allow the GIS subtype or 1, 2, or 4.

Top to Bottom Order of the Mapping Rows when not Using the Order Column

If you choose to not use the Order column, spec mapping is processed in top-to-bottom order. The service uses the actual order of Excel rows, and the first match found is used to map the spec.

Further, the first spec mapping row per feature type is the default spec assignment. In the event that an imported feature does not match up with anything in your mapping resource, the service falls back to the default spec for the feature class.

If you would rather it not fall back to the first mapping (the default), then create a generic, “catch all” mapping as the last row per feature type. In this manner, unmatched features fall into the generic spec as opposed to receiving the default spec.