Properties Generator v1.0

Object modelling guidelines

The following guidelines are to assist with the creation of the geometric/graphical object using a BIM authoring application, such as Revit or ArchiCAD. Guidance is also given to assist object creators in regards to file naming and IFC designation and property sets for object types that are not already included within the NATSPEC BIM Properties Generator.  

The aim of the guidelines below are to standardise and rationalise an objects graphical and non-graphical content, to improve its functionality and interoperability between BIM applications, and so as not to compromise the performance of the project model into which it may be placed. 

 

Object metadata

The following guidelines and general rules can be applied to objects (generic or manufacturer specific) being created that are not currently included in the Properties Generator.

IFC designation

To allow for improved interoperability between BIM authoring and BIM ready applications it is important to assign the correct IfcElementType and PredefinedType to an object. This information is provided for all the objects currently included in the Properties Generator. If creating objects currently not included in the Properties Generator, review the IFC4 schema (see ‘Resources’ tab above) to find the IfcElementType and PredefinedType relevant to the object being created and assign them to the object in your chosen BIM authoring application. For example, in Revit this would be done by completing the hard-coded property of ‘IfcExportAs’ with the relevant IfcElementType and completing the hard-coded property of ‘IfcExportType’ with the corresponding PredefinedType.

Using the example of a desk, the corresponding IfcElementType would be ‘IfcFurniture’ and the PredefinedType would be ‘DESK’.

If a defined IfcElementType, that reflects the object being created, cannot be found in IFC4, then the designation of ‘IfcBuildingElementProxy’ shall be used for the IfcElementType and the designation of ‘USERDEFINED’ shall be used for the PredefinedType. If using IfcBuildingElementProxy, then an additional property of ‘ElementType’ (or ‘ObjectType’ if using IFC2x3) shall be added to the object and the value completed with a descriptive name to define the object.

IFC properties

It is also important for interoperability to apply relevant IFC properties to the object being created. Most elements in the IFC schema have corresponding property sets (Pset_’s) and quantity take off property sets (Qto_’s). If a Pset_ of Qto_ exists for the object being created, then the properties from those sets should be added to the object properties. These property sets are often called common property sets and titled Pset_???Common, where ??? is the IFC element. For example, the common property set for a door is Pset_DoorCommon.

If the object represents a proprietary manufacturer product (or may be used to do so in the future) then the properties from the IFC property sets of Pset_ManufacturerOccurrence and Pset_ManufacturerTypeInformation should also be included.

Further property sets from the IFC schema can be added, if required, such as Pset_Asset, Pset_Condition and Pset_Warranty.

If the BIM authoring application being used includes hard-coded properties that are equivalent (but not identically named) to any of the IFC properties to be added to the object, then the hard-coded property may be used instead of the IFC property, provided that the hard-coded property is mapped to the corresponding IFC property when exporting the model to a different BIM ready application.

Other properties

If adding properties to an object, from a source other than IFC, name the properties using the Pascal Case (or Upper Camel Case) convention of having no space between each word and starting each word with a capital letter. e.g. SolarHeatGainCoefficient. Only use alphanumeric characters in the property name.

To provide for linking to a specification system it is also recommended to add the following three properties to the object being created:

-          ‘SpecificationCode’ - Value to be completed with the relevant specification numeric reference (code).

-          ‘SpecificationTitle’ - Value to be completed with the corresponding specification title.

-          ‘SpecificationSystem’ - Value to be completed with the name of the specification system being used.

Other properties recommended for inclusion are:

-          ‘CreatedBy’ - The name of the person, organisation or library provider that created the object.

-          ‘CreatedByURL’ - URL hyperlink to the object creator’s website.

-          ‘ModifiedIssue’ - To record the last date of issue (version or revision) of the object within an object library. Value to be completed in the following format <yyyymmdd.no> where the ‘no’ suffix is equal to the number of times the object has been issued on that date. For example, 20180316.01.

-          ‘Revision’ - For indicating the object revision within project model.

-          ‘Manufacturer’ - For objects that represent a proprietary manufacturer product (or may be used to do so in the future). Value completed with manufacturer name.

-          ‘ManufacturerURL’ - For objects that represent a proprietary manufacturer product (or may be used to do so in the future). Value completed with a URL hyperlink to the manufacturer’s website.

-          ‘ProductInformation’ - For objects that represent a proprietary manufacturer product (or may be used to do so in the future). Value completed with a URL hyperlink to further product information, such as technical documentation, installation guides, etc.

Where a property has a requirement to be completed with a particular value, such as some IFC properties or manufacturer object properties that represent the variants of a product, then limit the available values that can be used to complete the property value, by using a single fixed value, a list of values, or a bounded value or range.

Classification

Using the appropriate classification system for the project or the object library, assign a classification to the object using three properties to define the classification code, the classification title and the version of the classification system being used. An example of classifying an object, in this instance a desk, using the Uniclass Products table would be to add the three following properties to the object:

-          Uniclass2015ProductsCode: Pr_40_50_21

-          Uniclass2015ProductsTitle: Desks, tables and worktops

-          Uniclass2015ProductsVersion: 1.9

