IFC Type Properties and Occurrence Overrides: Read the Effective Value

Read the type and the occurrence together

A coordinator buys a report of equipment information from an IFC model. One proposed report repeats the equipment type's values for every object. Another lists only properties attached directly to each object. Both can look orderly, yet they answer different questions. The useful purchase is the information that applies to each identified occurrence.

An occurrence is an individual modeled object; its assigned type supplies a shared definition. IfcRelDefinesByType connects one type to one or more occurrences. Properties can exist on both sides of that relationship. Within a corresponding property set, the applicable properties combine the type's properties with the occurrence's properties. Where a property name occurs at both levels, the occurrence value takes precedence. A local change to one property does not discard the others.

The explanation here follows buildingSMART's IfcRelDefinesByType, IfcPropertySet and IfcPropertySingleValue development-document definitions at immutable commit ecca26ca450e8f164eac1e6e876ce840410e407a. These development texts were checked on October 20, 2026; they do not identify a latest released IFC build. Identify the actual delivery's IFC schema separately when commissioning a result.

References: [IFV1][IFV2][IFV3]

Identify the complete property path

A field called CoordinationAllowance needs its property-set context. ExampleCoordinationInputs.CoordinationAllowance identifies both the containing set and the property being discussed. A property with the same name in ExampleOtherInputs is a different path; it does not override the first merely because its final name matches.

IfcPropertySet provides the named container, and its individual property names must be unique within that set. The definition distinguishes occurrence attachment through IfcRelDefinesByProperties from attachment to a type. Looking only at directly attached occurrence sets can therefore miss shared information.

The examples use custom set names without the reserved Pset_ prefix. buildingSMART reserves that naming convention for sets defined by the specification. A project-defined name does not establish a standard requirement, and a familiar display label does not establish which set supplied a value. Preserve the actual names in the requested output; resolve an ambiguous mapping explicitly.

References: [IFV2]

IFV-01: three occurrences sharing one type

Fictional example IFV-01 contains equipment occurrences E1, E2 and E3, all assigned to type T. T has the custom property set ExampleCoordinationInputs. That set contains CoordinationAllowance with nominal value 0.60, typed as IfcPositiveLengthMeasure, and ReviewGroup with text value A. The project's length unit is metre, and the type's allowance property has no explicit Unit.

E1 has no local properties in that set. E2 has a local ExampleCoordinationInputs set containing only CoordinationAllowance: nominal value 800, also an IfcPositiveLengthMeasure, with an explicit millimetre unit. E3 has a local set with the same set name containing only ReviewGroup, with text value B.

These are invented project inputs for explaining information interpretation. They are not standardized equipment requirements, an actual IFC payload or the output of a software run. Keeping the inputs small makes the consequence of each interpretation visible: E2 changes the allowance, and E3 changes the review group.

References: [IFV1][IFV2][IFV3]

Resolve the values and their units

E1 obtains both fields from T. Its allowance is 0.60 m, or 600 mm, and its review group is A. The lack of local properties does not make E1's effective information empty.

E2 takes its allowance from the occurrence: 800 mm, equivalent to 0.80 m. Its review group remains A from T because E2 supplied no replacement for that property. Reading E2's entire local set as a replacement for the entire type set would lose the group.

E3 takes review group B from the occurrence. Its allowance remains 0.60 m, or 600 mm, from T. The two fields for one object can legitimately come from different levels.

For IfcPropertySingleValue, the nominal value carries its data or measure type. When Unit is supplied, that property unit overrides the global project unit; otherwise the applicable unit comes from the measure type and project unit assignment. Resolve the chosen property's unit before converting it. E2's explicit millimetre unit governs its 800 even though the project length unit is metre.

A useful normalized result is therefore E1: 600 mm/A; E2: 800 mm/A; E3: 600 mm/B. Retain the original typed values and unit sources alongside that presentation so the recipient can explain why E2 differs.

References: [IFV1][IFV3]

