ifc-template-catalog

Versioned buildingSMART PSD/QTO template catalogs: typed property and quantity set definitions with their applicability, provenance and diagnostics, deterministic embedded snapshots, and explicit correction overlays. It owns no IFC model records (ADR 0017).

cargo add ifc-template-catalog

The openbim-ifc facade also provides it behind its property-catalog feature.

• API documentation: docs.rs/ifc-template-catalog
• Reference page: openbimrs.github.io/ifc
• Source and issues: github.com/openbimrs/ifc

Embedded editions and profiles

Official snapshots are embedded for IFC2X3 TC1, IFC4 ADD2 TC1, and IFC4X3 ADD2 (feature embedded, default). Corrected overlays exist for IFC4 ADD2 TC1 and IFC4X3 ADD2; IFC2X3 TC1 has the official profile only. Official artifacts are never rewritten: the IFC4X3 overlay adds Pset_Stationing.HasIncreasingStation, which the published ADD2 documentation lists and the PSD XML the snapshot is built from omits.

Snapshot format

All three editions live in one container, data/catalog.bin (format 3, module snapshot): 1,423,604 bytes, where the three bincode snapshots it replaced were 3,648,573. It is a lossless format shift, nothing is trimmed:

• a string table holds each string the distinct records use more than once, most used first; a string used once stays inline beside its context; a lowercase hexadecimal GUID or SHA-256 is stored as its bytes;
• each distinct property, quantity and set record is stored once across editions, so templates and texts IFC4 ADD2 TC1 and IFC4X3 ADD2 publish identically take no extra space;
• each edition keeps its own entry: its source manifest (release, source URL, source digest, counts) and its sets in order, each with its source path and file digest.

The first lookup of an edition decodes that edition's records only. The container is not compressed on top: it would need a decompressor in every binary, and every channel the crate ships through compresses already.

snapshot::encode writes a container or a per-edition file deterministically; the SHA-256 of each is pinned (CONTAINER_SHA256, pinned_sha256). Tests decode every edition and profile to the content fingerprints taken from the format it replaced.

Runtime catalogs

With the runtime feature, and without embedded if the binary should not carry the container, a host installs an edition from snapshot bytes it loads itself; the bytes must match the edition's pin or the container's:

use ifc_template_catalog::catalog::CatalogProfile;
use ifc_template_catalog::definition::CatalogEdition;
use ifc_template_catalog::runtime;

let edition = CatalogEdition::Ifc4x3Add2;
runtime::install(edition, &std::fs::read("catalog/ifc4x3-add2.bin")?)?;
let catalog = runtime::load_catalog(edition, CatalogProfile::Corrected)?;

Write the per-edition files with cargo run -p ifc-template-catalog --features runtime --example export_snapshots -- <dir>; it checks each against its pin. The npm package @openbim/ifc ships them and loads them this way.

Version-explicit TSV index

Each committed TSV has an edition and source_digest column, preserves set/member GUIDs when the source publishes them, and retains the source XML path and digest. GUIDs are release-scoped evidence, not a promise that equal names or GUIDs have identical semantics across editions. Generate one deterministically:

cargo run -p ifc-template-catalog --example export_ifc4_tsv -- \
  ifc4x3-add2 crates/ifc-template-catalog/data/ifc4x3-add2.tsv

The example accepts ifc2x3-tc1, ifc4-add2-tc1, or ifc4x3-add2. Provenance, exact corpus gates, checksums, and artifact sizes are in data/NOTICE.md.