Run any Skill in Manus with one click

ifc-impl-format-transcoding

Stars0

Forks0

UpdatedMay 20, 2026 at 08:51

Use when converting an IFC model between encodings (SPF .ifc, ifcXML, ifcJSON, ifcZIP) and the result must stay faithful, and when deciding which on-disk format to pick for a given exchange. Prevents confusing a format transcode with a schema-version migration, expecting STEP #id numbers to survive a round-trip, treating ifcJSON as a guaranteed lossless format, and assuming DERIVE or INVERSE attributes are lost in conversion. Covers the format comparison matrix, the EXPRESS schema as the single canonical model, SPF to ifcXML conversion (ISO 10303-28 plus the Part 28 configuration file), SPF or ifcXML to ifcJSON (provisional), ifcZIP wrapping, what is and is not preserved, and the transcoding vs version-migration vs geometry-export split. Keywords: IFC format conversion, transcoding, SPF to ifcXML, ifc to json, ifcXML, ifcJSON, ifcZIP, ISO 10303-28, Part 28 configuration file, lossless, round-trip, "which IFC format", "convert ifc file", "ifc file too big", "json instead of ifc", "lost data after conversion",

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Impertio-Studio

Impertio-Studio/IFC-Claude-Skill-Package

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

4 files

SKILL.md

readonly

More from this repository

same repository

ifc-core-data-model

Impertio-Studio/IFC-Claude-Skill-Package

Use when you need to understand or explain how the IFC schema is organized, decide which conceptual layer an entity belongs to, judge whether one schema is allowed to reference another, or work out why an entity does or does not carry a GlobalId. Prevents the upward-reference mistake (a lower-layer schema pointing at a higher-layer entity), the assumption that every IFC entity has a GUID, and the error of treating a serialized .ifc / .ifcXML / .ifcJSON file as the schema instead of a derived encoding. Covers the four-layer architecture (Resource, Core, Interoperability/Shared, Domain), the downward-only referencing rule (ladder principle), the EXPRESS schema as the single canonical model, and the GlobalId presence rule across IFC2x3, IFC4 and IFC4.3. Keywords: IFC layered architecture, four-layer schema, Resource layer, Core layer, Interoperability layer, Domain layer, ladder principle, downward reference, IfcKernel, IfcProductExtension, GlobalId, GUID, IfcRoot, EXPRESS canonical model, ISO 16739-1, ISO 10303

2026-05-200

ifc-impl-authoring-file

Impertio-Studio/IFC-Claude-Skill-Package

Use when authoring a new IFC file from scratch and the minimal valid skeleton must be built before any element can be added: the IfcProject context root, the IfcUnitAssignment, the IfcGeometricRepresentationContext, the spatial tree, the IfcOwnerHistory, the STEP header, and the first wall with geometry. Prevents the file failing to open or showing nothing in a viewer because units, the geometric context, or the spatial root are missing, because GlobalId values are regenerated on every export, or because FILE_SCHEMA does not match the entities used. Covers the mandatory setup sequence, the HEADER and FILE_SCHEMA, stable GlobalId generation, the project to site to building to storey chain wired with IfcRelAggregates, placing one IfcWall with IfcRelContainedInSpatialStructure, and the decision of which IFC version to target. Keywords: author IFC file, create IFC from scratch, minimal IFC file, IfcProject setup, IfcUnitAssignment, IfcOwnerHistory, IfcGeometricRepresentationContext, FILE_SCHEMA, GlobalId generati

2026-05-200

ifc-impl-cobie

Impertio-Studio/IFC-Claude-Skill-Package

Use when producing, reading, or extracting COBie facility-management handover data from an IFC model: mapping COBie worksheets to IFC entities, deciding which records belong in COBie scope, choosing between the IFC STEP exchange and the spreadsheet form, or extracting a COBie subset from a full design model. Prevents treating COBie as a geometry format, inventing IFC entity names for COBie records, mapping a Component to a type instead of an occurrence, and exporting parametric geometry into an FM handover. Covers COBie as the Basic FM Handover MVD subset, the worksheet to IFC entity map, the IFC2x3 and IFC4 bindings, and the STEP versus spreadsheet exchange. Keywords: COBie, FM handover, facility management handover, Basic FM Handover MVD, asset management data, IfcSpace, IfcZone, IfcSystem, IfcTask, IfcDocumentReference, IfcConstructionResource, COBie spreadsheet, COBie worksheet, component versus type, asset register from IFC, handover data, how do I export COBie, what is COBie, COBie data missing, non-gra

