Example: Infrastructure classification

by Raido Puust

In this section we carry out a basic classification on the example of infrastructure project, where we select one component, one technical system (including functional system reference designation), one built space and a construction entity. Autodesk Civil 3D template from the download section is in use (see the *.dwt file at download area, from which the previously described properties have been copied). In addition, the CCI-EE application table is used, which lists the types/subtypes used in the generation of reference designation codes.

Note. The types/subtypes given in CCI-EE application table must be based on a uniform set of rules, e.g., a distinct function that the element performs or some other, distinct aspect. Types/subtypes can always be specified with product-specific properties (additional properties), so the CCI-EE application table types/subtypes must not be viewed in the context of a product/manufacturer or based on some too specific property. However, in some cases, the distinguishing type/subtype can be the context of the material if such a distinction is very fundamental (e.g., environmental aspect). The CCI-EE application table presented here is owner-wide (applicable for different owner types – infrastructure client, building client, railroad client etc.). Meaning that if you look at the given application tables from the perspective of one specific owner, it is obvious that one does not need to expand all CCI/CCI-EE class codes into types/subtypes, but to work on with those that are important to them only.

Download the Autodesk Civil 3D sample model used in the example below (2023 version):
BridgeComponents-ENG-C3D2023_CCI-EE-2023.04.0.1.dwg

Note. The example file is currently classified only in the scope of the examples below. It is not a 100% correctly modeled file, so it is worth focusing on the individual components classified in the examples below.

Classification of a component

After importing properties related to CCI-EE classification into the active project, they are displayed in the Extended Data pane of the Properties dialog. At the same time, it must be emphasized that with later addition, the corresponding property groups must be included in the objects through the Add Property Sets dialog. The template includes one property group called A010_AdminCCI. As an example, let’s look at the classification of the top, pavement layer of the road according to CCI-EE.

Using Surface as a component example, we will go through the properties shown in the previous image (the construction layer can also be represented as a Solid component, which is derived from the Corridor model extraction):

AC175_cciCOcode – pavement layer key classifier (from CCI-EE <CO> table). No additions (numbers/letters) are allowed. In this example as: NCA

Note. This is what we select in the CLASSIFICATION section. Since it is a component, only in the extent of the component property (and not, for example, in the extent of the construction entity).

AC180_cciCOterm – concept supporting the key classifier as text (from CCI-EE <CO> table). In this example: Paving. Note that it is not displayed in the Properties palette by default, but it is visible in the Select Classification dialog. If desired, this property can be added to the A10_Administrative data template.

In essence, the basic level of classification is limited to those two parameters. It will be extended through the definition of reference designation system, which includes, among other things, the unique ID of the paving layer, the type ID. As well as the connection/relation to the type of technical system of the roadway, it’s unique ID, and from there to the desired main level (functional system, construction entity, built space, construction complex).

AT800_TypeNumber – it provides the type number derived from the type table (the CCI-EE application table, which is separate from the CCI-EE general table and may be established at the project / owner level). For example, in this example we write the value as 21, which indicates that it is a bitumen bound wearing course.

