# Qto\_\*\*\* properties expectations **URL:** \ **Category:** IFC\ **Tags:** properties, ifc4x3, ifc4\_3\ **Created:** [October 3, 2025, 4:03pm UTC](https://forums.buildingsmart.org/t/qto-properties-expectations/6298 "2025-10-03T16:03:09Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![jwouellette](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/jwouellette/32/2140_2.png) [@jwouellette](https://forums.buildingsmart.org/u/jwouellette)\ **Post date:** [October 3, 2025, 4:03pm UTC](https://forums.buildingsmart.org/t/qto-properties-expectations/6298/1 "2025-10-03T16:03:10Z")
As we further revise the US Bridge Design-to-Construction exchange standard, a question popped up about how the schema-defined Qto\_\* properties are expected to be used. I’ve looked at the documentation and past topic here in the forums and not found an answer to the question…. “Are users expected to fill these specific properties in manually or are vendors expected to automate them with internally derived values?” It seems that previous discussions have pointed out that the Qto properties and psets are subject to definitions based on a variety of standards that may be determined locally/nationally/per project. That would then suggest that automatic calculation would be impossible to accommodate such a variety of possible definitions and resulting values. If they are meant to be manually entered, then there should probably be documented guidance, in our case through the IDM, which specifies the rules in which quantities are expected to be calculated and entered by model authors. So, what is the consensus? Are they autogenerated or manual? ---
**Author:** ![aothms](https://avatars.discourse-cdn.com/v4/letter/a/c67d28/32.png) [@aothms](https://forums.buildingsmart.org/u/aothms)\ **Post date:** [October 6, 2025, 9:09am UTC](https://forums.buildingsmart.org/t/qto-properties-expectations/6298/2 "2025-10-06T09:09:11Z")
My interpretation is that historically this was a potential distinction: autogenerated vs manual. But since then: - In IFC4.3 IfcProperty.Specification (renamed from Description) was introduced and intended to point to a more formal specification (formula?) - I think people realised that whether something is derived or prescriptive information cannot be universally determined and depends on LOD and other aspects - Development of the specification began to favour Psets over Qto as well (also for ‘numeric’ data) [0] All in all I’d say it’s hard to give decisive guidance on this now. Quantities are limited to a small set of quantity kinds which means that for quantities out side of this range they need to properties instead (or plain numeric) - which means a general rule cannot be decided upon anyway. I think it’s best to review on a case by case basis and leave the door open for multiple interpretations depending on the type and information need of the exchange. [0] ```auto ifc4 to ifc4.3 additions: qto: 94 -> 115 (+22%) didn’t check whether these come from 4.1 4.2 or 4.3 pset: 420 -> 645 (+54%) ``` ---
**Author:** ![jwouellette](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/jwouellette/32/2140_2.png) [@jwouellette](https://forums.buildingsmart.org/u/jwouellette)\ **Post date:** [October 6, 2025, 8:23pm UTC](https://forums.buildingsmart.org/t/qto-properties-expectations/6298/3 "2025-10-06T20:23:36Z")
Ok. I guess we’ll proceed with using our own defined quantities, where needed and supply our own definitions/formulas, typically defined by AASHTO, ACI, AISC, or other related industry standards in the US. Then we’ll include them in the US Bridge/US Infra DDs. ---
**Author:** ![jwouellette](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/jwouellette/32/2140_2.png) [@jwouellette](https://forums.buildingsmart.org/u/jwouellette)\ **Post date:** [October 6, 2025, 8:27pm UTC](https://forums.buildingsmart.org/t/qto-properties-expectations/6298/4 "2025-10-06T20:27:26Z")
It’s a shame that we keep having these in\<\>out of classes and properties between versions, often without enough input or deeper investigation into whether or not they are a good idea to include or deprecate. I don’t blame any one directly, I just think that it points to a need for a better process, including architecture of the schema… let’s hope we don’t make the same mistakes for IFC5… ---
**Author:** ![Dieter-Hubertson](https://avatars.discourse-cdn.com/v4/letter/d/eb8c5e/32.png) [@Dieter-Hubertson](https://forums.buildingsmart.org/u/Dieter-Hubertson)\ **Post date:** [October 10, 2025, 1:15pm UTC](https://forums.buildingsmart.org/t/qto-properties-expectations/6298/5 "2025-10-10T13:15:09Z")
Hello Jeffrey, at [Qonic.com](http://Qonic.com) we see the QTO\_\* properties as being calculated automatically in Qonic, not being added manually. We follow the description of [ifc43-docs.standards.buildingsmart.org](http://ifc43-docs.standards.buildingsmart.org). To us these definitions are (or should be) a standard, not an interpretation depending on project/use case/country/… If there is room for interpretation then we need to finetune the definitions. ![image](https://us1.discourse-cdn.com/flex016/uploads/buildingsmart1/original/2X/0/0f355e726638514cc058c75634305740c684e7cc.png) ![image](https://us1.discourse-cdn.com/flex016/uploads/buildingsmart1/original/2X/f/f7e09ef29ab240296671c96dd8702f10f643ce95.jpeg) ---
**Author:** ![jwouellette](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/jwouellette/32/2140_2.png) [@jwouellette](https://forums.buildingsmart.org/u/jwouellette)\ **Post date:** [October 10, 2025, 4:02pm UTC](https://forums.buildingsmart.org/t/qto-properties-expectations/6298/6 "2025-10-10T16:02:41Z")
@Dieter-Hubertson one of the problems is that the Qto\_\*\*\* psets vary in which properties they contain for each different type of object…. some contain more or less than others, based on what someone might have considered “measurable”, at one point in time. Similar to my [Pset\_Address discussion on GitHub](https://github.com/buildingSMART/IFC4.3.x-development/issues/995), I would think it would be better to have ONE standard Qto pset, with ALL potential quantity properties. Then, they could be used in any combination, where applicable, before a stakeholder starts defining their own on an object type by object type basis. While I do appreciate Qonic going the automatic route, the question from the stakeholder point of view is “is that the correct method of defining the quantity?” For many cubic geometry entities it may seem obvious to the casual observer, but I’m learning A LOT about how that view is erroneous as I talk to the bridge domain experts. ---
**Author:** ![Dieter-Hubertson](https://avatars.discourse-cdn.com/v4/letter/d/eb8c5e/32.png) [@Dieter-Hubertson](https://forums.buildingsmart.org/u/Dieter-Hubertson)\ **Post date:** [October 13, 2025, 6:49am UTC](https://forums.buildingsmart.org/t/qto-properties-expectations/6298/7 "2025-10-13T06:49:38Z")
> [@jwouellette](#): > > Qto @jwouellette I prefer to have a description and a selection of measurements for each Entity Class, separated. For example, coming up with a clear definition of length that applies to all cases seems impossible to me. However, I agree that the current Qto definitions are only a starting point and should be refined further. ---
**Author:** ![steverugi](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/steverugi/32/2583_2.png) [@steverugi](https://forums.buildingsmart.org/u/steverugi)\ **Post date:** [October 13, 2025, 11:28am UTC](https://forums.buildingsmart.org/t/qto-properties-expectations/6298/8 "2025-10-13T11:28:36Z")
I use IFC4x3 in Blender/Bonsai Qto\_\*BaseQuantities are mostly OK for our models, (low-to-mid-range level of details) I don’t find the class-based set to be an issue