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?
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]
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%)
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.
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…
Hello Jeffrey, at 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. 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.
@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, 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.
@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.
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
