| name | ifc-impl-mvd-export |
| description | Use when exporting an IFC file that must conform to a Model View Definition (MVD): choosing between Coordination View 2.0, Reference View, and Design Transfer View, declaring the matching ViewDefinition string in FILE_DESCRIPTION, and restricting the geometry to the representation types the chosen view permits. Prevents the non-conformant export that declares ReferenceView_V1.2 but still emits CSG or Boolean-clipping geometry, the file that names an MVD whose IFC version does not match FILE_SCHEMA, and the export that fails buildingSMART certification because the ViewDefinition contract is broken. Covers what an MVD constrains, the geometry matrix per view, the ViewDefinition keyword syntax, the Reference-versus-Design-Transfer subset relationship, and the software certification and Validation Service context. Keywords: MVD export, Model View Definition, ViewDefinition, FILE_DESCRIPTION, Coordination View 2.0, Reference View, Design Transfer View, ReferenceView_V1.2, CoordinationView_V2.0, DesignTransferView, tessellation export, geometry restriction, CSG excluded, IFC certification, Validation Service, export scorecard, which MVD should I use, my IFC export is not conformant, how do I export a reference model, what is an MVD.
|
| license | MIT |
| compatibility | Designed for Claude Code. Requires IFC IFC2x3, IFC4, IFC4.3. |
| metadata | {"author":"OpenAEC-Foundation","version":"1.0"} |
Exporting an IFC File to a Model View Definition
The full IFC schema has over 1300 entities; no single exchange uses all
of it. A Model View Definition (MVD) is a standardized subset of the
schema scoped to one exchange scenario. It fixes which entities,
attributes, property sets, and geometry representation types a
conforming exporter is allowed to produce. Exporting to an MVD means two
things ALWAYS done together: declaring the MVD in the file header, and
keeping the actual content inside the subset that MVD allows.
Verified against the buildingSMART IFC4 Reference View specification, the
buildingSMART MVD database, the IFC Header Data Implementation Guide
v1.0.2, and the IFC4.3, IFC4 ADD2 TC1, and IFC2x3 TC1 specifications. See
references/methods.md for the MVD registry and geometry matrix,
references/examples.md for header strings and a conformance checklist,
and references/anti-patterns.md for the export mistakes that break MVD
conformance.
Quick Reference
The three main MVDs
| MVD | IFC version | ViewDefinition string | Purpose |
|---|
| Coordination View 2.0 | IFC2x3 TC1 | CoordinationView_V2.0 | clash detection, model federation |
| Reference View | IFC4 ADD2 TC1 | ReferenceView_V1.2 | one-directional reference models |
| Design Transfer View | IFC4 ADD2 TC1 | DesignTransferView_V1.1 | editable model transfer (Draft) |
Reference View also has a Final release for IFC4.3 ADD2; its geometry
rules mirror the IFC4 Reference View. Declare the ViewDefinition string
published with that IFC4.3 release.
What an MVD constrains
An MVD is a contract. Declaring it ALWAYS commits the file to:
- The entity and attribute subset of the named view.
- The property sets the view requires.
- The geometry representation types the view permits.
- An IFC version: the MVD and
FILE_SCHEMA MUST agree.
NEVER declare an MVD the content does not actually satisfy: a reader
relies on the declared view to decide what it must implement.
Geometry permitted per MVD
| Representation | Coordination View 2.0 | Reference View | Design Transfer View |
|---|
SweptSolid (extrusion, revolution) | yes | yes | yes |
AdvancedSweptSolid | n/a (IFC2x3) | swept disk only | yes |
Tessellation | n/a (IFC2x3) | yes | yes |
Brep | yes | no | yes |
Clipping (Boolean DIFFERENCE) | yes | NO | yes |
CSG (Boolean tree) | yes | NO | yes |
MappedRepresentation | yes | yes | yes |
FootPrint | yes | yes (Grid, Space, SpatialZone) | yes |
| dimension-driven parametric | n/a | NO | yes |
The Reference View deliberately EXCLUDES CSG, Boolean clipping, and
parametric dimension-driven geometry so the originator keeps the
editable parametric model. IFC2x3 has no tessellation entities, so
Coordination View 2.0 never uses Tessellation.
The Reference / Design Transfer subset rule
The Reference View is a true SUBSET of the Design Transfer View. A reader
that imports the Design Transfer View can ALWAYS also import Reference
View data; the reverse is NOT true. The views differ by the level of
parametric information captured, not by level of detail.
Decision Trees
Which MVD to export
What is the exchange scenario?
├── Clash detection / federation in an IFC2x3 toolchain
│ -> Coordination View 2.0 (FILE_SCHEMA = IFC2X3)
├── Distribute a reference model for coordination, takeoff, viewing,
│ where the receiver only reads and does not edit (IFC4)
│ -> Reference View (FILE_SCHEMA = IFC4)
│ Geometry MUST be tessellation, simple swept solids, or swept
│ disk solids. NEVER emit CSG or Boolean clipping.
├── Hand a model to another authoring tool that will edit it (IFC4)
│ -> Design Transfer View (FILE_SCHEMA = IFC4)
│ Full geometry, including CSG and parametric, is allowed.
├── Infrastructure model (bridge, road, rail, alignment)
│ -> IFC4.3 Reference View (FILE_SCHEMA = IFC4X3)
└── Facility-management handover data, not geometry
-> COBie / Basic FM Handover ; see ifc-impl-cobie.
Reference View geometry: substitute, never emit
Does the model contain Boolean / CSG geometry (a wall with an opening
cut by IfcBooleanClippingResult, a CSG solid)?
├── YES, and the target is the Reference View
│ ALWAYS bake the result before export:
│ - evaluate the Boolean and emit the result as Tessellation, OR
│ - emit it as a plain SweptSolid if the shape allows.
│ NEVER write the IfcBooleanClippingResult itself.
└── YES, and the target is the Design Transfer View
Emit the Boolean geometry as-is: the view permits it.
Patterns
Pattern 1: declare the ViewDefinition in FILE_DESCRIPTION
The FILE_DESCRIPTION first argument carries the ViewDefinition:
FILE_DESCRIPTION(('ViewDefinition [ReferenceView_V1.2]'),'2;1');
The keyword sits inside ViewDefinition [ ... ]. Multiple view keywords
are comma-separated inside one string. implementation_level is ALWAYS
'2;1'. ALWAYS write the keyword that matches the MVD column in the
table above, exactly.
Pattern 2: pair the MVD with FILE_SCHEMA
Coordination View 2.0 -> FILE_SCHEMA(('IFC2X3'));
Reference View -> FILE_SCHEMA(('IFC4'));
Design Transfer View -> FILE_SCHEMA(('IFC4'));
IFC4.3 Reference View -> FILE_SCHEMA(('IFC4X3'));
The MVD names an IFC version. FILE_SCHEMA MUST name the same version.
NEVER declare CoordinationView_V2.0 in a file whose FILE_SCHEMA is
IFC4: Coordination View 2.0 is defined only for IFC2x3.
Pattern 3: a Reference View export
For a Reference View file, ALWAYS, before writing:
- Set
FILE_SCHEMA(('IFC4')) and the ReferenceView_V1.2
ViewDefinition.
- Convert every Boolean / CSG solid to tessellation or a plain swept
solid.
- Emit
Body geometry only as Tessellation, SweptSolid, or
AdvancedSweptSolid (swept disk).
- Keep
MappedRepresentation for repeated type geometry; it is
permitted.
- Verify no
IfcBooleanResult, IfcBooleanClippingResult, or
half-space solid remains in any representation.
Pattern 4: a Design Transfer View export
The Design Transfer View permits all geometry. ALWAYS still:
- Set
FILE_SCHEMA(('IFC4')) and the DesignTransferView_V1.1
ViewDefinition.
- Keep parametric and Boolean geometry intact so the receiving tool can
edit it.
- Treat the file as a superset of a Reference View export: a Reference
View reader must still be able to consume the Reference-View parts.
Pattern 5: verify before claiming conformance
After export, ALWAYS upload the file to the buildingSMART Validation
Service. It checks STEP syntax, the EXPRESS schema, and the normative
rules. Export certification scorecards are built from real user files
uploaded this way. A file that declares an MVD but fails validation is
not conformant regardless of the header string.
Reference Links
references/methods.md: the MVD registry, the ViewDefinition keyword
syntax, the geometry matrix, and the certification context.references/examples.md: complete header strings per MVD and a
Reference View conformance checklist.references/anti-patterns.md: the export mistakes that break MVD
conformance.
Related skills
ifc-core-mvd: the MVD concept, concept templates, and Root Concepts.ifc-syntax-geometry-tessellation: the tessellation entities a
Reference View export relies on.ifc-syntax-step-physical-file: the FILE_DESCRIPTION and
FILE_SCHEMA header syntax.
Official sources