Compare the three proposed extracts

A type-only flattened report repeats 600 mm and group A for all three occurrences. It preserves the common starting point, but silently reports E2's allowance and E3's group incorrectly for the requested effective-value task. The clean rows hide the two local decisions.

An occurrence-only dump has no local fields for E1. It reports E2's 800 mm allowance without its inherited group and E3's group B without its inherited allowance. Those local records can be useful for reviewing exceptions. They are incomplete as the requested per-object information report.

A report that resolves both levels returns the three results above and identifies the source of each field. For E2, the allowance source is E2 and the group source is T. For E3, the allowance source is T and the group source is E3. E1 obtains both from T. This gives the recipient an explanation as well as a number.

Replacing an entire set whenever a local set exists introduces another error: E2 loses ReviewGroup and E3 loses CoordinationAllowance. The example needs a property-by-property combination. A report should also retain genuinely additional local properties within the corresponding set, rather than treating local data only as replacements.

Compare these proposed outputs against the same E1/E2/E3 population. A missing occurrence or a silently dropped inherited field cannot be repaired by changing a column heading to effective value.

References: [IFV1][IFV2]

Keep unset values and physical meaning visible

IfcPropertySingleValue permits an unset NominalValue. A property present without a supplied nominal value is not a numeric zero. It must also remain distinguishable from an absent local property. Return that state explicitly and agree any required treatment instead of inventing a number or silently assuming a fallback.

A bare 800 without its measure type and unit context is insufficient for the example's conversion. If the needed unit context is unavailable, identify that gap. Guessing from the magnitude would make two plausible-looking extracts harder to reconcile.

CoordinationAllowance is only an invented model-information input. Resolving it establishes what the example data says; it supplies no clearance requirement, product rating or installed dimension. Do not add it to an equipment footprint to manufacture a physical envelope. Engineering adequacy requires the applicable equipment, geometry and project evidence. A readable shape cannot decide which of the three extracts faithfully interprets these stored properties.

References: [IFV3]

Buy a representative recipient result

Before buying a full-population report, ask the proposed provider to demonstrate the intended result for a representative type and occurrences that exercise these distinctions. Include a type-only case, a numeric override with a different explicit unit, and an occurrence that overrides another field while retaining the inherited numeric value. IFV-01 supplies a compact comparison case; the project sample must use its own identified inputs.

Describe the return precisely. It should identify the model issue, IFC schema, object and assigned-type identities, complete set/property paths and the definitions used for interpretation. For each requested field, retain the original nominal value and type, the unit and its source, the effective value in the agreed reporting unit, and whether the selected property came from the type or occurrence. Keep absent, unset, ambiguous and unevaluated information visible.

Ask the recipient to recover the three expected pairs and explain their origins in the intended receiving environment or report. Name that environment and its version with the returned result. A provider offering raw local properties has described a different output from one demonstrating resolved per-object information. Neither a screenshot nor an opening model supplies the missing explanation.

Agree the target field population and output scope with the recipient. This is a bounded information task; a representative result establishes only the behavior actually demonstrated.

Bring the information task to planning

Use the related IFC conformity and IDS article for the separate question of standard conformity and specified information requirements. The Revit/IFC exchange guide addresses what must survive delivery. The Revit component guide covers separately schedulable instances and quantities, while the COBie guide follows asset references between Types, Components and Spaces. Those decisions remain with their existing guides; this article supplies the missing explanation of effective IFC property values.

Leviathan's Physical Infrastructure Planning and CAD service is the existing route for discussing layouts, routing coordination, schedules and engagement-defined documentation. Use the related project inquiry to describe which equipment or pathway objects matter, the fields the recipient needs and the output you want to discuss.

The engagement must confirm its authoring tools, delivery resources, reviewers and supported formats. Identify who will perform any specialist IFC extraction or receiving-application demonstration before committing that work. Bring the actual model-information question and an authorized representative input so the scope discussion can address the required result.