Author Topic: Best practices for model set-up  (Read 31 times)


  • Administrator
  • Newbie
  • *****
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Best practices for model set-up
« on: May 10, 2017, 03:30:16 pm »
Found this on MT Hojgaard's website - simple yet effective. Could almost replace most PxPs found today  ;D

gotta lov the openness and willingness to share!

1. The model consists of objects
The Building Information Model consists of objects that represent building components. Each object represents one and only one building component. No generic objects or models-in-place may be used.
2. Identical coordinate system, modular grid and reference points in all models
All project models without exception must be based on one and only one shared coordinate system for X and Y coordinates, and one and only one approved levels system for the Z axis. Rotation to true north must also be identical for all project models. The purpose is to facilitate the generation of shared models based on the many different discipline models.
3. Objects must be used for their purpose
BIM models are built from objects that represent building components, and the objects must be used for their purpose/function only. This means that, for instance, wall objects may be used only for walls and not for the modelling of small decks or beams. This principle applies to all objects.
4. No object overlap
The geometry of the different building components must not take up the same space. Models must be coordinated so as to eliminate object overlap. Nor may there be any duplicate objects on top of each other.
5. Not different object types for the same purpose
Objects with the same operation (function/purpose) must be represented by one and the same type.
6. Consistent object naming
First and foremost, it is important to ensure consistency in the naming of objects by using an SfB, BIM7AA or other classification code. At MT Højgaard we use an object naming standard. See MT Højgaard’s CAD_BIM Manual for more details. Object naming data must be typed in one data field for all building components (such as Typemark) and must not be entered in different fields.
7. Drawings are extracts from the models
Drawings should be retrieved from the model. It is only natural that there are details in 2D. But 2D drawings may not contradict the 3D model. Details are made directly and preferably on the basis of the 3D model. For instance, a door should not be visible only in a 2D model, or conversely, only in the 3D model. The scope of information not being available in the model must be specified with reference to the ICT appendix to the conditional consultancy agreement.
8. Models have properties
Models have properties (relevant data added at building component level) which are to follow cross-disciplinary consistent naming practices. Naming and necessary properties are defined as a part of the VDC deliverables.
9. The model is divided for production
For example, pillars are divided according to floors, decks are divided into components or cast sections, but the method applies to all building components. Waste or different/deviating margins are not taken into consideration and should be accounted for elsewhere, for instance in the description.
10. Objects are connected to the right floor
Objects that represent building components are connected to the floor they belong to and thus indicate the specific and not an arbitrary location. Moreover, objects are controlled by an off-set.
11. The model has space objects with information
The model contains meaningful ”rooms” or ”spaces” which represent rooms and zones in the model. These objects must contain consistent information about room type and/or function as well as numbering and any basic information about the defined building components such as surface areas of the different types of building components and their surface materials.
12. Objects have classification codes
Each object has a classification code as a property. The code must be represented in an approved system which can contain all building components in the relevant project. It must also be possible to see the code in the project bill of quantities and in descriptions.

Social Buttons