AT850_TypeDesignation – this property is based on the two previous ones – the type number and the classification of the component or element (so in this example as: NCA21). This property is important if you want to have a stand-alone parameter that focuses on the type/subtype aspect. This property is not needed in a situation where you want to move immediately to a reference designation property that also contains a type description part (see below). However, this property can be used, for example, to represent a type designation in a drawing.
AJ125_IDNumber – this property is associated with an element’s type/subtype, introducing the uniqueness of an element associated with a particular type/subtype. Therefore, it is worth emphasizing that this ID is not unique over the entire construction entity / project, but it is unique in the system of related elements (unique across the typical construction layers or unique in terms of the associated space (sample line group range) – in that case we can use the range of values 01-99, otherwise, if we would like to see this value across the construction entity, we may run out of available ID numbers (there could be hundreds of components with the same type in one construction entity). In this example as: 01
AR200_ReferenceDesignation – this property summarizes the key classifier, type identifier and ID number and is written according to the scheme given in the CCI-EE guidelines. The sequence is: CCIcode+IDnumber % CCIcode + type number. The last part is also available as an AT850_TypeDesignation property value. So, in our example: NCA01%NCA21 (% represents the part where the reference to the type starts, see the CCI-EE guidelines).
AM945_MultiLevelRD – in this example it is empty because there is no other related component associated within the road layer (e.g., referring to the markings on the roadway, etc.)
AR225_ReferenceDesignationSet – this field contains the reference designation of current component (AR200_ReferenceDesignation) and the reference designations at higher levels (hence the name – reference designation set). For example, with the component, the reference code of the corridor will be added (as a technical system, part of a functional system), and you can also put reference designation parts of the construction entity and construction complex. In this example given as:
-A1001.AA1001.NCA01%NCA21 (see the description below regarding the technical/functional system, as this part must be derived from the road corridor reference to which the road layer belongs to). Note that the reference designation set can also be presented as “smaller bites”, for example without a construction entity/complex. The CCI-EE manual describes when to use the “-” sign and when to use the “+” sign. In addition, we may wish to refer to the reference designation of the space within that reference designation set. The context of “placement” or “location” must be distinguished. For example, with the road sign, we are talking about the context of the placement. While a component in space can be referenced as from the context of the location (in which case “++” or double plus sign is used). Several reference designation sets can be added under one property, but in this case, those should be separated with the “/” sign.
-A1001.AA1001.NCA01%NCA21/+<CS>FAA$$$$

Note. The reference to the carriageway (FAA) is an additional reference, therefore the “/” delimiter is used and we also use the table reference to delimit that we are talking about the code part of the built space (there is no point in rewriting the entire part that follows, separated by the construction element and the “-” sign, because it has already been added beforehand). In this case, it makes sense to use the table reference. On the other hand, we could also integrate them under one code, where we start with the “+” sign, then adding a construction space reference, followed by a construction complex, construction entity and finishing up with “-” part as shown already (this is also explained in the CCI-EE guide). However, it has been said that the representation of the reference designation set should be viewed based on the exchange information requirements. And sometimes, chunking works better than writing everything in one line.

Classification of a technical system (corridor example)

In the following image, a corridor object is selected, which we have classified as the technical system. This technical system includes all separate construction layers, for example, including the bitumen bound wearing course that was previously classified. Let’s look at what properties must be filled in (minimally) for the corridor as a technical system.

AC165_cciCTcode – the main classifier of the corridor (from the CCI-EE <CT> table). No other letters/numbers can be added to it. Noted here as: AA

Note. This is what we select in the CLASSIFICATION section. Since it is a technical system, only in the extent of the technical system property (and not, for example, in the extent of the construction entity).

AC170_cciCTterm – concept supporting the key classifier as text (from CCI-EE <CO> table). In this example: Pavement construction. Note that it is not displayed in the Properties palette by default, but it is visible in the Select Classification dialog. If desired, this property can be added to the A10_Administrative data template.

In essence, the basic level of classification is limited to those two parameters. It will be extended through the definition of reference designation system, which includes, among other things, the unique ID of the technical system, the type ID. As well as the connection/relation to the type of functional system of the roadway, it’s unique ID, and from there to the desired main level (construction entity, built space, construction complex).

AT800_TypeNumber – it provides the type number derived from the type table (the CCI-EE application table, which is separate from the CCI-EE general table and may be established at the project / owner level). For example, in this example we write the value as 10, which indicates that it is a paving system.

AT850_TypeDesignation – this property is based on the two previous ones – the type number and the classification of the construction element (so in this example as: AA10). This property is important if you want to have a stand-alone parameter that focuses on the type/subtype aspect. This property is not needed in a situation where you want to move immediately to a reference designation property that also contains a type description part (see below). However, this property can be used, for example, to represent a type designation in a drawing.
AJ125_IDNumber – this property is associated with an element’s type/subtype, introducing the uniqueness of an element associated with a particular type/subtype. Therefore, it is worth emphasizing that this ID is not unique over the entire construction entity / project, but it is unique in the system of related elements (unique across technical systems that belong to some functional system). In this example as: 01
AR200_ReferenceDesignation – this property summarizes the key classifier, type identifier and ID number and is written according to the scheme given in the CCI-EE guidelines. The sequence is: CCIcode+TypeNumber+IDNumber. The fist part is also available as an AT850_TypeDesignation property value. So, in our example: AA1001 (if the ID has not yet been specified, it can also be represented as AA10$$, where $$ represent a placeholder for the ID value).
AM945_MultiLevelRD – in this example, it is not used because there is no other technical system associated with the corridor (e.g., we may wish to refer to underground building system with AA10, for example AA10.BA10 – BA10 comes from the list of a separate type/subtype list).

AR225_ReferenceDesignationSet – this field contains the reference designation of current technical system (AR200_ReferenceDesignation) and the reference designations at higher levels (hence the name – reference designation set). For example, with the technical system, the reference code of the functional system is added, and you can also put reference designation parts of the construction entity and construction complex. In this example given as:
-A3201.AA1001 (in here the type and ID of a functional system is also included, type number 32 or type designator A32 can be seen below)

Classification of a construction space

…

Classification of a construction entity

Using Autodesk Civil 3D as an example, to represent a construction entity or a construction complex, you should create a separate generic component that defines the scale of the construction. A group of functional systems can also be used for this purpose, but it is important that we can independently define the construction entity as a whole. For example, it is not correct that we include this coding under CLASSIFICATION section once a selected component is already classified through a component or technical system level. In other words, in the CLASSIFICATION section presented in the image below, there is a line for defining the construction entity, but we use this part of the dialog so-called once (only for the component, only for the technical system, etc.) and in the reference designation set we can bring other, higher levels into play (including the construction entity). Otherwise, key classifiers will be created twice (at different levels) and thus it is not easy to understand what is meant by one or another component when exchanging information.

Note. The CLASSIFICATION section should always have only one line related to the CCI context, not several!

Note. If we go back to the construction component / technical system for a moment, we can also add the CCI-EE code of the construction entity / complex to the reference code there. In this case, we need to do this for each individual element to ensure uniformity of data presentation. You can use both, writing as a single code line (see the CCI-EE manual) or separating individual pieces of code with the “/” separator.

However, to give context, it is also good to visually show how the project is divided into parts (construction entities). So, below is a generic geometric object that summarizes a specific infrastructure construction entity (a separate entity is, for example, a bridge/viaduct, and for that we would make another volumetric object around the bridge/viaduct). The construction complex is represented through the reference designation set.

AC145_cciCEcode – classification of the construction entity, as a road (from CCI-EE <CE> table). No other letters/numbers can be added to it. Noted here as: RA
AC150_cciCEterm – a description supporting the classification of the selected construction entity class code (from CCI-EE <CE> table). It is not displayed separately but can be seen in the selection of the CLASSIFICATION section and can also be highlighted as a separate property in the A010_Administrative data template. Here in the example: Road
AC135_cciCCcode – classification of the construction complex (from CCI-EE <CC> table). No other letters/numbers can be added to it. Noted here as: R. We do not fill this in a separate property, but we use it in the reference designation set: R$$$$.RA$$$$
AC140_cciCCterm – a description supporting the classification of the selected construction complex class code (from CCI-EE <CC> table): Traffic complex. It is not presented as a separate property

Note that the type number and ID number are currently unknown, so these parts are marked as $$, or numeric placeholders. While the blank text part has a # (related to the description of type).

With this, we have presented an example of classification logic based on Autodesk Civil 3D. The components are different and thus the previously discussed principles must also be used in the classification of other objects. The software specifics and template structure are described in a later section.