2026-05-200

ifc-impl-library-selection

Impertio-Studio/IFC-Claude-Skill-Package

Use when choosing which IFC implementation library to use for a project, or when unsure which tool reads and writes IFC files for a given language, platform, or target IFC version. Prevents picking a library that does not fit the language or platform, expecting this package to teach a library API, asserting an unverified IFCx Rust library, and confusing schema migration with geometry conversion. Covers the library landscape (IfcOpenShell, web-ifc, xBIM, IFC++), the language and platform decision matrix, routing to the owning OpenAEC skill packages, and the emerging state of IFC5 and IFCx tooling. Keywords: IFC library, IfcOpenShell, web-ifc, ThatOpen engine_web-ifc, xBIM, XbimEssentials, IFC++, ifcx-rs, which IFC library should I use, read IFC in Python, parse IFC in the browser, IFC in dotnet, IFC in Rust, IFC WASM, library decision matrix, pointer skill, which tool for IFC, how do I open an IFC file in code, "library does not support my IFC version", "no IFC library for my language", "IFC parsing is too slo

2026-05-200

ifc-syntax-ifcjson

Impertio-Studio/IFC-Claude-Skill-Package

Use when reading, generating, or evaluating an ifcJSON file, choosing a JSON encoding for IFC data in a web or REST application, or resolving the ref-based cross-references in an ifcJSON document. Prevents treating ifcJSON as a stable standardized format, expecting lossless round-tripping, inlining referenced entities instead of using ref objects, and using the legacy IFCJSON-Team lineage instead of the current buildingsmart-community repo. Covers ifcJSON as a provisional candidate format for IFC4 and IFC4.3 : the top-level envelope, the data array of entity objects, camelCased attribute keys, the ref object that replaces the STEP id, file size, and the two ifcJSON lineages. Keywords: ifcJSON, IFC JSON, JSON encoding of IFC, ifcjson data array, ref object, globalId, camelCase IFC attributes, buildingsmart-community ifcJSON, provisional format, candidate format, IFC for web apps, IFC REST API, how do I read an IFC JSON file, convert IFC to JSON, IFC without EXPRESS, my ifcJSON will not round-trip, "ifcJSON fil

2026-05-200

ifc-syntax-ifcxml

Impertio-Studio/IFC-Claude-Skill-Package

Use when you need to read, write, or recognise an ifcXML file, understand the iso_10303_28 / uos document structure, or resolve id / ref / href references in IFC XML data. Prevents confusing ifcXML (ISO 10303-28) with the STEP Physical File (ISO 10303-21), hand-authoring the XSD instead of generating it, ignoring the version-specific Part 28 configuration file, and mishandling the by-reference versus by-containment duality. Covers the ifcXML XML encoding, ISO 10303-28, the Part 28 configuration file, the iso_10303_28 root and single uos element, entity-to-element mapping, id / ref / href references, and when to choose ifcXML over SPF. Keywords: ifcXML, .ifcXML, IFC XML, ISO 10303-28, Part 28 configuration file, iso_10303_28, uos, unit of serialization, id ref href, xsi:nil, by-reference, by-containment, XSD validation, XSLT, XPath, how do I open an ifcXML file, ifcXML vs ifc, what is ifcXML, IFC XML schema, ifcXML file too large, "ifcXML will not validate", "href reference not resolving", "ifcXML opened as pl

2026-05-200

name	ifc-impl-format-transcoding
description	Use when converting an IFC model between encodings (SPF .ifc, ifcXML, ifcJSON, ifcZIP) and the result must stay faithful, and when deciding which on-disk format to pick for a given exchange. Prevents confusing a format transcode with a schema-version migration, expecting STEP #id numbers to survive a round-trip, treating ifcJSON as a guaranteed lossless format, and assuming DERIVE or INVERSE attributes are lost in conversion. Covers the format comparison matrix, the EXPRESS schema as the single canonical model, SPF to ifcXML conversion (ISO 10303-28 plus the Part 28 configuration file), SPF or ifcXML to ifcJSON (provisional), ifcZIP wrapping, what is and is not preserved, and the transcoding vs version-migration vs geometry-export split. Keywords: IFC format conversion, transcoding, SPF to ifcXML, ifc to json, ifcXML, ifcJSON, ifcZIP, ISO 10303-28, Part 28 configuration file, lossless, round-trip, "which IFC format", "convert ifc file", "ifc file too big", "json instead of ifc", "lost data after conversion", "ids changed", how do I convert an IFC file, what format should I export.
license	MIT
compatibility	Designed for Claude Code. Requires IFC IFC2x3, IFC4, IFC4.3.
metadata	{"author":"OpenAEC-Foundation","version":"1.0"}