Multiple classification systems can be provided on any object by simply adding further properties, always using the three properties of Code, Title and Version for each classification added. So, another example, again for a desk, using Omniclass Table 23 would be:

-          OmniclassTable23Code: 23-21 11 11 23

-          OmniclassTable23Title: Commercial Desks

-          OmniclassTable23Version: 2012-05-16

If the BIM authoring application being used has hard-coded properties for the purpose of classifying the object, then they may be used in place of these suggested properties.

Links to the various classification systems can be found on the ‘Resources’ tab above.

 

Geometric/graphical object modelling

Note: For objects created using Revit, NATSPEC recommend following the geometric modelling guidelines detailed in the Australian and New Zealand Revit Standard (ANZRS). A link to the ANZRS documentation can be found in the ‘Resources’ tab above.

General modelling guidelines

The following general modelling guidelines are recommended:

-          Model the object at a scale of 1:1 using metric geometry in millimetres.

-          Establish an origin point (or insertion point) that logically represents the placement of the object in the project model. Particular attention needs to be given if the object has parametric geometry. For example, the origin point of a column would be best placed on the centreline of the column, to allow for the column size to be altered parametrically without changing the plan position of the column. BIM authoring applications usually require structural items to have their origin point in the centroid of that element to aid any analytical calculations that the model may be used for. Objects of similar type or form should always have matching origin points to aid swapping in and out in a project model.

-          Represent the physical form of the object’s external boundary without providing excessive or unnecessary detail. Important information such as connection points, openings or required clearance zones should also be included.

-          Use visual drafting conventions such as line types, hatching and fill to distinguish between different parts of the object and to show variances in depth of surface in different views.

-          Use the default colour of grey for objects that may be available in more than one colour, alternatively use a representative colour for the object.

Dimensioning and reference items

The following guidelines are recommended for dimensioning and reference items:

-          Constrain all dimensions to reference items, such as planes, lines or points, rather than directly to geometry. Dimensioning to geometry may not react in the manner expected. Derive dimensions automatically using the associative dimensioning functions within the BIM authoring application.

-          When providing objects with parametric geometry (i.e. geometry that can be manipulated by the metadata associated with the object), the parametric behaviour should be controlled by reference items.

-          Constrain all labels to reference items. Ensure all labels that reflect information contained within the object metadata, match such data.

-          Locate dimensions beyond the extents of the object geometry, making sure they do not overlap and are easy to read.

 

Object and file management

Object file naming

Structure the file name as follows:

<Type>_<SubType>_<Source>_<Product/RangeIdentifier>_<Differentiator>_<Originator>

Where the following naming field definitions apply:

-          <Type> = The object Type. e.g. ‘Insulation’.

-          <SubType> = The object Subtype. e.g. ‘Thermal’.

-          <Source> = Used only for proprietary manufacturer objects to identify the product manufacturer. The manufacturer name is usually used.

-          <Product/RangeIdentifier> = Used only for proprietary manufacturer objects to identify the product, or product range, that the object represents. The product code or product range name is usually used.

-          <Differentiator> = This is an optional naming field used, if required, to further differentiate the object in question. e.g. ‘FoilBacked’.

-          <Originator> = This is an optional naming field used for objects being created for inclusion in an object library, to readily identify the library provider of the object.

Use the PascalCase (or Upper Camel Case) convention for naming within each naming field. e.g. VexProWindows.

File size

To minimise the file size of the object and so as not to compromise the performance of the model into which the object may be placed, the following file management techniques are recommended:

-          Purge or delete all unused or temporary modelling content from the object, such as unused line types, reference items, construction lines or CAD content.

-          Compress the file size to a minimum and keep the use of arrays and voids within the object to a minimum.

-          Limit thumbnails and preview images to an appropriate size and resolution. All reference items and dimensions should not be visible in these images.

Functionality

To allow greater flexibility and correct functionality of the object, it is recommended to implement the following:

-          Model the object so as not to be reliant on any other object, unless it is a specific requirement of that object type that it requires a host object. An example may be a wall mounted light fixing, which would be reliant on the wall onto which it is to be placed.

-          Provide an object with parametric geometry when the object can represent variants of an object type. Limit the parametric capability of the object to the available variants of the product it represents. For example, if the product is available in 4 different lengths, limit the parametric length function of the object to those 4 available lengths.

Note: Do not provide parametric capability to allow the object to represent multiple IfcElementType’s. For example, do not create one object that can represent a bath and also represent a sink, as these objects are represented by different IfcElementType’s. In this situation create a duplicate object, one to represent a parametric bath and one to represent a parametric sink and designate each its correct IfcElementType.

-          Use fixed geometry where it Is not intended for the object to be modifiable. An example might be for a manufacturer object that is only available in one size.

-          Provide for viewing the object at different scales, controlling the information included in these views. In Revit the different scales are described as Coarse, Medium and Fine. Using the same terminology: Coarse is typically used for low detail, low fidelity elements, generally viewed at a scale above 1:100, and the geometry visible is only indicative of the element and may include symbolic linework; Medium is typically viewed at scales of 1:20 to 1:100 and the geometry visible should be sufficient to serve the purpose of resembling the real object; Fine is typically used for highly detailed elements, usually viewed at a scales of 1:1 to 1:20.