Merry Christmas and a Happy New Year
Prettige kerstdagen en een Gelukkig nieuwjaar!
Veselé vánoce a šťastný nový rok
Frohe Weihnachten und ein gutes neues Jahr
Froue Weihnåcht’n, und a guad’s nei’s Joah
Gleðileg jól og farsælt komandi ár
Buon Natale e felice anno nuovo
Hyvää joulua ja onnellista uutta vuotta
God jul og godt nytt år
God Jul och Gott Nytt År
Glæd Geol and Gesælig Niw Gear
Boas Festas e Feliz Ano Novo
¡Feliz Navidad y próspero año nuevo!
Wesołych świąt i szczęśliwego Nowego Roku
Linksmų Kalėdų ir laimingų Naujųjų Metų
С Рождеством! – Новым Годом!
COBie – Construction Operations Building information exchange – was developed in the US to collect information during design and construction, ready for handing over to the building operator. It is based on the buildingSMART IFC data model and derives from the FM handover model view definition.
FM Basic Handover – Exchange Requirements & Model View Definition
The COBie standard can be used in three formats: IFC SPFF, ifcXML and SpreadsheetML. The spreadsheet option makes it particularly attractive to less experienced users along the supply chain. COBie is an internationally recognised data specification. It can be implemented in commercial software and then used in construction projects. It enables each stakeholder to do their job as specified in the contract, but information is captured as it is created, not by a retrospective trawl through the files, and duplication of effort is avoided. The need for high-quality integrated information at the point of handover has long been recognised as a priority, and COBie was developed to meetthis need. The U.S. Army Corps of Engineers has been a prime mover in development and implementation, while over in the UK the government has approved the use of COBie in its fiveyear programme to secure full asset information in public projects.
It is important to know that the actual IFC file, whether it is an SPF (STEP Physical File) or XML representation, is always defined against a schema. The schema gives meaning (names and relations on top of the knowledge contained in the IFC file). The schema is static for all IFC4 files. It is published by buildingSMART as an EXPRESS schema and alternatively an XML schema.
Currently the latest version is the Release Candidate 4 of IFC4. It can be downloaded at:
IFC4 RC4 page
On top of the schema MVDs (Model View Definitions) are defined that describe what parts of the schema are used within a certain IFC file and/or extra restrictions on top of the schema. IFC4 is describing each instance of a building component that is contained in the IFC file. Click on picture for schema!
The instance contains semantic data like its name, description, type (wall vs. door), relations with other instances (connections to walls/other objects, opening elements), position and relation in the building structure as well as geometry and property sets. New to IFC4 is that each instance has also a type defined (in previous versions this was only valid for a subset of the instances). Non geometrical information can be attached to instances as well as to types.
Several instances can refer to the same type.
The position of instances is absolute or relative towards the position of another instance, these relative placements can be nested and several levels deep. Geometry of each visible instance is defined. It is however possible to reuse defined geometry from other instances.
Not all defined geometry in an IFC file is visible in CAD or viewers. For example space boundaries between walls and spaces are often defined but mostly not shown. Each instance can have more than 1 geometrical representation and a single 3D representation of an instance can have more than one color.
IFC4 files are full of relations. Many of these relations are inverse relations defined by the schema and not visible in the text view of an IFC file.
published by Peter P. Bonsma — on www.buildingsmart-tech.org