Multiple CUs per Feature

The design environment allows the assignment of multiple compatible units per GIS feature via the GU/CU architecture. For example, a linear feature might represent a three-phase primary conductor. This linear feature could represent multiple CUs that would comprise the conductor in the field. In the case of a three-phase conductor, three CUs would represent a conductor for each phase and another fourth CU could represent the neutral conductor. In Gas utility applications, a meter station might be modeled in the GIS as a single point but would actually consist of several related units. These related units would require multiple CUs in the design scenario.

How Designer Supports Multiple CUs Per Feature

At the base-product level, Designer supports the assignment of multiple CUs per GIS feature by decoupling the CU from the GIS feature that it may represent. Before 8.1, there was a one-to-one relationship between the CU and the GIS feature. Designer 8.1 and beyond uses the GU/CU architecture to allow many CUs to be associated to one GIS feature (GU).

In all past versions of Designer, the use of drag/drop functionality to place CUs in the Design tree is standard and is still used. In fact, it is extended to allow CUs to be dragged and dropped underneath existing GUs. This provides base-product support for placing multiple CUs per feature.

Editing CU Configurations

Where the base-product support for multiple CUs per feature is flexible and can be applied in all cases, additional implementation-specific requirements may exist for the management of GU/CU assembly for a specific feature class. Designer allows for the construction of Custom Configuration Editors that can perform these management tasks for a given GIS feature class.

Configuration Editors are written as ActiveX controls (OCXs) that implement the custom field editor interfaces (explained in the next section) and provide a user interface that facilitates the assignment of CUs to GIS features.

When to Build a Custom Configuration Editor

Again, the assignment of multiple CUs to GIS features is supported by Designer without any customization. However, there are a few cases that might warrant the development of custom configuration editors:

When attributes of several CUs collectively drive the attributes of the feature.
When the data model is not normalized; that is, when multiple CUs represent one feature in the GIS, but the relationship is not modeled as a normalized bank-unit relationship.
When contingent validity checking is required as the CUs are associated to the feature.

This discussion assumes a knowledge of the new CU architecture of Designer. This architecture agglomerates CUs underneath GIS Unit objects (GUs) that serve as a link from the GIS feature to the individual CUs that are associated to it. Figure 1 below shows the basic relationship between a GU and CUs.

Figure 1, GISUNIT object

Attributes of Feature Determined Collectively by Multiple CUs

With Designer’s standard functionality, a GU can have its own CU Defining Attributes (CUDAs) that drive the attributes of the feature to which the GU is associated. Alternatively, the GU can inherit (from below) the CUDAs on a CU contained by the GU if the CU has the same TABLENAME and SUBTYPE as the GU and if the Work Function of the CU is ‘Install.’ Figure 2 shows the CU object. The CUDAs on the CU will supercede those on the GU, again given the condition that the TABLENAME and SUBTYPE are the same.

Figure 2, CU Object

Non-Normalized Data Model

In some data models, the normalized bank/unit structure that can be applied to some feature classes is not used. Instead of storing the units as related records in the GIS, the attributes are stored with the feature. However, in the design scenario the units are important and must be modeled by separate CUs that comprise the actual feature modeled in the GIS. In such cases, it is necessary to create a custom configuration editor for the feature class to allow the user to assign multiple CUs to the feature.

Often in such cases, it is also necessary for the configuration editor to handle the mapping of CUDAs stored with the CUs to attributes on the feature.

Contingent Validity between the Feature Class and CUs

There may be cases where some CUs should not be associated with a certain type of GU. For example, a cable television joint-use attachment CU might be restricted from being associated to a GU representing a street light.

Cases of attribute contingent validity can usually be handled by the specification of CUDAs, but a custom configuration editor could also be employed to handle the contingent attribute validity as well.