Skip to content
Structura v0.6.0 · FR-W3

What is in the file

One IFC file, named schema, named model view definition. Below is what a BIM manager opens it to find: the spatial spine, the entity and the geometry authored for each of the 8 element classes, the property sets carried on every element, and the rule that decides an element’s identity. The counts are read from the sample package on this page, not asserted.

IFC4 Reference View [ReferenceView_V1.2] 8 element classes Millimetres
Quoted from the sample file

Schema and view definition

larch-annex.ifc · STEP header
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [ReferenceView_V1.2]'),'2;1');
FILE_NAME('Larch Annex','2026-01-01T00:00:00',('Structura'),('Structura'),'structura-pipeline','structura-pipeline','none');
FILE_SCHEMA(('IFC4'));
ENDSEC;

Read from the committed sample at build time. The timestamp is pinned, not a wall clock: writing the same model twice yields byte-identical files.

The view definition is the part most conversions leave blank.

Structura declares one and holds to it: geometry is explicit, every element is a real IFC entity of its own class, and nothing depends on a proprietary extension to be read. A receiving tool can validate the file against the named view rather than against whatever the exporter happened to emit.

Schema
IFC4
Length unit
MILLI · METRE
Area · volume unit
SQUARE_METRE · CUBIC_METRE
Spatial structure

Project, site, building, storey

  1. IfcProject
  2. └ IfcSite
  3. └ IfcBuilding
  4. └ IfcBuildingStorey
  5. └ elements
  6. └ IfcSpace

Elements hang off their storey with IfcRelContainedInSpatialStructure . Rooms cannot: an IfcSpace is itself a spatial element, so it extends the spine through IfcRelAggregates instead. Storey placements are relative to the building, so the storey elevation is applied exactly once.

Storeys in the sample building, parsed from its elevation sheets

Larch Annex
Storey Elevation Height
L00 0 mm 4200 mm
L01 4450 mm 3400 mm
L02 8100 mm 3400 mm
L03 11750 mm 3400 mm
L04 15400 mm 3400 mm
L05 19050 mm 3000 mm

6 storeys reconstructed from 8 sheets, with 75 recorded assumptions travelling beside the model.

One row per class

Entity, geometry, count

Each element class, the IFC entity Structura authors for it, its predefined type, the geometric representation, and how many instances the committed sample file contains.
Class PredefinedType Representation · Body In the sample
IfcWall SOLIDWALL SweptSolid — the rectangle length × thickness_mm extruded to height_mm, placed on the centreline; every hosted opening subtracted with IfcOpeningElement + IfcRelVoidsElement 72
IfcDoor DOOR · SINGLE_SWING_LEFT SweptSolid — a box width_mm × wall thickness × height_mm sitting in its opening with the sill on the storey floor, joined by IfcRelFillsElement 55
IfcWindow WINDOW · SINGLE_PANEL SweptSolid — the same box lifted sill_mm above the storey floor, joined to its opening by IfcRelFillsElement 48
IfcColumn COLUMN SweptSolid — a circle of diameter_mm extruded height_mm upward from the storey floor at its centre 24
IfcSlab FLOOR or ROOF SweptSolid — the outline polygon extruded thickness_mm, top at the measured elevation when the mesh route supplies one, otherwise derived from the storey 7
IfcStair STRAIGHT_RUN_STAIR SweptSolid — one tread box per riser tiling the run, so the flight lands exactly on the storey above 5
IfcRoof GABLE_ROOF Tessellation — the pitched panels as one IfcPolygonalFaceSet sharing ridge and eave vertices, Closed = False: four panels are a shell, not a solid none here
IfcSpace SPACE · CompositionType ELEMENT SweptSolid — the outer boundary polygon extruded height_mm from the storey floor, aggregated onto its storey with IfcRelAggregates 54

Counts are instances of that entity in the committed sample, which is a flat-roofed building: it carries no IfcRoof . Pitched roofs come from the mesh route and are authored as a tessellated shell — the class is in the file format, just not in this building.

What else the file carries

  • IfcProject 1

    one, with the unit assignment

  • IfcSite 1

    one

  • IfcBuilding 1

    one

  • IfcBuildingStorey 6

    one per storey, Elevation from the elevation sheets

  • IfcOpeningElement 103

    one per hosted door and window

  • IfcPropertySet 265

    one Structura_Params per element

  • IfcElementQuantity 54

    one Qto_SpaceBaseQuantities per room

  • IfcRelVoidsElement 103

    opening cut into its host wall

  • IfcRelFillsElement 103

    door or window filling its opening

  • IfcRelAggregates 9

    site, building and the rooms on each storey

  • IfcOwnerHistory none

    omitted — optional in IFC4, and it would carry a wall clock

