Hi,
I have been struggling with some QTO topics in my daily routines and would like to make an improvement suggestion.
When defining deliverables in a BEP, I often stumble upon Quantities that are not standard definitions in the IFC structure. This happens in most of the Projects in the German and Austrian region. For this reason, instead of having them in a QTO, they must be defined in a custom Pset, which IMHO, does not look clean. These components have a length, but do not possess a height and width.
The Entities in mind are: Qto_ColumnBaseQuantities Qto_BeamBaseQuantites
CrossSectionArea is in this case not enough to declare the dimension of the mentioned elements. The IfcLengthMeasure as a part of IfcElementQuantity is applicable for Length, Height and Width at some entities, such as: IfcWall, IfcFooting.
Hence, my suggestion would be to have also the Height and Width for Beams and Columns additional to length in the IFC 4.3 schema.
@jwouellette Do you know someone that should know it? Otherwise, it raises serious doubts about the suitability of addressing new schema requests here or there. I’ll ask Leon van Berlo, then.
@daviddelven I think it is appropriate to have the general discussion here and then once a decision has been made among the community, to file a formal issue on the corresponding GitHub repository. The person bringing up the issue and agreeing on the resolution can file it… But maybe @Evandro has a different opinion about this.
I like the suggestion from @jwouellette. The Forums seems the perfect place to socialise and workshop a proposal, before raising it to GitHub repository, in a proper template.
However, in this specific case, I would suggest considering bSDD. The use of quantities with bSDD can be far more interesting and quicker IMO. Definitely worth someone experimenting with it
nice discussion so far about the implementation. I am willing to send it to the next level when we reach an agreement about the solution.
therefore, do I understand that the suggestion for extending the BaseQuantites for the two entities brings benefits for the IFC structure? My German and Austrian colleagues will agree, what about the rest?
Can you define these?
What is the “width” of a column? What is the “height” of a column (as opposed to its “length” which is now defined)? What about non-rectangular columns? Profile-based? Don’t simplify to too much or clearly define when the width and height may be applicable.
Before you start defining such quantities and submit changes for standard QTO (Base Quantities), be sure that they are well agreed upon and understood and a related measurement method is defined. I stress this, because we are trying to align national guidelines as much as a possible to what is being defined within the IFC scheme, but at the same time there are also national standards to adhere to (just like your case of Germany and Austria). And they may conflict with other countries.
While not part of Base Quantities, it is currently possible to define custom Quantity Sets, which are very similar but the same as Property Sets. This is where I’d expect such non-standard quantities to reside.
Here is my in-depth explanation for this case:
A column is geometrically represented not only by a length, but also some sort of cross-section. Since we build mostly orthogonal columns and with one extrusion, the case of depth and width would represent the cross-section:
Having just the area of the cross-section does not fully define the geometry of a column. Therefore, adding the two attributes, I believe we have added value to many use cases.
One could say that in a spatial context, the width and depth could be one or the other. In my opinion, it does not matter how the column placed.
The column has a geometrical representation, with makes it differ from other columns or belong to a group.
The same applies for a Beam which has different dimensions.
Knowing about these two properties helps the understanding of how many columns or beams of the same geometry are present in the project. In a wider case, this identification helps technical documentation of the project
I am also aware of different types of cross-sections for columns. In the case of a beam, it is even more complicated, especially when we talk about T-Beams. The definition of the cross-section geometry in this case would be the bounding box or the nominal values of the cross-section. But in this case, we can distinguish between a normal beam or T-Beam based on their enumeration.
@stefkeB you mentioned that such quantites could be custom added to the QuantitySet.
does the schema allow this? As an Archicad user, is it possible to define it there?
Generally, IFC schema does not prohibit to add custom properties (quantities) in existing property sets.
It should not affect readers, but obviously you should have agreement with particular reader to recognize the data.
Refer to github I am not sure what is correct repository to submit issues now,
I created one qto request couple of months ago in bSI-InfraRoom/IFC-Specification but it is not answered yet.
The normal procedure would be to start a project in one of the rooms (or a joint project between rooms).
For just two properties that would seem an overkill, so probably it would be a wide evaluation of the Qsets.
As Evandro said, to use it in practise fast (and reliable) the bSDD is the perfect solution for it. You can publish your extensions and share them with the global community.
PS: there is even a plan to monitor usage of bSDD to find popular extensions and add those on the shortlist to be added to IFC in a next version. But that is long term planning and ideas.
Hi @berlotti
that sounds like a reasonable solution to use the bsDD. Is there any documentation on the proper usage of the database?
Also, where is the best place to publish the extensions to share them with the community?
