| 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 |
|---|