IFC Format Transcoding

Convert an IFC model between its on-disk encodings without losing data, and pick the right encoding for an exchange. The governing fact : IFC is one EXPRESS schema with several derived encodings. Transcoding re-renders the SAME model population in a different encoding. It NEVER changes the schema version and NEVER changes the geometry.

This skill is encoding-level. For a schema-version change (IFC2x3 to IFC4) see ifc-impl-version-migration ; that is migration, not transcoding. For the encoding syntax itself see ifc-syntax-step-physical-file, ifc-syntax-ifcxml, ifc-syntax-ifcjson.

Quick Reference

The four encodings

Format	Extension	MIME type	ISO standard	Size vs SPF	Status
SPF / STEP	`.ifc`	`application/x-step`	ISO 10303-21	100%	Official
ifcXML	`.ifcXML`	`application/xml`	ISO 10303-28	113%	Official
ifcZIP	`.ifcZIP`	`application/zip`	none	17%	Official
ifcJSON	`.json`	`application/json`	none	148%	Provisional / Candidate

Sizes are the official buildingSMART figures (SPF = 100%). ifcZIP 17% is the compressed size of whichever text payload it wraps.

Core rules

The EXPRESS schema is the single canonical model. ALWAYS treat a transcode as "read the EXPRESS population, re-render it" : the model is the invariant, the file bytes are not.
ALWAYS keep the schema version fixed across a transcode. SPF IFC4 transcodes to ifcXML IFC4, NEVER to ifcXML IFC2x3. Changing the version is migration.
DERIVE and INVERSE attributes are NEVER serialized in ANY encoding, so a transcode can NEVER lose them. They are recomputed by the reader.
NEVER promise a lossless ifcJSON round-trip. ifcJSON is provisional ; round-trip is a design goal, not a guarantee.
ifcZIP is pure compression. Wrapping and unwrapping is ALWAYS lossless.

Decision Trees

Is this transcoding or migration

Does the schema version change (FILE_SCHEMA value differs) ?
├─ NO  : same version, different encoding
│        -> TRANSCODING. This skill. Re-render the EXPRESS population.
└─ YES : IFC2x3 to IFC4, IFC4 to IFC4.3, etc.
         -> SCHEMA-VERSION MIGRATION, not transcoding.
            Entities are renamed/removed/added. See ifc-impl-version-migration.
            (A migration may ALSO change encoding ; do the two steps separately.)

Which target encoding to pick

What is the priority for this exchange ?
├─ Widest compatibility, smallest text  -> SPF (.ifc). The default.
├─ XML toolchain (XSLT, XPath, XSD validation), schema validation -> ifcXML
├─ Web / JavaScript app, REST API, JSON-native consumer          -> ifcJSON
│   (accept provisional status and weaker tooling)
└─ Transfer or storage where size dominates -> ifcZIP
    (wraps an SPF or ifcXML payload ; decompress before parsing)

Is a given transcode lossless

