Proposal for new IfcZedShapeProfileDef

[Moult]

Taken from https://lysaght.steelselect.com.au/products/lysaght/lysaght-zed-cee-purlins-and-girts

In Australia we have Zed and Cees. Cees are handled by IFC here: http://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcCShapeProfileDef.htm

Zeds are not: http://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcZShapeProfileDef.htm - what IFC calls a Zed seems to be more of a hot rolled profile than a cold one.

How might this be handled? The name "Z" is already taken, and it is not exactly the same (e.g. hot Zs have a web thickness and a flange thickness whereas cold Zeds are just a single thickness and the edge radius doesn't apply. Therefore I'd propose a new shape but I wouldn't know exactly what to call it:

IfcZedShapeProfileDef?

Ping @jmirtsch as the structural expert in Australia.

Also curious if this is an Australian specific problem or also a problem in Europe/US? Ping @Jesusbill

[aothms]

Z and Zed sounds a bit easy to confuse. Can we find a more semantic name such as UniformThicknessZShapeProfileDef ColdRolledZShapeProfileDef ZShapeProfileDefWithLips

Searching around a bit there seems to be some others we don't support such as Sigma and Cee-Plus (some additional inwards lips).

The alternative is that we recommend CenterLineProfileDef with IndexedPolyCurve. It's not terrible either, but then we should provide some recommendations on conventions (like curve directions, center point) so that it's somewhat straightforward to cross reference the explicit coords with the parameters known by structural engineers.

We also have to learn from the CraneRail profile and Trapezium profile debacles after all.

I'm fine either way.

[jmirtsch]

There is some insight into standard profile shapes in Revit as outlined in this documentation. https://help.autodesk.com/view/RVT/2021/ENU/?guid=GUID-31C1849F-0BF4-4F9D-9F76-007F9831AB6F

There are a few shapes not in IFC.
Maybe I get off topic, but parametric profiles are not included in Reference View. MVD. I raised at the implementers meeting in Boston about publishing a Coordination Model View for IFC4.3 As I understand it there is no time frame for progressing Design Transfer view. If there is to be wide spread implementation of parametric profiles and enhancing what is already within the standard, I'd suggest a primary active MVD should include them.

[Moult]

ZShapeProfileDefWithLips

I like this.

there is no time frame for progressing Design Transfer view

A huge shame if vendors only focus on reference view, so much of IFCs capabilities become lost. It gradually degrades the users impression of IFC to be something no better than what you can achieve with dotbim, OBJ+CSV, Speckle objects, etc. MVDs are probably the wrong channel anyway, it would be good to have a combo of IDS and other Gherkin like expectations like "I need parametric layers and profiles".

< / end rant >

[TLiebich]

parameteric profile shapes

I am not sure whether adding more and more specific classes is the best solution. There are many (particularly cold-bend) profile definitions out, often also regulated by national standards, so that might lead to an extraordinary growth of profile classes. Maybe we should more look into a generic definition of parametric profiles.

As a very preliminary though - something like:

ENTITY IfcParametricProfileDefGeneric SUBTYPE of (IfcParameterizedProfileDef); ProfileShape : IfcProfileShapeEnum; -- list of shape types (T, Z, C, etc. with instructions being part of the specs) UserDefinedProfileShape : OPTIONAL IfcLaber; -- additional shapes, when ProfileShape is USERDEFINED ProfileParameterNames : LIST [1:?] OF UNIQUE IfcIdentifier; -- parameters like Web Thickness, etc. ProfileParameterValues : LIST [1:?] OF IfcNonNegativeLengthMeasure; -- corresponding list of values (assuming all lenght) ResultingCurve : OPTIONAL IfcIndexedPolyCurve; -- resulting closed curve as fallback END_ENTITY;

Of cause, this is more of an IFC5 discussion.

Design Transfer View

share the same frustration - but why should it be influenced by the MVD vs. IDS/Gherkin discussion? Personally I think we need both - a complete definition of the "to be implemented" subset of an MVD, and easier ways to validate IFC data pupulations, like IDS.

[Moult]

Instead of introducing many new attributes with a new entity why not just leave it as an indexed polycurve based profile def but attach a pset with parameters? Psets can belong to profiles and can be easily extended.

[aothms]

I agree, I think the semantic content propose by @TLiebich looks good, but we can probably use ProfileProperties for that. And to reiterate my comment. I'd propose CenterLineProfileDef (but it might need some additional clarity on what to do with the end points)

[TLiebich]

sure, this is another possibility - but I would still emphasise that parameter takes precidence over the polycurve. Just using the IfcArbitraryClosedProfileDef / IfcCenterLineProfileCurve with property sets pointing to it does not have quite the same meaning.

Anyway - my point was more - should we continue to expand fixed parameterized profile classes or opt for a generic approach. Second question (if answer to the first is: "generic") would then be how to encode such generic definition.

And there could be a hybrid definition:

ENTITY IfcParametricProfileDefGeneric SUBTYPE of (IfcParameterizedProfileDef); ProfileShape : IfcProfileShapeEnum; -- list of shape types (T, Z, C, etc. with instructions being part of the specs) UserDefinedProfileShape : OPTIONAL IfcLaber; -- additional shapes, when ProfileShape is USERDEFINED ResultingCurve : OPTIONAL IfcIndexedPolyCurve; -- resulting closed curve as fallback WHERE HasProfileParameter : SIZEOF (SELF/IfcProfileDef.HasProperties) > 0; END_ENTITY;

WHERE rule to ensure, that there is something attached (still weak, but anyway ...)

[Moult]

I guess the benefit of Psets is that it makes it easier for countries to add their own standard, and viewers can just rely on the polycurve instead of having to build support for N more parametric profiles around the world. The responsibility is on the IFC authoring / editing app to follow the parameters, not viewers.