IFC Shared Geometry: Follow the Products Behind a Reused Shape

Ask what the recipient must identify

An equipment model can reuse a shape efficiently while retaining every product the recipient needs. It can also draw convincing equipment without retaining the product relationships needed for selection, quantities or coordination. The purchasing question is whether the receiving result preserves those relationships, not whether every visible object has its own independent copy of the same geometry.

For an IFC exchange, distinguish the product occurrence from the representation used to draw it. A product occurrence is an individual modeled object. Its representation describes its shape; its placement relates that shape to the model. Several occurrences can use common source geometry. Conversely, one occurrence can use more than one inserted shape.

The definitions here come from buildingSMART's documentation at immutable development commit ecca26ca450e8f164eac1e6e876ce840410e407a, read October 20, 2026. This identifies the texts used for the explanation, not the schema or model-view requirements of a particular delivery. Agree those for the actual exchange.

References: [IM3][IM4]

Follow the definition, insertion and product

IfcRepresentationMap supplies a reusable source representation and a mapping origin. IfcMappedItem refers to that source and supplies a mapping target using a Cartesian transformation. One source can therefore be inserted into several representations instead of being independently duplicated for each use.

Those entities describe representation reuse. They are not interchangeable with a product occurrence. An IfcProduct has its own representation and object placement, and common type information can provide geometry for multiple occurrences. The mapping transformation and the product placement participate at different levels of that relationship.

A receiving tool may expose these levels differently. A mesh resource, an inserted drawing item and a selectable equipment record need not have a one-to-one relationship. Ask the proposed exchange provider which level its quantity or selection result describes. A label such as instance is incomplete until its meaning is clear.

The coordinate-frame article linked below explains transformations and placement. Here, the relevant consequence is that changing a placement can distinguish two uses of the same source without requiring two different shape definitions.

References: [IM1][IM2][IM3]

IM-01: four products, five inserted shapes

Consider a fictional coordination exchange with four selected equipment-product occurrences, P1, P2, P3 and P4. These short labels stand in for distinct product identities; they are not IFC GlobalId strings. The selection deliberately includes complete modeled equipment products, rather than every geometric item in the file.

P1, P2 and P3 each have a body representation containing one mapped item referring to source map A. Their product placements differ. They are three separately identified products using one reusable shape definition.

P4 is one selected equipment-assembly product. Its body contains two mapped items referring to source map B, with different mapping targets positioning the two shapes within that product. In this stipulated data, those two internal shapes are not separate product occurrences. buildingSMART's IfcTypeProduct explanation explicitly illustrates multiple placements of a representation within a product occurrence; a repeated shape need not introduce another product.

The totals now answer three different questions. There are two source maps, A and B. There are five mapped items: three uses of A and two uses of B. There are four selected product occurrences. None of the three totals replaces another.

This is an original conceptual relationship example. No STEP file, exporter or receiving application was run. It establishes no installed equipment quantity, supplier kit contents or physical assembly design.

References: [IM4]

Compare three returns against the same task

Suppose the buyer needs to select each of the four equipment products and associate it with a coordination comment. A return containing only two unique source geometries cannot satisfy that task merely by naming A and B. It has identified reusable shapes, not the four selected occurrences.

Another return expands the five mapped shapes into five selectable drawing objects. That can be useful for geometric inspection. If it discards the product relationship, however, the recipient cannot tell that the two B shapes belong to P4. Treating all five drawing objects as independent equipment records would change the agreed population.

A useful return preserves P1, P2, P3 and P4 as the four product-level selections while retaining their geometry. Selecting P4 identifies one product with two mapped shapes. Selecting P1 identifies a different product from P2 even though both use A. The recipient can recover the product-to-shape association without guessing from location or appearance.

An importer may flatten or duplicate geometry internally and still preserve that association. Keeping the exact source encoding is not the only possible way to satisfy the recipient task. Conversely, retaining efficient shared geometry is insufficient if product identities disappear. Compare the actual result, rather than rewarding a particular internal mesh count.

If the purchase instead requires separately identified components inside P4, define that additional product population with the model author. Two visible subshapes do not supply it. The existing Revit component and quantity guide addresses the separate choice of which modeled components must participate individually in a schedule.

Read the dependency behind a common shape

Reuse also explains the reach of a geometry change. In IM-01, A supplies the shape used by P1, P2 and P3. If a later exchange issue changes A while keeping these references, the geometry supplied through A changes for all three products. P4's two B references do not acquire that change merely because all four products appear in one view.

Changing only P2's placement is a different change. It changes where P2's represented geometry is placed, without defining a new source A or moving P1 and P3. A review comparing two issues should distinguish a source-definition change from a change to one occurrence's relationship to that source.

Geometry reuse does not make every product property shared. The existing IFC type/occurrence article explains property defaults, local overrides and units. Nor does a common shape establish that three products have the same serial number, procurement status or connection endpoints. Those are separate information relationships.

For a recipient investigating an apparent repeated change, this dependency is useful positive evidence: identify which products refer to the changed source and which occurrence-level relationships differ. The explanation supplies no file-editing method or assertion that any particular receiving software preserves those dependencies.

References: [IM1][IM3]

Keep product identity and representation identity distinct

buildingSMART's IfcRoot definition assigns GlobalId to rooted objects, while resource-schema entities have a different role. A shared representation-map reference therefore does not replace the identity of each product using that representation. Preserve the product identities required by the exchange, rather than using a geometry-resource identifier as an equipment key.

For IM-01, P1 and P2 must remain distinguishable even when a viewer stores A only once. P4 must remain one selected product even when the viewer exposes its two shape uses for inspection. The receiving result should explain both relationships. A screenshot showing all five shapes cannot establish either one.

A product identity in a model is not proof that an identified physical item was received or installed. Likewise, a count of the selected model objects is not a material order. Keep the agreed information task, model issue and selection basis attached to the result before using it in a downstream workflow.

References: [IM5]

Buy a representative exchange before scaling it

Ask the proposed provider and recipient to demonstrate a small exchange containing several products that share a source and one product that uses that source more than once. This exercises a relationship that a single isolated object cannot expose. Use the intended software versions, actual delivery schema and authorized representative inputs.

For the fictional IM-01 requirement, the recipient should be able to distinguish four product selections, recover five inserted-shape uses and trace them to two source definitions. It should explain why P4's two shapes remain associated with one selected product. If the intended return is a report, that report should recover the same association instead of presenting unexplained totals.

Include a comparison of two issues when shared-change traceability matters. Ask the provider to identify a changed common source separately from a moved occurrence. That is an evidence request, not a claim that an exporter or viewer has passed a test here.

A successful sample establishes only the behavior demonstrated. It does not settle model completeness, geometric fidelity, field condition or engineering adequacy. The IFC validation and exchange guides retain those broader delivery questions.

Connect the information task to the planning package

Leviathan's Physical Infrastructure Planning and CAD service is the existing route for discussing layouts, routing coordination, schedules and engagement-defined documentation. Describe the receiving task: which product-level selections, common-shape relationships and downstream associations must survive the proposed output.

Use the related inquiry with an authorized representative input and the recipient's intended use. The engagement must confirm its tools, supported formats, production resources and reviewers before a specialist IFC demonstration is committed. This article does not establish an IFC software or model-conversion service.

Once that information question is resolved, the planning team can distinguish a useful equipment relationship from an attractive drawing. That makes the next scope discussion concrete without turning geometric repetition into an equipment count or an installation claim.