Ifc Impl Mvd Export

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

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:

1. The entity and attribute subset of the named view.
2. The property sets the view requires.
3. The geometry representation types the view permits.
4. 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

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:

1. Set FILE_SCHEMA(('IFC4')) and the ReferenceView_V1.2 ViewDefinition.
2. Convert every Boolean / CSG solid to tessellation or a plain swept solid.
3. Emit Body geometry only as Tessellation, SweptSolid, or AdvancedSweptSolid (swept disk).
4. Keep MappedRepresentation for repeated type geometry; it is permitted.
5. 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:

1. Set FILE_SCHEMA(('IFC4')) and the DesignTransferView_V1.1 ViewDefinition.
2. Keep parametric and Boolean geometry intact so the receiving tool can edit it.
3. 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

• IFC4 Reference View specification: https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/schema/views/reference-view/index.htm
• buildingSMART MVD database: https://technical.buildingsmart.org/standards/ifc/mvd/
• buildingSMART software certification: https://www.buildingsmart.org/compliance/software-certification/
• buildingSMART Validation Service: https://www.buildingsmart.org/users/services/validation-service/