IFC Data Integration
An IFC file can validate against the schema and still disagree with the last one about which storey a wall belongs to. This guide works through the decisions a construction platform makes when it ingests IFC: which encoding to accept, what identity is keyed on, how the spatial tree is discovered, where properties and quantities really live, how uploads are validated and how models are placed against each other.
20 min read
50 views
- A file can be schema valid and still unusable Model view definitions carry the containment and placement rules the schema leaves out, and they have deviated from it in practice.
- GlobalId is a fixed 22 character string, not a UUID It is a compressed 128 bit identifier in a base64 variant, and only entities rooted in IfcRoot carry one at all.
- Walk the spatial tree, never assume four levels The depth is explicitly project dependent, and containment and reference are two different relationships a loader has to read.
- Properties live on the type as often as on the element A set assigned to an object type is shared across every occurrence, so occurrence only extraction never sees it.
- IDS checks content where certification checks the exporter Any model from any authoring tool can be checked against an IDS file, which puts the requirement on the side that receives it.
IFC data integration begins with a file that parses cleanly and still does not mean what the last one meant. Two exports of the same building can validate against the schema and still disagree about which storey a wall sits on. buildingSMART documents the cause against its own ecosystem on the model view definition page: "In fact, MVDs have frequently deviated from the intended semantics of the IFC specification." Its consequence is stated on the same page, "As a result, different MVDs can enforce mutually incompatible interpretations of the same IFC model." A platform that treats an upload as a settled document inherits that disagreement silently.
In short: the decision table below holds the ten decisions this guide works through. Four are the ones this guide returns to. Identity is keyed either on GlobalId or on a surrogate the platform invents. The spatial tree is either walked through its relationships or assumed to be site, building, storey and space. Properties are read off occurrences alone or resolved through the type level first. And an upload is either validated for content or only for syntax.
Why two valid IFC files disagree
A model view definition is a subset of the schema built for one exchange scenario, and buildingSMART is blunt about the standing of those subsets on its model view definition page: "MVDs must be recognized for what they are: separate standards in their own right." The same page carries the caveat, "While MVDs are based on IFC, they do not always strictly adhere to it." An importer written against one view is an importer written against one standard rather than against IFC.
Narrowing is concrete enough to break working code. A view may restrict what an exporter is allowed to emit, and the same page gives an example: "They may allow only IfcMaterialLayerSet for materials and restrict geometry to just SweptSolid or BRep." buildingSMART names one pair where that breaks down: "Data created according to IFC4precast MVD cannot reliably be read or interpreted by Reference View-compatible software".
Nor does the schema settle the question. The IfcBuilding entity page says where the real rules live: "Detailed requirements on mandatory element containment and placement structure relationships are given in model view definitions." That one sentence is why a file can be schema valid and still useless to a consumer. Those containment rules are given there rather than in the schema.
buildingSMART's own answer is to move the requirement out of the exchange format and into a checkable statement of what the receiver needs. Its position paper frames that as a scope question: "This is the part that matters to the end user, and it is the scope that can be fully described using Information Delivery Specifications (IDS)." Pharos Production practice follows that split. Accept several views on ingest, record which one a file claims and validate content separately.
Integration decisions and their failure modes
Each row below stands on its own. The options column is sourced from the buildingSMART pages cited here, while the choose-when and failure-mode columns are Pharos Production practice rather than requirements of the standard. Every section after the table works through one row.
| Integration decision | Options (sourced) | Choose when (Pharos Production practice) | Failure mode (Pharos Production practice) |
|---|---|---|---|
| Ingest encoding | STEP physical file, ifcXML, ifcZIP or ifcJSON | Accept the STEP physical file, recommended for file based exchange and the most widely used in practice | A pipeline built on ifcJSON, classed under Provisional/Candidate and listed as under development |
| Parsing strategy | Server side pre processing into the platform's own store, or client side parsing of the original file | Pre process server side wherever properties, quantities, search or reporting matter | A gigabyte model parsed on a laptop, where in our experience the ceiling arrives on the client long before the server |
| Identity across revisions | GlobalId, a platform assigned surrogate, or a composite of GlobalId and source file | Key on GlobalId for anything rooted in IfcRoot and assign a surrogate for resource level data, which carries none | A 36 character UUID column, when GlobalId is a fixed 22 character string in a documented base64 variant |
| Revision model | Trust OwnerHistory, or build a platform side revision model | Always build platform side, since OwnerHistory is optional and stores only the last modification | Treating a file as a version controlled model when it is a snapshot of one business transaction |
| Spatial tree construction | Walk IfcRelAggregates from IfcProject down, or assume site, building, storey and space | Always walk the relationships, since the depth is explicitly project dependent | A hard coded four level import dropping building sections, storey complexes and partial storeys |
| Element to level assignment | Read containment only, or read the reference relationship as well | Read both. Containment answers where an element lives, reference answers where it appears | A lift shaft belongs to the basement and vanishes from every floor it passes |
| Property extraction | Occurrence property sets only, or type level sets resolved first with occurrence overrides applied | Always resolve the type level first, then apply occurrence overrides | Properties are missing, because the set sits on the object type |
| Quantity handling | One quantity per element, or quantity sets keyed by method of measurement | Key by method of measurement wherever costing or regulatory reporting touches the number | Two areas for one space overwrite each other, since several quantity sets with different methods are legal on a single element |
| Validation hook | Rely on the exporter's MVD certification, validate content with IDS or accept anything that parses | Validate content with IDS at the upload boundary and treat MVD conformance as the exporter's problem | A missing data set surfaces in the consuming workflow rather than at upload, when nobody can still ask for a re export |
| Georeferencing | Read the map conversion and coordinate reference entities, or fall back to site latitude, longitude and elevation | Require the map conversion for anything that federates, overlays a map or joins survey data | Federated models are misplaced against each other on attributes documented as approximate |
The schema as a data model
IFC is a data schema before it is a file format. Published as ISO 16739-1:2024, it covers the schema, its documentation and the property and quantity set definitions a platform maps onto its own columns. The free HTML and the ISO text are not the same artifact, and the documentation root says how they differ: "The structure and semantic contents of this are exactly the same as the ISO IFC 4.3 but with additional examples and clarifications in the documentation."
Version targeting is a compatibility question with a published rule behind it. buildingSMART's release database uses a four part notation of major, minor, addendum and corrigendum. It states what each level promises: "Addendums consist of improvements to existing features, where the schema may change but upward compatibility is guaranteed." Major versions may break compatibility and corrigendums change documentation without touching the schema. IFC 4.3 ADD2 (4.3.2.0, ISO 16739-1:2024), IFC 4 ADD2 TC1 (4.0.2.1, ISO 16739-1:2018) and IFC 2x3 TC1 are all marked Official at once, which is why a platform targets more than one.
GlobalId and identity across revisions
Not everything in an IFC file is independently addressable. The IfcRoot entity page draws the line: "All entities that are subtypes of IfcRoot can be used independently, whereas resource schema entities, that are not subtypes of IfcRoot, are not supposed to be independent entities." An importer that treats every instance as a first class row is building on the wrong set.
The layer architecture is where that line falls. The specification's Introduction states the rule: "all entities defined at the core layer, or above carry a globally unique id and optionally owner and history information". Resource level data carries none, so a platform that needs to address it assigns a surrogate that means nothing outside the platform.
That identifier is not the UUID a database expects. The IfcGloballyUniqueId page states the purpose, "An IfcGloballyUniqueId holds an encoded string identifier that is used to uniquely identify an IFC object.", and the reason for its shape, "Since this identifier is required for all IFC object instances, it is desirable to compress it to reduce overhead." Underneath sits a 128 bit GUID, compressed by a base64 process documented as differing from common implementations and stored as a fixed 22 character string whose first character is always 0, 1, 2 or 3. A 36 character UUID column rejects or mangles it.
IFC carries no revision history of its own. OwnerHistory is optional on every rooted entity and only the last modification is stored. Object versioning restrictions are deferred to view definitions and implementation agreements. Framing on the introduction page is the same: "Today, IFC is typically used to exchange information from one party to another for a specific business transaction." A file is a transaction snapshot. The revision model, the diff between two uploads and the lineage of an element across them are platform work, and in Pharos Production practice they are the first thing a construction platform owns outright.
The spatial tree and where an element lives
Everything in an exchange hangs off one root. The IfcProject page describes the job precisely: "The IfcProject's main purpose in an exchange structure is to provide the root instance and the context for all other information items included." Read a file from there rather than from a flat sweep of instances.
Spatial breakdown is not a fixed quartet. The IfcSpatialStructureElement page generalizes site, building, storey and space into one abstraction and states the depth rule: "A spatial project structure might define as many levels of decomposition as necessary for the project." It also gives the invariant a loader must enforce rather than assume: "The spatial project structure, established by the IfcRelAggregates, shall be acyclic." Hard coding four levels drops building sections, storey complexes and partial storeys, all legal CompositionType interpretations.
Elements attach to a level through a relationship rather than a parent pointer, and the cardinality is strict. buildingSMART's containment relationship page states it: "The containment relationship of an element within a spatial structure has to be a hierarchical relationship; an element can only be contained within a single spatial structure element." Its companion relationship is where multi storey objects actually live: "The reference relationship between an element and the spatial structure need not be hierarchical; that is, an element can reference many spatial structure elements." An importer that ignores reference makes a lift shaft belong to the basement and disappear from every floor it passes.
Which level is correct for which element is not settled by the standard at all. That same page says so outright: "The question, which level is relevant for which type of element, can only be answered within the context of a particular project and might vary within the various regions." Pharos Production practice is to negotiate the convention with the authoring side before the first upload, validate it on ingest and keep a geometric re derivation as a diagnostic, never as a silent correction.
Aggregation carries a dependency that a platform's delete path has to respect. The IfcRelAggregates page states it in both directions: "Decompositions imply a dependency, implying that the whole depends on the definition of the parts and the parts depend on the existence of the whole." Enforcement is then handed to the reader, because the implied behavior has to be established inside the applications. Removing a storey is never a single row operation.
Properties and quantities are a traversal
Property extraction is easy to underestimate, because the key space is unbounded by design. The IfcPropertySet page describes predefined sets carrying a significant name and then opens the door: "In addition any user defined property set can be captured." Standard property sets are prefixed Pset_ and standard quantity sets Qto_. Everything else is a local convention or one modeler's habit that still has to survive ingest.
Some of the properties are not on the element being read. That same page states the sharing rule: "An IfcPropertySet assigned to an object type is shared among all occurrences of the same object type." An importer that reads occurrence sets alone returns a wall with no fire rating, because the rating was set once on the wall type.
Attachment itself is a graph edge rather than an attribute. The IfcRelDefinesByProperties page gives the cardinality: "The IfcRelDefinesByProperties is an N-to-N relationship, as it allows for the assignment of one or more property sets to one or more objects." Reading properties is a traversal in both directions, and a flat column mapping loses the many side of it.
Quantities are harder, because one element legitimately carries several answers. The IfcElementQuantity page ties a single quantity set to a single method of measurement and then allows more than one: "However several instances of IfcElementQuantity are assignable to an element, thus allowing for an element having quantities generated according to several methods of measurement." A table storing one area per space overwrites one measure with another and reports the survivor as fact.
Vocabulary is not fixed either. That same page defers it: "The recognizable values for the name and the method of measurement attributes have to be agreed upon in further agreement documents, such as implementers agreements." In Pharos Production practice a quantity is stored keyed by its method of measurement, and the base quantity set counts as one method among several rather than as the truth. Any costing output names the method it used.
One wall traced end to end makes the order concrete, and the order is our practice at Pharos Production rather than a sequence the standard prescribes. The file is parsed server side, and the wall's GlobalId becomes its key because a wall is rooted in IfcRoot. Containment answers which storey it lives on and the reference relationship answers which other storeys it appears on, so a two storey wall is written once and indexed twice. The object type is resolved next, its property sets read first and the occurrence sets merged over them, which is where a fire rating usually arrives. Quantity sets are stored one per method of measurement. The IDS run then checks that merged record rather than the raw file, and a wall still missing its fire rating fails the upload.
Choosing an encoding for ingest and for serving
Size is a stated consideration rather than an implementation detail. buildingSMART's IFC Formats page says so: "As building data can be quite large (i.e. gigabytes), the choice of format may have practical considerations." Its relative size figures put the STEP physical file at 100 percent, ifcXML at 113 percent, ifcZIP at 17 percent and JSON at 148 percent, a statement about encodings rather than about any real file.
For ingest the recommendation is unambiguous. That same page states it: "For the widest compatibility and smallest size for file-based import and export, STEP Physical File (SPF) is recommended." That page also calls it the most widely used format for IFC in practice, which settles the question before the recommendation does.
A STEP physical file cannot be interpreted without the schema. The specification introduction describes the encoding: "It is a clear-text encoding of the entity instances that make up the exchange, in which attribute values are provided as an ordered sequence of unnamed values." Attribute meaning comes from position in an EXPRESS entity definition, so a parser that does not load the schema is guessing at every field.
None of that makes one encoding mandatory. The scope clause leaves the door open: "Alternative exchange file formats may be used if they conform to the data schemas." Recommended and prevalent describes the STEP physical file accurately. Canonical and required do not.
JSON answers a real complaint and is not finished. buildingSMART's ifcJSON repository states the motivation in two parts, the reach of the tooling, "Many developers have never seen/used EXPRESS or STP instance files before, which increases the effort required to extract data required from them.", and the shape of the exchange itself, "IFC instance populations are typically exchanged as files, which is at odds with linked, distributed, and rapidly changing data seen on most design and construction projects and products." The formats table classes JSON under Provisional/Candidate rather than Official and the scope clause lists the JSON schema as under development, so treat it as a candidate encoding, not an ingest contract.
On the serving side the decision reverses, and what follows is Pharos Production practice rather than anything the specification requires. Convert once at ingest into the platform's own normalized representation and serve that. The IFC Formats page notes that any of these formats may be negotiated between clients and servers, and none of the pages read for this article says anything about what an application stores. Keep the original file addressable for provenance rather than making a browser reimplement an EXPRESS parser.
Validating what arrives with IDS
Certification and validation are different questions and only one belongs to a platform. A model view definition is what a vendor names when applying for software certification, and the specification's Introduction records the current policy: "The official MVD policy for IFC 4.3 currently holds 3 levels of implementation for IFC". Those three are Reference View, Alignment Based View and Design Transfer View. A certified exporter tells you a file came from a known subset, not whether this file carries the data a downstream workflow needs.
Information Delivery Specification is the hook that does. buildingSMART's IDS user manual defines it, "Information Delivery Specification (IDS) is a buildingSMART standard for specifying and checking simple information requirements from IFC models.", and puts the check on the receiving side: "Model recipients may use the IDS file to check whether the IFC model meets all of the Specifications." That is exactly the position a platform occupies at an upload boundary.
Internal structure is what makes a requirement automatable. That same manual splits it in two: "Specifications consist of two parts: applicability - describing what elements are subject to this specification, and requirements - listing what those applicable elements should or shouldn't have." Both halves are built from facets such as property, entity, classification, material or partOf, and the manual's worked example is that all walls must have a fire rating property.
Portability across authoring tools is the claim that makes IDS worth building against. The user manual states it plainly: "Any IFC model produced from any software can be checked against an IDS file." A model view definition is a property of the exporter; an IDS is a property of the receiver, which is the right way round for a platform that cannot dictate what its clients model in.
Support for it is testable rather than merely claimed. buildingSMART's IDS documentation index records the conformance material: "The folder also contains a suite of over 250 test file pairs (.ids and .ifc) for verifying the correctness of the software implementation reading and checking capabilities". The repository also carries the XML schema and implementers documentation covering details such as numeric tolerance. Pharos Production practice is that an upload is accepted only after an IDS run, with the report stored against the upload record.
Georeferencing and federated models
Coordinates are where federation quietly fails. The IfcMapConversion page defines the transformation: "The map conversion deals with transforming the local engineering coordinate system, often called world coordinate system, into the coordinate reference system of the underlying map." It carries eastings, northings, orthogonal height, optional axis direction values and an optional scale factor, and it does not project from the geodetic reference system. It places a model rather than reprojecting it.
A fallback exists and is documented as a fallback. The IfcSite page names the authoritative route, "Precise geospatial information of a site shall be derived from the georeferencing entities that relate the IfcProject to the real world, using sets of datum (see IfcCoordinateOperation and IfcCoordinateReferenceSystem).", and warns about the alternative: "This methodology is not meant to replace precise georeferencing, but can still be useful for those use cases that do not require accurate geospatial information (e.g., sun shading simulations)." Latitude, longitude and elevation are an approximation, and a federation built on them cannot be trusted to place two models against each other.
Federation itself is practice rather than specification. None of the pages read for this article describes how two IFC files are combined into one coordinated model, so treat the following as Pharos Production practice. Require the map conversion on every incoming model and quarantine a file without one rather than dropping it at the origin. Resolve every cross model query in the shared reference system rather than in a single file's local frame. Site sensor feeds follow the same rule, and our IoT development guide covers that layer.
Infrastructure models position elements by a different method, and a building only importer has no code path for it. IFC 4.3 brought bridges, roads, railways, waterways and port facilities into the standard, and the IfcAlignment page states how placement works there: "The relative positioning along the alignment is defined by the linear referencing methodology." An element on a road sits at a distance along a curve rather than inside a storey, so a spatial tree walk finds nothing and reports an empty model instead of an unsupported one.
Large models and the shape of the pipeline
Semantics and geometry separate cleanly, which is the structural fact a pipeline design leans on hardest. The IfcProduct page makes representation conditional: "An IfcProduct occurs at a specific location in space if it has a geometric representation assigned." A product is defined by its properties and its representations, and because representation is a separate assignment the two can be stored and served independently.
What follows is Pharos Production practice rather than a requirement of anything published, since none of the pages read for this article says anything about storage. Parse once on the server into two stores. One holds the semantic graph, the spatial tree, property sets and quantities, keyed on GlobalId. Another holds a tessellated geometry artifact keyed on the same identifier. Search and reporting then answer from the semantic store without touching geometry.
Client side parsing of the original file is the alternative, and its fit is narrow. It keeps the pipeline short and stops paying the moment properties, cross model search or reporting matter, because every consumer then reimplements the same traversal.
A semantic store keyed on stable identifiers lets an operations layer join model data to live readings from a building, and the digital twin patterns in our manufacturing software development guide depend on that separation. A platform that only ever produced a tessellated viewer file has nothing to join on.
How Pharos Production helps
An IFC data integration is four pieces of software and one written agreement: a schema aware parser that loads the spatial tree through its relationships rather than by assumption, a semantic store keyed on GlobalId with type level properties resolved and quantities kept per method, a geometry pipeline that serves a viewer without serving the source file, an IDS gate at the upload boundary and a convention with the authoring side about which level owns which element.
Our construction software development work covers those pieces: the ingest pipeline, the normalization that absorbs property set drift between authoring tools and the validation gate that turns a silent data gap into a rejected upload at the boundary.
Sources: buildingSMART International on technical.buildingsmart.org (the IFC introduction, the IFC specifications database, the IFC formats page and the model view definition page); the official IFC 4.3 HTML documentation on ifc43-docs.standards.buildingsmart.org (the documentation root, clause 1 Scope, the Introduction and fourteen entity pages); the buildingSMART IDS and ifcJSON repositories on GitHub. ISO 16739-1:2024 and ISO 16739-1:2018 are cited by title and edition. Read on 17 September 2026. Engineering guidance, not legal advice.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 6
No matches
Try a different keyword, change the topic or clear filters
-
Adopt in almost every case. What follows is our reading at Pharos Production rather than a position any standards body takes.
A schema aware parser has to load an EXPRESS definition, resolve unnamed positional attributes, follow relationship objects in both directions and keep working across more than one schema version, and none of that is where a construction platform differentiates. What is worth building yourself sits above it: the normalization into your own model, the revision logic between uploads and the validation gate. Budget for the parser being replaceable, so keep its output behind an interface of your own rather than letting its object model leak into your database.
-
It happens, and a pipeline has to survive it rather than assume it away. Our experience is that an authoring tool can reissue identifiers on export, on a round trip through another application or after a rebuild of part of the model, and the specification offers no lineage mechanism because it defers object versioning to view definitions and implementation agreements.
Pharos Production practice is to treat a changed identifier as a delete plus an insert by default, then reconcile with a secondary match on type, spatial parent, name and geometry extent. Surface that reconciliation to a human rather than resolving it silently, and give anything a user annotated a stable platform side key that outlives the file.
-
No, and conflating them creates work nobody planned. An IFC file is an exchange of model data for one transaction, so a pipeline around it answers questions about elements, spaces, properties and quantities.
Drawings, specifications, contracts, correspondence and the approval trail around them are documents, and they need versioning, permissions and retention rules an element store does not provide. The useful link between the two is identity: store the source file in the document layer, keep its hash and its upload record, then reference that record from every element the ingest produced so a value can always be traced back to the file it came from.
-
Pharos Production defaults have counter conditions worth naming. Server side pre processing is wasted where a platform only ever displays a model and nobody queries it by property, and a viewer parsing the original file is the simpler answer there.
Keying quantities by method of measurement is overhead where a single method is contractually fixed for a whole project. An IDS gate that rejects uploads is wrong during early design, when models are deliberately incomplete and a warning is more useful than a refusal. Requiring a map conversion is disproportionate for a single building that never federates with anything else.
-
Read them rather than assuming them, and record what you read. Pharos Production practice is to take units from the file rather than from a default, because in our experience a platform that hard codes millimeters eventually meets a model authored in feet and inches, and the error surfaces only when a quantity report goes out.
We convert everything to one internal unit at ingest, keep the source unit on the record and treat a model whose declared unit conflicts with its coordinate magnitudes as suspect rather than converting it anyway. Precision follows the same rule: store what arrived and round only at presentation.
-
A short acceptance run against real client files rather than a sample model. Every element resolves to a spatial level, and elements that reference several levels appear under each.
Property counts match between a type level resolution and a manual check on a handful of occurrences. A space with two quantity sets keeps both, with their methods of measurement intact. An IDS run produces a report that is stored and readable. Two models with map conversions land in the same place when federated, and one without a map conversion is quarantined rather than placed at the origin. The checklist is Pharos Production practice and passing it is not certification.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
