├── Discussion ├── IFC4-IfcTesselationItem_V3.pdf └── IFC4-Tessellated-Geometry.pptx ├── IFC4_DesignTransfer_View.md ├── IFC4_Library_View.md ├── IFC4_Reference_View.md ├── README.md ├── Schedule └── Readme.md └── Scope ├── P2 DetailedScopeIFC4CoordinationView V0.4.pdf ├── P2 DetailedScopeIFC4CoordinationView V0.5.pdf ├── P2 DetailedScopeIFC4CoordinationView V0.6.pdf ├── P2 GeneralScopeIFC4CordinationView 20140221.pdf ├── P2 GeneralScopeIFC4CordinationView 20140423.pdf └── README.md /Discussion/IFC4-IfcTesselationItem_V3.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/buildingSMART/IFC4-CV/ed56220fede51a33eb10ba58b010eb9594bb2819/Discussion/IFC4-IfcTesselationItem_V3.pdf -------------------------------------------------------------------------------- /Discussion/IFC4-Tessellated-Geometry.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/buildingSMART/IFC4-CV/ed56220fede51a33eb10ba58b010eb9594bb2819/Discussion/IFC4-Tessellated-Geometry.pptx -------------------------------------------------------------------------------- /IFC4_DesignTransfer_View.md: -------------------------------------------------------------------------------- 1 | # Foreword 2 | 3 | To be updated from [standard foreword boiler plate text] (http://www.buildingsmart-tech.org/ifc/IFC4/final/html/foreword.htm) 4 | 5 | # Introduction 6 | 7 | ## Purpose 8 | 9 | The overall goal of the Design Transfer View is to provide building information with support for editing of interconnected elements. Such applications enable inserting, deleting, moving, and modifying physical building elements and spaces. The target scenario is an architect providing building design information to an engineer for a particular discipline, where geometric modifications may need to be made. 10 | 11 | To enable such editing, higher-level design parameters must be preserved, and applications must generate downstream geometry consistently according to such parameters. The scope of parameters is limited to those that impact interconnected elements: for example, increasing window dimensions impacts composition of walls; moving walls impacts geometry of connected walls, adjoining spaces, coverings, and embedded elements; adjusting pipes or ducts may require resizing openings. The scope of parameters does NOT include those that only impact a specific element (e.g. stair tread dimensions) -- such scope is reserved for a Library Model View currently defined as illustrative. All geometry is supported in the Design Transfer, including Constructive Solid Geometry (CSG) and new Non-Uniform Rational B-Spline (NURBS) geometry defined in IFC4 for precisely describing arbitrary curved surfaces. 12 | 13 | ## Objective 14 | 15 | ## Compatibility concerns 16 | 17 | As the Design Transfer View is intended to be compatible with the IFC2x3 Coordination View, every effort will be made to retain such compatibility while supporting new IFC4 concepts where applicable that enhance editing capability (e.g. IfcMaterialProfileSet, IfcAdvancedBrep). 18 | -------------------------------------------------------------------------------- /IFC4_Library_View.md: -------------------------------------------------------------------------------- 1 | # Foreword 2 | 3 | To be updated from [standard foreword boiler plate text] (http://www.buildingsmart-tech.org/ifc/IFC4/final/html/foreword.htm) 4 | 5 | # Introduction 6 | 7 | ## Purpose 8 | 9 | The overall goal of the IFC4 Library View is to provide building information that may be fully edited by design applications independently of any specific parameters or formulas for calculating geometry. 10 | 11 | To enable such editing, geometric attributes are bound to formulas based on higher-level parameters. While this model view provides examples of parameters at particular elements, it does not require specific parameters; rather the originating application may encode formulas used for generating the geometry and downstream applications may re-use such formulas for regenerating geometry. The IfcMetric and IfcAppliedValue entities [expanded in IFC4] are used for representing such formulas. Attributes may be bound to formulas based on arithmetic operations of other parameters and tables of available configurations. Elements may be decomposed into parts dynamically where the count and placement may vary according to formula. Moveable parts may also be described (e.g. drawer sliding, door opening). Such capabilities should fully support parametric behavior that can be described in existing design-related applications (e.g. Sketchup). Examples of usage include floor tiles (defining dimensions, texture, pattern, boundary, etc.), framed walls (stud type, stud spacing, plate type, axis path, etc.), junction boxes (number of gangs), concrete columns (rebar count, rebar cover, etc.), and virtually any product having multiple configurations. 12 | 13 | The Library View is currently out-of-scope, but is described herein to better illustrate how the other Model Views relate and how they may fit into future roadmaps. 14 | -------------------------------------------------------------------------------- /IFC4_Reference_View.md: -------------------------------------------------------------------------------- 1 | # Foreword 2 | 3 | To be updated from [standard foreword boiler plate text] (http://www.buildingsmart-tech.org/ifc/IFC4/final/html/foreword.htm) 4 | 5 | # Introduction 6 | 7 | ## Purpose 8 | With the publication of the IFC4 release, that has been accepted as ISO16739 by the International Standardization Organization, several enhancements and improvements over the previous IFC releases are now available for improved open BIM interoperability using the IFC protocol. 9 | 10 | The main purpose of this document is to define a standardized subset of the IFC4 schema, a Model View Definition MVD, that is particularly suitable for all BIM workflows that are based on reference models, where the exchange is mainly one-directional. Here requested modifications of the BIM data, mainly of the shape representation, are handled by a change request to the original author, and changes ae not executed upon the imported IFC data with the intent to be sent back to the original source. 11 | 12 | Examples of this reference workflow are: 13 | - Coordination planning (combining different discipline specific IFC models for visual checking) 14 | - Clash detection (finding clashes between different discipline specific IFC models) 15 | - Background reference (loading an IFC model, usually from a different discipline) as a linked model 16 | - Quantity take-off (determine the quantities of the various model elements with the IFC model) 17 | - Construction sequencing (taking the IFC model and associating it to a construction schedule) 18 | - Visual presentation (for presenting the IFC model to a broad audience) 19 | 20 | Common characteristics of the workflow using reference models are: 21 | - The source of the BIM information remains with the originator 22 | - The full parametric behaviour, and thereby the intellectual engineering property, remains with the originator 23 | - The ownership of the model, and responsibility for its correctness, remains with the originator 24 | - The original model is published as IFC4 Reference View model reflecting the as-is status 25 | - The receiver of the IFC4 Reference View model has access to the full model content 26 | - The receiver of the IFC4 Reference View is not supposed to modify the model 27 | - The receiver of the IFC4 Reference View can analyse and extract the information of the model 28 | - If the receiver suggests or demands a change, it has to be communicated as a change request to the originator 29 | - The buildingSMART standard BCF (BIM Collaboration Format) is developed to efficiently support these change requests. 30 | 31 | The Level of Detail of the shape representation and the Level of Information for the property content of the actual reference models depends on the source model. The buildingSMART standard IDM (Information Delivery Manual) can be used to determine the minimum content for a particular workflow support. The IFC4 Reference View allows rich content to be published, see next chapter Objective for more details. 32 | 33 | ## Objective 34 | The main objective of the IFC Reference View is the widest possible proliferation of IFC BIM data across a big range of software application types supporting different communication and collaboration workflows. 35 | 36 | The IFC Reference View is characterized by the ability to publish BIM data following that subset of IFC definitions that enables semantically rish content of building data, and to some degree also other built environment data, to be exchanges with a streamlined geometric representation that is optimized for analysis and display, but excludes dimension-driven geometric parameters. The geometric representation is therefore suitable for all workflow scenarios, where the imported IFC model is displayed, analysed, compared, clashed, but not parametricly modified for futher work processes. 37 | 38 | Semantic building data models being exchanged using the IFC4 Reference View would typically include: 39 | - physical elements with explicit geometry, properties, quantities, material, and classification 40 | - types of elements with associated physical elements to group common definitions (geometry, properties, material, and classification) 41 | - spatial elements (spaces, zones) with explicit geometry, properties, quantities, and classification 42 | - spatial structure elements (site, building, story), but also spatial zones for non-vertical construction 43 | - element breakdown structure between physical elements (assemblies, sub-assemblies, parts) 44 | - spatial breakdown structure between spatial elements (spatial decomposition of building, story or zones) 45 | - spatial containment structure between spatial elements and physical elements (elements in spatial zone) 46 | - logical system structure and assignment (physical elements assigned to systems and sub systems) 47 | - topological structure of system networks (element to port, and port to port, relationship) 48 | - common context of the building model, providing units, coordinate system and GIS positions 49 | - general object identification using globally unique identifier 50 | 51 | Additional capabilities for enriching the semantic information exposed by the IFC4 Reference View can be defined as an Add-on Model View Definition. Forseeable examples are capturing 4D models with the addition of the work schedule related entities, or 5D models with the addition of construction resource related entities. 52 | 53 | ## Workflow support 54 | The overall goal of the IFC Reference View is to provide workflows where building information models are to be consumed by the widest array of software applications that do not require modifying geometry. Such applications enable viewing, estimating, building, operating, and other downstream analysis. 55 | 56 | > EXAMPLE One target scenario is an architect providing building design information to a contractor or facility manager. It is expected that the resulting geometry would reflect sufficient realism for viewing in software (dimensions, normals, colors, textures), but not of rendering quality for artistic presentations (lighting, shader effects, curve interpolation, rasterizing). 57 | 58 | To support the widest array of consuming applications, the resulting schema should be as limited as possible for representing geometry in the interest of minimizing resources required of application developers. Such schema should also be as compact as possible to enable downstream use on mobile devices with limited network bandwidth. It is proposed that the resulting geometry is limited to triangles with normal vectors, colour and texture coordinates and simple sweeped solids with applied colour and texture. 59 | 60 | ## Compatibility concerns 61 | 62 | As the IFC4 Reference View is new (there is no corresponding concept in the IFC2x3 Coordination View), there is no constraint for compatibility, and the resulting schema will leverage new triangulation definitions in IFC4 to support more efficient data transfer. 63 | 64 | The second Model View Definition that is proposed in parallel to the IFC4 Reference View, the IFC4 Design Transfer View, is an extension of this model view. In other words, the IFC4 Reference View is a true subset of the IFC4 Design Transfer View. 65 | 66 | Complying software interfaces, that implements import of the IFC4 Design Transfer View, shall also be able to correctly import IFC4 Reference View data sets. But not vice versa, a complying software interface, that implements import of the IFC4 Reference View will not be capable to import IFC4 Design Transfer View data sets. It is however required that a compliant software interface for importing IFC4 Reference View displays an agreed error messange showing the IFC version, and the IFC Model View Definition of the imported IFC file, that does not match "IFC4 Reference View" with an explanation, that a non-compatible IFC file has been received. 67 | 68 | > NOTE The correct error message and the link to further information on the buildingSMART website explaining the purpose of the different IFC Model View Deinitions need to be agreed upon. 69 | 70 | # 1 Scope 71 | 72 | ## 1.1 General scope definition 73 | The general scope defines the main functionalities of the IFC4 Reference View as an overview. It includes a complete listing of the model elements and model element types that are included in the IFC4 Reference View MVD. 74 | 75 | > NOTE The Model elements are refered to in MVD as root concepts, being the indivudual root elements, that contain the attributes, geometric shapes, dynamic property sets and other semantic information. 76 | 77 | The detailed scope of the IFC4 Reference View is determined by the concept templates that are included. A detailed description of each concept template is provided by "4 Fundamental concepts and assumptions". 78 | 79 | ## 1.2 Model elements 80 | The main components of the IFC4 Reference View are the semantic model elements that carry a predefined meaning. The complete breakdown of all model elements declared in IFC4 are also known as the IFC4 built-in classification following an element by function classification. 81 | 82 | In addition to each of the Model elements shown here in the subsequent tables, each Model element maybe further specialized by its "_PredefinedType_", or even a user defined type. 83 | 84 | > EXAMPLE An _IfcFireSuppressionTerminal_ is a specific Model element, that may be further specialized using its _PredefinedType_ Enumeration to be: a sprinkler, a hose reel, a fire hydrant, or a breeching inlet. If a proper predefined type is not yet included, a user defined type can be assigned as well. 85 | 86 | **Architectural model elements** 87 | 88 | | shell and core | finishing | furnishing 89 | |------------------|--------------------|----------- 90 | | _IfcBeam_ | _IfcCovering_ | _IfcFurniture_ 91 | | _IfcColumn_ | _IfcRailing_ | _IfcSystemFurnitureElement_ 92 | | _IfcChimney_ * | _IfcShadingDevice_ | - 93 | | _IfcRamp_ + | _IfcCurtainWall_ | - 94 | | _IfcStair_ ++ | _IfcDoor_ | - 95 | | _IfcRoof_ | _IfcWindow_ | - 96 | | _IfcSlab_ | - | - 97 | | _IfcWall_ | - | - 98 | 99 | > Legend: * new in IFC4, + includes IfcRampFlight, ++ includes IfcStairFlight 100 | 101 | 102 | **Structural model elements** 103 | 104 | | Foundation & Frame | Reinforcement | Fastener, etc. | 105 | |----------------------|----------------------|----------------| 106 | | _IfcFooting_ | _IfcReinforcingBar_ | _IfcFastener_ 107 | | _IfcPile_ | _IfcReinforcingMesh_ | _IfcMechanicalFastener_ 108 | | _IfcMember_ | _IfcTendonAnchor_ | _IfcBuildingElementPart_ 109 | | _IfcPlate_ | _IfcTendon_ | _IfcDiscreteAccessory_ 110 | 111 | > NOTE: Architectural elements, like IfcWall, IfcSlab, IfcBeam, etc, are also used in structural models, and vice versa 112 | 113 | **Building service model elements** 114 | 115 | The model element specialization structure within the building service domain within the IFC standard is organized accoring to its function within a distribution system, and not primarily according to the main building service discipline, within it is mainly used. 116 | 117 | The internal specialization structure for building service elements at its highest level is also independed of the fluid used within the distribution system: 118 | - flow segments 119 | - flow fittings 120 | - flow terminals 121 | - flow moving devices 122 | - flow storage devices 123 | - flow controller 124 | - energy conversion device 125 | - distribution control elements 126 | 127 | The following tables intents to assign the model elements to the various disciplines within the building service system domain. 128 | 129 | | general MEP elements | used for gases and fluids | ports for connectivity | 130 | | ------------------------|-----------------------------|------------------------| 131 | | _IfcEngine_ * | _IfcFlowMeter_ * | _IfcDistributionPort_ | 132 | | _IfcMedicalDevice_ * | _IfcFilter_ * | - | 133 | | _IfcUnitaryEquipment_ * | - | - | 134 | 135 | 136 | | Heating, Cooling | Plumbing | Common | 137 | |----------------------|--------------------------------|----------------| 138 | | _IfcBoiler_ * | _IfcFireSuppressionTerminal_ * | _IfcPipeSegment_ * 139 | | _IfcBurner_ * | _IfcInterceptor_ * | _IfcPipeFitting_ * 140 | | _IfcCoil_ * | _IfcSanitaryTerminal_ * | _IfcPump_ * 141 | | _IfcSpaceHeater_ * | _IfcStackTerminal_ * | _IfcValve_ * 142 | | _IfcTubeBundle_ * | _IfcTank_ * | - 143 | | - | _IfcWasteTerminal_ * | - 144 | 145 | 146 | | Ventilation | Air conditioning | Common 147 | | ----------------------|-----------------------------|------- 148 | | _IfcAirTerminalBox_ * | _IfcAirToAirHeatRecovery_ * | _IfcDuctSegment_ * 149 | | _IfcDamper_ * | _IfcChiller_ * | _IfcDuctFitting_ * 150 | | _IfcDuctSilencer_ * | _IfcCondenser_ * | _IfcAirTerminal_ * 151 | | - | _IfcCooledBeam_ * | _IfcFan_ * 152 | | - | _IfcCoolingTower_ * | - 153 | | - | _IfcEvaporativeCooler_ * | - 154 | | - | _IfcEvaporator_ * | - 155 | | - | _IfcHeatExchanger_ * | - 156 | | - | _IfcHumidifier_ * | - 157 | | - | _IfcCompressor_ * | - 158 | 159 | 160 | | Electrical | cont. | Common 161 | |----------------------------------|-------------------------------|------- 162 | | _IfcElectricAppliance_ * | _IfcAudioVisualAppliance_ * | _IfcCableSegment_ * 163 | | _IfcElectricDistributionBoard_ * | _IfcCommunicationAppliance_ * | _IfcCableFitting_ * 164 | | _IfcElectricGenerato_r * | _IfcJunctionBox_ * | _IfcCableCarrierSegment_ * 165 | | _IfcElectricMotor_ * | _IfcLamp_ * | _IfcCableCarrierFitting_ * 166 | | _IfcElectricStorageDevice_ * | _IfcLightFixture_ * | - 167 | | _IfcElectricTimeControl_ * | _IfcSolarDevice_ * | - 168 | | _IfcMotorConnection_ * | _IfcSwitchingDevice_ * | - 169 | | _IfcProtectiveDevice_ * | _IfcTransformer_ * | - 170 | 171 | 172 | | Building automation | cont. | cont. 173 | |-------------------------|-------------------------------------|------ 174 | | _IfcActuator_ * | _IfcFlowInstrument_ * | _IfcSensor_ * 175 | | _IfcAlarm_ * | _IfcProtectiveDeviceTrippingUnit_ * | - 176 | | _IfcController_ * | _IfcUnitaryControlElement_ * | - 177 | 178 | > Legend * new in IFC4, note all building service occurrence elements are new, the previous IFC2x3 release only included the generic occurrence elements: _IfcFlowSegment_, _IfcFlowFitting_, _IfcFlowTerminal_, _IfcFlowMovingDevice_, _IfcFlowStorageDevice_, _IfcFlowController_, _IfcEnergyConversionDevice_ and _DistributionControlElement_. Those are still available as general purpose MEP Model elements, but its use is discouraged. 179 | 180 | 181 | **Other model elements** 182 | 183 | | Other elements | 184 | |----------------| 185 | | _IfcBuildingElementProxy_ + 186 | | _IfcCivilElement_ *++ 187 | | _IfcGeographicElement_ * 188 | | _IfcDistributionChamberElement_ 189 | | _IfcElementAssembly_ 190 | | _IfcTransportElement_ 191 | 192 | > Legend: * new in IFC4, + also used as general element proxy ++ provided as stub for future infrastructure extensions 193 | 194 | 195 | **Spatial elements, spatial structure and grouping elements** 196 | 197 | | Spatial structure | other grouping structure | others | 198 | |---------------------|----------------------------|---------| 199 | | _IfcSpace_ | _IfcZone_ | _IfcGrid_ 200 | | _IfcBuildingStorey_ | _IfcSystem_ | - 201 | | _IfcBuilding_ | _IfcBuildingSystem_ * | - 202 | | _IfcSite_ | _IfcDistributionSystem_ * | - 203 | | _IfcSpatialZone_ *+ | _IfcDistributionCircuit_ * | - 204 | | - | _IfcGroup_ | - 205 | 206 | > Legend: * new in IFC4, + provided as a stub for non vertical constructions 207 | 208 | 209 | ### 1.3 Model element types 210 | Model element types are part of the IFC4 Reference View. They enable to describe and share common model element information that are shared by multiple occurrences of the same type. Sharable type information includes: 211 | - Geometric shape representation; 212 | - Property information; 213 | - Material information. 214 | 215 | > EXAMPLE: A particular air outlet as an article, with its shape, its material and its manufacturer information being described once as a type and then having several occurrences, each placed within the building, referencing the same type and hence its shape, material and properties. 216 | 217 | Most of the Model elements introduced in the previous session have a corresponding Model element type, such as _IfcWall_ - _IfcWallType_, _IfcFastener_ - _IfcFastenerType_, _IfcFan_ - _IfcFanType_. Only the following spatial structure elements _IfcSite_, _IfcBuilding_, _IfcBuildingStorey_, the grouping elements _IfcGroup_, _IfcZone_, _IfcSystem_ (and subtypes), and the _IfcDistributionPort_ and _IfcGrid_ do not have matching element types. 218 | 219 | 220 | ## 1.4 Overview on major concepts used 221 | 222 | ### 1.4.1 Object attribute 223 | All model elements, listed in the previous section, are defined by several generic and direct object attributes, some specific model elements do carry additional direct attributes. The usage of the direct generic attributes is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"): 224 | - "_Software Identity_", it defines how to apply the Globally Unique Id and how to compress it during exchange; 225 | - "_User identity_", it defins the meaning of _Name_, _Description_, _LongName_ and _Tag_ attributes; 226 | - "_Object Occurrence Predefined Type_", it defines how to use the _PredefinedType_ and in case of user defined types, how to assign the user defined type information within the _ObjectType_ attribute for occurrences of model elements; 227 | - "_Element type predefined type_" it defines how to use the _PredefinedType_ and in case of user defined types, how to assign the user defined type information within the _ElementType_ attribute for types of model elements. 228 | 229 | 230 | ### 1.4.2 Project context 231 | There is a single instance of _IfcProject_ within each IFC data set. It sets the context for the exchange, including units, geometric context, global positioning and classification systems used within the data set. The usage of the project context is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"): 232 | - "_Project Units_", declaration of the units used within this data set, all geometric representations are forced to use the global units (e.g. for length measure and plane angle measure), property values may override global unit declarations; 233 | - "_Project Representation Context_", declaration of the 3D and 2D representation contexts, including precision factors; 234 | - "_Project Global Positioning_" (new in IFC4), positioning the project engineering coordinate system (right handed Cartesian coordinate system) within a global coordinate reference system; 235 | - "_Project Classification Information_", providing the name and version information about the classification systems used within the data set. 236 | 237 | 238 | ### 1.4.3 Object definition 239 | A main objective of the IFC4 Reference View is to enable rich information content for each model element. Model element occurrences can refer to their model element types for sharing common information. General properties are attached to model elements as property sets, either directly to the model element occurrence, or to its type. Individual model element occurrences can hold their quantities, if those are pre-calculated by the sender of the IFC data set. The usage of the object definition is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"): 240 | - "_Object Typing_", associates the Model element occurrences with the corresponding element type; 241 | - "_Property Sets_", assigns dynamically defined property sets, holding set of individual properties, to the model element occurrences of element type; 242 | - "_Quantity Sets_", assigns dynamically defined quantity sets, holding set of individual quantities, to the model element occurrences. 243 | 244 | #### 1.4.3.1 Object typing 245 | The contept template describes the mechnism of associating model element occurrences to the corresponding type and the way and restrictions of overriding type based properties by properties directly assigned to the model element occurrences. 246 | 247 | #### 1.4.3.2 Property sets 248 | Property sets hold, as the name suggests, a set of properties grouped by a common theme. Each individual property has: 249 | - a name 250 | - an optional description 251 | - a value, or number of values, of a given datatype 252 | - a unit or the information of being unitless 253 | 254 | The semantic meaning of each property is provided by its name. Properties, that are semantically declared within the scope of the IFC4 Reference View, are based on a property definition template that is published as an instrict part of the Model View Definition. Extensions to the property definitions can also be defined outside the property definition scope of the IFC4 Reference View, however the name prefix for property sets "Pset_" is restricted to properties defined within the original scope of IFC. 255 | 256 | There are two ways to declare property templates: 257 | - using the Property Set Definition PSD schema, an XML schema developed independent of the IFC specification, 258 | - using the newly introduced IFC4 property set template and property template 259 | 260 | > NOTE The PSD Schema has been used since many earlier versions of the IFC standard and has a broad legancy. The newer property set template definitions are now part of the IFC schema and can therefore be embedded within an IFC data set directly. Both schemas can be mapped without information loss. 261 | 262 | #### 1.4.3.3 Quantity sets 263 | Quantity sets hold, as the name suggests, a set of quantities pre calculated for the model element occurrence. Each individual quantity has: 264 | - a name 265 | - an optional description 266 | - a value of a given datatype corresponding to the quantity measure (length, area, volume, weight, time 267 | - a unit 268 | - a quantity formula, describing how the quantity value was calculated 269 | 270 | The semantic meaning of each qualtity is provided by its name. Quantities, that are semantically declared within the scope of the IFC4 Reference View, are based on a quantity definition template that is published as an instrict part of the Model View Definition. Extensions to the quantity definitions can also be defined outside the quantity definition scope of the IFC4 Reference View, however the name prefix for quantity sets "Qto_" is restricted to quantities defined within the original scope of IFC. 271 | 272 | 273 | ### 1.4.4 Object association 274 | In addition to the Property sets and the Quantity sets, also a classification reference to an external classification system can be assigned, and material as either single material, a material constituent sets or an material layer sets aor material profile sets combining material information with dimensions can be associated to one or many model elements. 275 | 276 | > NOTE Material dimensions are layer thicknesses, or profile geometries for e.g. a column with an embedded steel profile and a concrete protection. Within the IFC4 Reference View, such material dimensions are used exclusively as alphanumeric information, and not as part of a dimension driven parametric shape representation. 277 | 278 | The usage of the object association is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"): 279 | - "_Material Association_"; assigns a material (or material set - constituent, layer, profile) to one or several model elements (either to element occurrences, or as shared material information to element types). 280 | - "_Classification Association_"; assignes a classification reference to one or several model elements. 281 | 282 | 283 | ### 1.4.5 Product shape 284 | The first main objective of the IFC4 Reference View is to enable the exchange of highly accurate, not non-parametric, geometric representations of the model elements. Each model element is placed directly or indirectly within the project coordinate system, defining its own object coordinate system. The geometric representation items describing its shape are positioned within this object coordinate system. 285 | 286 | In order to minimize the effort for receiving and interpreting the geometic representations by the receiving software systems, in terms of development effort, processing power and loading times, the complexity and variety of geometric models has been minimized for the IFC4 Reference View. 287 | 288 | #### 1.4.5.1 Product placement 289 | Each model element defines its own object coordinate system. The placement is defined by the following concept template: 290 | - "_Local Placement_", creating an object coordinate system for the shape representation of the model element, either absolutely to the project engineering coordinate system, or relatively to another object coordination system. 291 | 292 | #### 1.4.5.2 Product geometric representation 293 | 294 | In scope of geometric shape representations of the 3D body geometry of physical and spatial elements are the following concept templates: 295 | - "_Body Tessellation Geometry_", using tessellated geometry in form of triangulated tessellations for describing the body shape of the model element; 296 | - "_Body SweptSolid Geometry_"; using extruded solid geometry or revolved solid geometry for describing the body shape of the model element; 297 | - "_Body AdvancedSweptSolid Geometry_"; using advanced swept solid geometry of circular cross sections for describing the body shape of the model element, only the swept disk solid is in scope; 298 | 299 | It is the default geometric representation of all model elements, allowing for a surface model representation with an indicator for closed shells (and therefore true volumes). The tessellated representation offers a very efficient way of exchanging 3D shape date, both for data set sizes and for processing time. Optionally the face normals can be exchanged as well. 300 | 301 | Since curved shapes would lead to very densely triangulated areas, the following swept solid based representations are also in scope of the IFC4 Reference View, balancing simplicity and compactness of representation: 302 | 303 | All other geometric models are out of scope of the IFC4 Reference View, in particular Boolean operations required for Constructive Solid Geometry CSG. 304 | 305 | > NOTE: The IFC2x3 Coordination View included CSG capabilities, the IFC4 Reference View therefore imposes a more restricted geometric representation of model elements. The IFC4 Design Transfer View should be used, if more complex geometric representations are required by the workflow. In particular, if a dimension-driven parametric representation, used by the IFC4 standard case elements, is needed. 306 | 307 | The geometric shape representation can either be directly assigned to a model element, or to its type. In case of type-based geometry, a the following representation type is used at the model element using the following concept template: 308 | - "_Mapped Geometry_", mapped representation defined at the corresponding element type. A mapped representation uses Cartesian transformation operations to place the type-based geometry within its object coordinate system. 309 | 310 | As an exception, the following elements, _IfcGrid_ and _IfcSpace_, _IfcSpatialZone_ may have an additional foot print 2D geometry (in case of _IfcGrid_ this is the only geometric representation. It is described in the following concept template: 311 | - "FootPrint Geometry", defining a 2D shape representation within the XY plane of the object coordinate system. 312 | 313 | #### 1.4.5.3 Geometric presentation 314 | Visual appearance is an important factor for the communication process using BIM data. The objective is not to support photo-realistic rendering of reference models, but to use color, basic rendering, and texture information to add visually accessible meaning to the model elements. 315 | 316 | In scope of presentation capabilities for the appearance of model element shapes are the following partial concept templates: 317 | - "_Surface Style Shading_", applying a single coloring for each solid; 318 | - "_Surface Style Rendering_", applying a single rendering (color, transparency, reflection, etc.) for each solid; 319 | - "_Surface Style textures_", applying a single texture for each solid according to a texture mapping based on the solid type; 320 | - "_Suface style tessellation_", applying a color and/or texture for each face of a tessellated solid. 321 | 322 | The visually adaquate presentation of model elements is constraint by the shape representation 323 | - for tessellated geometry: color per face, texture per face 324 | - for swept solid geometry: color and rendering information per solid, texture applied to solid using standard mapping 325 | 326 | 327 | ### 1.4.6 Object Composition 328 | 329 | The object composition functionality describes the product breakdown structure of model elements within an IFC data set, with separate breakdown structures for physical elements and spatial elements. Physical element structures describe parts and assemblies, spatial element structures describe vertical structures (for buildings) and horizontal structures (for other assets - as a stub in this release). A specific type of decomposition is the voiding - a subtraction of a void from a physical element. Another specific type is the nesting of ports within a distribution elements. 330 | 331 | The usage of the object association is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"): 332 | - "_Element Aggregation_", creating a hierarchical product breakdown structure relationship between assemblies and parts; 333 | - "_Spatial Aggregation_", creating a hierarchical spatial decomposition relationship between spatial structure elements; 334 | - "_Element Voiding_", creating a voiding relationship between a physical element and penetrating voids - within the scope of the IFC4 Reference View this relationship is a logical relationship, the void is already part of the geometry of the physical element, 335 | - "_Port Nesting_", creating an 1:N relationship between the physical element and one or many ports defining inlets or outlets - used for distribution elements. 336 | 337 | 338 | ### 1.4.7 Object Assignment 339 | 340 | The object assignment defines the assignment of objects, such as a link between model elements to groups, tasks or resources. Only the grouping assignment is in scope of the IFC4 Reference View and defined within the following concept template: 341 | - "_Group Assignment_", Assignment of one or several model elements to a group. It includes the more specific assignments of _Grouping General_, _Grouping to System_, and _Grouping to Zones_. 342 | 343 | 344 | ### 1.4.8 Object Connectivity 345 | 346 | The object connectivity defines the interlinkage between model elements. Examples are the link between physical elements and the spatial structure, where they are located, of the connection betwee the two ports of two consecutive distribution elements. 347 | 348 | The usage of the object association is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"): 349 | - "_Spatial Structure_", defines the containment of a physical element within a spatial container; 350 | - "_Port Connectivity_", defines the connection and the direction of flow between two ports of consecutive distribution elements; 351 | - "_Building Service Connectivity_", links a spatial or distribution system to a spatial structure (such as a building section); 352 | - "_Element Filling_", links a filling (usually a door or window) to an opening (usually in a wall or slab). -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # IFC4 Coordination View project overview 2 | 3 | The goal of this project is to specify the subset of the [new IFC4 release] (http://www.buildingsmart-tech.org/specifications/ifc-releases/ifc4-release/ifc4-release-summary) that supports coordination activities, also known as Coordination View. The work will be based on the [IFC2x3 CV] (http://www.buildingsmart-tech.org/certification/ifc-certification-2.0/ifc2x3-cv-v2.0-certification/ifc2x3-cv-v2.0-certification-summary) that is currently used by buildingSMART for software certification. Instead of developing another single IFC4 Coordination View, this project proposes to develop two (later three) correlated partial views: 4 | * [IFC4 Reference View](/IFC4_Reference_View.md) 5 | * [IFC4 Design Transfer View](/IFC4_DesignTransfer_View.md) 6 | * [IFC Library View](/IFC4_Library_View.md) [illustrative, since not part of this project] 7 | 8 | 9 | ## Available documentation 10 | 11 | ### General information on scope 12 | - [latest powerpoint overview] (https://github.com/BuildingSMART/IFC4-CV/blob/master/Scope/P2%20GeneralScopeIFC4CordinationView%2020140423.pdf) 13 | The general scope statement defines the requirements on the two successors of the Coordination View from the IFC exchange work flow perspective and from the expected user experience. 14 | 15 | - [latest version of mindmap] (https://github.com/BuildingSMART/IFC4-CV/blob/master/Scope/P2%20DetailedScopeIFC4CoordinationView%20V0.6.pdf) 16 | Overall mindmap showing the scope of the IFC Reference and IFC Design Transfer View based on the Model elements and Concept templates used and showing main IFC entities included. 17 | 18 | ### IFC4 Reference View (NEWS) 19 | 20 | In order to achieve a broad engagement, a public review period is set up to start today and to end on Sept 30, 2014. All necessary information, the achieved improvements, the beta version specifications, the change logs and resolved issue lists, as well as the overall objective and scope definitions are published on the buildingSMART website. 21 | 22 | - IFC4 Reference View - see [IFC4 RV at buildingsmart-tech.org] (http://www.buildingsmart-tech.org/specifications/ifc-view-definition/ifc4-reference-view) 23 | - IFC4 Addendum 1 - see [IFC4 Add1 at buildingsmart-tech.org] (http://www.buildingsmart-tech.org/specifications/ifc-releases/ifc4-add1-release) 24 | 25 | There you will also find a short introduction on how to join the review process, information on the issue database to be used, and how to join the new email exploder for all IFC4 related work in order to stay connected. 26 | 27 | 28 | 29 | Documentation: 30 | - Purpose, objective and scope, see [IFC4 Reference View Specification] (https://github.com/BuildingSMART/IFC4-CV/blob/master/IFC4_Reference_View.md) 31 | 32 | 33 | ### IFC4 Design Transfer View 34 | 35 | - Overview, see [IFC4 Design Transfer View Specification] (https://github.com/BuildingSMART/IFC4-CV/blob/master/IFC4_DesignTransfer_View.md) 36 | 37 | 38 | ### IFC4 Library View [Illustrative] 39 | 40 | - Overview, see [IFC4 Library View Specification] (https://github.com/BuildingSMART/IFC4-CV/blob/master/IFC4_Library_View.md) 41 | 42 | 43 | 44 | ## Additional explanation 45 | 46 | **Purpose of the IFC4 Coordination View Successors** 47 | 48 | The goal of these Model Views is to represent building design information that may be delivered across disciplines in design, construction, and operations. These Model Views are limited to physical building products and systems, and exclude all other lifecycle information (actors, controls, processes, resources). This model view may reference type definition information used by a building (e.g. common geometry for product models), but does not encapsulate product libraries – a separate Model View may be defined for that in the future (i.e. IFC4 Library View). Full connection information is within scope (element connections, ports, interference relationships), as is decomposition information (aggregation, voiding, filling). 49 | 50 | Several Model Views are defined with increasing levels of design intent: Reference View, Design Transfer View, and Library View. These model views do not correlate with level of detail; higher or lower LOD may be indicated in any of these model views; rather they differ on the level of parametric information captured which impacts required capabilities of software applications. It is conceivable that these Model Views could be supported separately or combined within a single file (e.g. A: reference geometry only, B: design geometry only, C: parameters and formulas only, A+B, B+C, A+C, A+B+C) – such granularity would allow the widest range of portability while at the same time supporting optimized retrieval (e.g. a mobile application could request downloading a project limited to a particular subset). 51 | 52 | Each of these model views will be explicitly defined in mvdXML format, which enables automation of implementations: if application software is designed to support IFC and mvdXML, then it can theoretically support any model view automatically. Automated filtering, translation, importing, exporting, validation, and user interface customization are possible. 53 | 54 | -------------------------------------------------------------------------------- /Schedule/Readme.md: -------------------------------------------------------------------------------- 1 | ## Project Schedule 2 | 3 | start: 01.01.2014 4 | end: 31.06.2014 (expected) 5 | 6 | milestones: 7 | - M1 31.01.2014 8 | - setup of the buildingSMART user and software expert panels 9 | - agreement on the final scope and direction of the project 10 | - M2 31.03.2014 11 | - publication of the draft model view definitions 12 | - presentation at the buildingSMART summit 17.-20. March 2014 in Stockholm 13 | - M3 30.06.2014 14 | - publication of the final model view definitions 15 | - publication as mvdXML 16 | - publication of HTML documentation and sub schemas in EXPRESS and XSD 17 | -------------------------------------------------------------------------------- /Scope/P2 DetailedScopeIFC4CoordinationView V0.4.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/buildingSMART/IFC4-CV/ed56220fede51a33eb10ba58b010eb9594bb2819/Scope/P2 DetailedScopeIFC4CoordinationView V0.4.pdf -------------------------------------------------------------------------------- /Scope/P2 DetailedScopeIFC4CoordinationView V0.5.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/buildingSMART/IFC4-CV/ed56220fede51a33eb10ba58b010eb9594bb2819/Scope/P2 DetailedScopeIFC4CoordinationView V0.5.pdf -------------------------------------------------------------------------------- /Scope/P2 DetailedScopeIFC4CoordinationView V0.6.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/buildingSMART/IFC4-CV/ed56220fede51a33eb10ba58b010eb9594bb2819/Scope/P2 DetailedScopeIFC4CoordinationView V0.6.pdf -------------------------------------------------------------------------------- /Scope/P2 GeneralScopeIFC4CordinationView 20140221.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/buildingSMART/IFC4-CV/ed56220fede51a33eb10ba58b010eb9594bb2819/Scope/P2 GeneralScopeIFC4CordinationView 20140221.pdf -------------------------------------------------------------------------------- /Scope/P2 GeneralScopeIFC4CordinationView 20140423.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/buildingSMART/IFC4-CV/ed56220fede51a33eb10ba58b010eb9594bb2819/Scope/P2 GeneralScopeIFC4CordinationView 20140423.pdf -------------------------------------------------------------------------------- /Scope/README.md: -------------------------------------------------------------------------------- 1 | # Scope definition 2 | 3 | This folder contains material helping to define the scope of the IFC4 coordination view successors 4 | - IFC4 Reference View 5 | - IFC4 Design Transfer View 6 | 7 | It includes a general overview about the aim of splitting the coordination view into two sub views. It also contains a details breakdown of the leaf-note classes and required functionality supported by these classes (in mvdXML terms: the "root concepts" and "concept templates"). 8 | 9 | ## General scope definition 10 | - [latest version] (https://github.com/BuildingSMART/IFC4-CV/blob/master/Scope/P2%20GeneralScopeIFC4CordinationView%2020140423.pdf) 11 | 12 | The general scope statement defines the requirements on the two successors of the coordination view from the IFC exchange work flow perspective and from the expected user experience. 13 | 14 | ### Version history: 15 | - [Version 21-04-14] (https://github.com/BuildingSMART/IFC4-CV/blob/master/Scope/P2%20GeneralScopeIFC4CordinationView%2020140423.pdf) - update for better differentiation between the views and certification requirements 16 | - [Version 0.5] (https://github.com/BuildingSMART/IFC4-CV/blob/master/Scope/P2%20GeneralScopeIFC4CordinationView%2020140221.pdf) - initial document 17 | 18 | ## Detailed scope definition 19 | 20 | - [latest version] (https://github.com/BuildingSMART/IFC4-CV/blob/master/Scope/P2%20DetailedScopeIFC4CoordinationView%20V0.6.pdf) 21 | 22 | The detailed scope defines the root concepts and concept templates defined in terms of a mindmap. 23 | 24 | ### Version history: 25 | - [Version 0.6] (https://github.com/BuildingSMART/IFC4-CV/blob/master/Scope/P2%20DetailedScopeIFC4CoordinationView%20V0.6.pdf) - update of the IFC Reference View concept tempates in general 26 | - [Version 0.5] (https://github.com/BuildingSMART/IFC4-CV/blob/master/Scope/P2%20DetailedScopeIFC4CoordinationView%20V0.5.pdf) - update of the IFC Reference View geometry concepts 27 | - [Version 0.4] (https://github.com/BuildingSMART/IFC4-CV/blob/master/Scope/P2%20DetailedScopeIFC4CoordinationView%20V0.4.pdf) - first publication and request for comments 28 | - up to version 0.4 - internal work declare the anticipated scope of the two views 29 | 30 | *Legend:* 31 | - Green boxes: concept is completely in scope of the MVD 32 | - Orange boxes: concept is partially in scope of the MVD (an exclusion statement is provided) 33 | - Red boxes: concept is out of scope of the MVD (note: only some concepts are marked as out of scope in order to clarify the scope, the following is true in general: all concepts not explicitly mentioned are out of scope). 34 | --------------------------------------------------------------------------------