CU Library

This topic applies to Designer versions 10.0.2 and earlier.

Designer, through the ArcFM Favorites Manager, provides a means of defining and storing CUs in the geodatabase. CUs are persisted in the geodatabase in the same way as Favorites and can function in a similar fashion. The collection of CUs stored in the geodatabase is referred to as the Designer CU Library. Like favorites, the CUs stored in the library can be exported as an XML file to be imported into other CU Libraries.

Integrating WMS CUs and the Designer CU Library

In most implementations of Designer, a collection of CUs will likely exist in both the Designer CU library and the workflow management system (WMS). The dual locations are necessary so the WMS and Designer can work with CUs independently of each other. However, the implementation-specific WMS CU collection and the Designer CU library can be integrated with some customization.

When integrating the two CU collections, the implementer must determine which system will ‘drive’ the other. In other words, all CUs can be defined in one system which will then update the CU collection in the other system to reflect those additions or changes. A process could be developed that would synchronize the two CU libraries.

Designer provides a set of tools that will allow the CU definitions to be imported into and exported from the Designer CU library. See Importing and Exporting CUs in this section.

Using The ArcFM Favorites Manager to Define CUs

CUs are persisted in the geodatabase in the same way as Favorites and can function in a similar fashion. When Designer is installed, the ArcFM Favorites Manager will provide a separate tab that is used to define CUs.

CUs can be added or edited in the same way that favorites are, but with two additional parameters:

Code - identifies the CU in the Designer CU library.
WMS Code - Corresponds with the CU as it is stored in the WMS. This code is necessary for the CU to be saved back in the WMS from Designer.

CU-Defining Attributes

CUs are the building blocks of designs and have specific attribute values known as CU-defining attributes. These attributes designate the features of that specific CU (e.g., a pole's height and class). The CU's parent layer reflects the CU-defining values. CU-defining attributes are not editable by the user and displayed in ArcMap as gray.

The user may set specific fields for that CU as CU-defining fields in ArcCatalog. CU-defining fields allow the CU to 'drive' the attribute values of the feature to which it is assigned. Consider, for example, a 40-foot, class 1 wood pole:

Attribute

CU-defining field

Value

Wood Pole

Subtype

Wood

40 foot

Height

40

Class 1

Class

1

CU-defining fields are set for the SupportStructure feature class. With the CU-defining Fields set as indicated, the CU would appear in ArcMap as in Figure 1.

Figure 1, CU-defining fields

CU-defining fields are specified in ArcCatalog using the ArcFM Properties Manager. Any field of a feature class can be set as 'CU Defining.' This is done on the Field Info tab as shown in Figure 2.

Figure 2, Designation of CU-defining field in the ArcFM Properties Manager

In the design environment, fields designated as CU-defining will not be editable. This is so the CU and feature to which it is assigned are in synch with one another. For example, if a 40-foot class 1 wood pole CU is added to the design and the height, class, and material type attributes have been specified as 'CU Defining' in the ArcFM Properties Manager, then those attributes will not be editable in the ArcFM Attribute Editor. If the height attribute could be changed to another value, then the CU would be misrepresented in the design.

Attribute	CU-defining field	Value
Wood Pole	Subtype	Wood
40 foot	Height	40
Class 1	Class	1