Property sets

The data attached to every element

Structura_Params on every element
el_id IfcText
the element id — the key review, eval and the schedule read
cls IfcText
the canonical class, identical to the authored entity
confidence IfcReal
the detector score that decided whether the element was flagged for review
params_json IfcText
the element as the canonical model holds it, keys sorted — dimensions, placement, host, source sheet
Qto_SpaceBaseQuantities on every room
Height IfcQuantityLength
room height in millimetres
GrossFloorArea IfcQuantityArea
boundary area in square metres
NetFloorArea IfcQuantityArea
the same polygon — omitted entirely when an interior hole was discarded, rather than overstating the room
GrossPerimeter IfcQuantityLength
boundary perimeter in millimetres
GrossVolume IfcQuantityVolume
area × height in cubic metres
params_json on one exterior wall, quoted from the sample file
{"cls":"IfcWall","confidence":96,"height_mm":4200.0,"id":"W-L00-001","kind":"ext","opening_ids":["WN-L00-001","WN-L00-002","D-L00-001","WN-L00-003","WN-L00-004"],"p1":[0.0,0.0],"p2":[30000.0,0.0],"source":"plan2d","source_sheet":"A-101 \\u00b7 Plan L00","storey":"L00","thickness_mm":240.0}

The canonical record of the element as the pipeline reconstructed it — dimensions, endpoints, hosted openings, and the sheet it was read from.

Honest by omission
A room whose boundary swallowed an interior island gets no NetFloorArea at all. Repeating the gross figure there would overstate the room in a space schedule by exactly that island, so the quantity is left out and the reason is recorded in the assumptions register shipped beside the file.
Identity

One rule decides every GlobalId

Every GlobalId is a uuid5 of the building’s identity plus the element’s class, storey and quantised placement — never a random value, never a sequence number — so an element nobody edited keeps the same GlobalId across every re-export, and an element that genuinely moved gets a new one.

That rule is the difference between a model you can re-issue and a model that breaks every downstream link each time it is regenerated. It is recorded as decision D-005 and held by an automated test: the same model authored twice yields identical GlobalIds, a dimension edit keeps them, and moving a wall re-identifies that wall and nothing else. Reclassifying an element does change its GlobalId — a reclassified element is a different IFC entity type, and pretending otherwise would be the lie.

One element from the sample, model and file agreeing
element   W-L00-001   IfcWall   storey L00
GlobalId  1mQsOZrUTNyQgt3jh$aBTB
Evidence
FR-7
GUIDs stable for unedited elements across versions, verified by test.
tests/unit/test_ifc_guid_stability.py
Authors the same model twice, edits dimensions, then moves an element, and asserts which identifiers may change.
Distinct GlobalIds
265 for 265 elements. The writer refuses to author a file at all if two elements ever collapse onto one identity.
Sample package

Open the real output

The Larch Annex fixture, converted and exported by the product — not a mock-up. Every file below is regenerated by the repository’s own demo generator and is byte-identical across runs; the checksum beside each one is recorded at build time from the file this page links to.

  • larch-annex.ifc Download

    The IFC4 Reference View model

    sha256 9a2611d9bdf5e5c7…
  • schedule.xlsx Download

    Element schedule, Excel workbook

    sha256 0f1c77e8243ee937…
  • schedule.csv Download

    Element schedule, comma-separated

    sha256 66afec4349db8ea9…
  • assumptions.json Download

    Assumptions register — every default the pipeline applied

    sha256 fddecc4b761c535a…
  • model.json Download

    The canonical model the IFC was authored from

    sha256 f5940667a9082b39…
  • summary.json Download

    Package summary: storeys, sheets, class counts

    sha256 ec7106d6401658f4…
Stated plainly

Not yet in the file

Owner-side systems ask for four things this file does not carry yet. They are named here rather than discovered during a handover. Each is roadmap: no date, no commitment, and nothing on this page counts it as shipped.

  • IFC type objects

    Roadmap

    Every element is authored as an occurrence. There is no type layer, so a receiving tool cannot group occurrences by a shared type definition or attach type-level properties.

    IfcWallType · IfcDoorType · IfcTypeObject

  • Standard Pset_*Common property sets

    Roadmap

    The model data travels in one custom set, with the full element record inside a JSON string. A mapping file in an asset-management system cannot address fields inside that string; the standard common sets it does know are not written.

    Pset_WallCommon and family

  • Classification references

    Roadmap

    No classification system is attached to any element, so a specification that requires a classified model has to add it downstream.

    IfcClassification · IfcClassificationReference

  • COBie handover

    Roadmap

    Storeys and rooms exist in the model, but there is no COBie export and no type or contact layer to build one from.

    Facility and Floor exist; Space, Type and Contact do not