Which pair ?
├─ SPF  <-> ifcXML   : lossless AT THE MODEL LEVEL (ISO 10303-28 + Part 28
│                      config). File-level details (#id, layout) are NOT kept.
├─ * <-> ifcZIP      : ALWAYS lossless (pure compression of an unchanged payload).
└─ SPF/ifcXML <-> ifcJSON : model-level fidelity NOT guaranteed (provisional
                            format). Verify against the converter before relying
                            on a round-trip.

Patterns

Pattern 1 : the canonical-model mental model

A transcode is always two steps over the EXPRESS schema as the pivot:

source encoding  --parse-->  EXPRESS population (entities, explicit attributes,
                                                 references)  --render-->  target encoding

ALWAYS think in terms of the EXPRESS population, never byte-for-byte text. Two files in two encodings are "the same model" when they encode the same population of entities and explicit attribute values. ALWAYS confirm FILE_SCHEMA (SPF) or the schema namespace (ifcXML) or schemaIdentifier (ifcJSON) matches before and after.

Pattern 2 : SPF to ifcXML and back

ifcXML is governed by ISO 10303-28, not ISO 10303-21. The EXPRESS-to-XSD mapping is not deterministic on its own : a published Part 28 configuration file, one per IFC schema version, pins the mapping. ALWAYS use the configuration file that matches the model's schema version.

This pair is lossless at the model level : both encode the same EXPRESS population. What does NOT survive:

STEP #id integers become XML id / ref / href strings. The numbering is NOT preserved.
Positional attributes become named XML elements or attributes.
An unset attribute ($ in SPF) becomes an absent element in ifcXML.
Comments and exact text layout are lost.

ALWAYS validate the model population after the transcode, NEVER diff the raw bytes.

Pattern 3 : transcoding to and from ifcJSON

ifcJSON is a Provisional / Candidate format with no ISO standard, synchronized to IFC4.3 (and usable for IFC4). It is 148% of SPF size. The cross-reference key is the entity globalId (a UUID) inside a {"type": ..., "ref": ...} object, replacing the SPF #id.

ALWAYS state the provisional status when proposing ifcJSON. NEVER promise a lossless SPF to ifcJSON to SPF round-trip : the ifcJSON specification lists round-trip as a design goal, and converters may apply options (compact formatting, inverse handling) that change output. ALWAYS verify a round-trip against the actual converter for the target IFC version before depending on it.

Pattern 4 : ifcZIP wrapping

ifcZIP is a plain ZIP archive. ALWAYS apply these rules:

The archive uses PKZip 2.04g (DEFLATE) compression. NEVER use encryption, Unicode archive features, or deflate64 : those break compatibility.
The archive MUST contain exactly ONE .ifc file OR exactly one .ifcXML file in its main directory. NEVER place multiple model files in one ifcZIP.
Wrapping and unwrapping change nothing in the payload : ifcZIP is ALWAYS lossless. To "transcode" an ifcZIP, unwrap it, transcode the payload, re-wrap.

Pattern 5 : what is at risk, what is safe

ALWAYS preserve, by an explicit strategy, the items genuinely at risk:

At risk in a transcode	Why	Mitigation
Instance identifiers (`#id` vs `id` vs `globalId`)	each encoding uses its own scheme	rely on `GlobalId` (the IfcRoot UUID), never on `#id`
Order of unordered aggregates (`SET`, `BAG`)	unordered by definition	NEVER depend on member order of a SET or BAG
Header metadata	not modeled identically across encodings	re-state author, timestamp, view definition after transcode
Comments	not part of the model	accept loss ; move notes into model entities
`IfcReal` numeric formatting	text representation differs	compare values numerically, not as strings

NEVER-at-risk (because never serialized in any encoding): DERIVE attributes and INVERSE attributes. A transcode cannot lose them ; the reader recomputes them.

Pattern 6 : transcoding vs migration vs geometry export

Three different operations are routinely confused:

Operation	Changes	Routes to
Transcoding	encoding only (SPF to ifcXML to ifcJSON)	THIS skill
Schema-version migration	schema version (IFC2x3 to IFC4) ; entities renamed	`ifc-impl-version-migration`
Geometry / format export	derived output (meshes, glTF, OBJ, COLLADA)	not IFC at all ; `ifc-impl-geometry-extraction`

Library tools mirror this split : an ifcpatch Migrate recipe performs schema-version migration ; an IfcConvert-style tool performs geometry export. ALWAYS name the operation correctly before choosing a tool. This skill does NOT teach library APIs ; for tool selection see ifc-impl-library-selection.

Reference Links

references/methods.md : per-format facts, version coverage, the ISO 10303-28 and Part 28 detail, the preservation matrix.
references/examples.md : the same model in SPF, ifcXML, and ifcJSON, plus worked transcode walk-throughs.
references/anti-patterns.md : the conversion failure modes and why each fails.

Related skills

ifc-syntax-step-physical-file : the SPF .ifc encoding (ISO 10303-21).
ifc-syntax-ifcxml : the ifcXML encoding (ISO 10303-28, Part 28 config).
ifc-syntax-ifcjson : the provisional ifcJSON encoding.
ifc-impl-version-migration : schema-version change, NOT transcoding.
ifc-impl-library-selection : choosing a library or tool for a conversion.
ifc-errors-encoding-issues : string-escape and character-encoding failures.

Verified sources

All format facts verified 2026-05-20 via WebFetch against the buildingSMART sources in SOURCES.md : the IFC file-formats page, the ifcXML Implementation Guide v2.0, implementation agreement CV-2x3-154 (ifcZIP), and the buildingsmart-community/ifcJSON repository.