buildingSMART / buildingSMART/IFC4.x-development

Incorrect and missing dimensional properties on Pset_CableCarrierSegmentTypeCableTraySegment CABLETRAYSEGMENT

Open
#233 5 comments 0 reactions 0 assignees View on GitHub
allocated-mepf ifc-update-out proposal
Dominant language
Python
Stars
234
Forks
123
Avg merge
15h 4m
Merged PRs (30d)
5

Description

When we are modeling walls and slabs, the layer set usage allows us to insert a new instance of a type and we can generate a sensible shape due to the layer set data. Similarly for profile sets and structural modeling - the profile set means that any implementer can build a tool that goes "click click beam" and the profile will be automatically generated correctly. These material sets are vital for parametric native IFC modeling / programmatic model generation.

Similarly for MEP modeling, layer and profile sets aren't used, but instead the convention seems to be storing the geometrical properties on psets. For example, IfcDuctSegment(Type) has Pset_DuctSegmentTypeCommon which gives a shape (e.g. rectangle) and a width, height, or diameter. This means that if I want to insert a new duct segment, it's click click boom.

PipeSegments provide an inner and outer diameter, and specific to predefined types (e.g. CULVERT) they also give widths. So this works out well. Same with CableSegments - a diameter property is always provided.

CableCarrierSegment is the odd one out.

[Pset_CableCarrierSegmentTypeConduitSegment](http://localhost:5000/IFC/RELEASE/IFC4x3/HTML/lexical/Pset_CableCarrierSegmentTypeConduitSegment.htm) which applies to [IfcCableCarrierSegmentTypeEnum](http://localhost:5000/IFC/RELEASE/IFC4x3/HTML/lexical/IfcCableCarrierSegmentTypeEnum.htm).CONDUITSEGMENT has width and height and shape, which is confusing because the shape is oval or circular for which width and height should probably be rewritten as diameter (+ diameter2 or something)

However [Pset_CableCarrierSegmentTypeConduitSegment](http://localhost:5000/IFC/RELEASE/IFC4x3/HTML/lexical/Pset_CableCarrierSegmentTypeConduitSegment.htm) only applies to CONDUITSEGMENT so for the more common case of CABLETRAYSEGMENT it seems as though there is no dimensional/shape data.

Also missing for trunking, catenary wire, dropper, and ladder segments.

I propose:

1. Add new dimensional / shape properties where missing for every predefined type.
2. Rename width and height to diameter X and diameter Y for conduit segments, OR add a new rectangle shape if relevant then also rename the properties (e.g. ducts use "NominalDiameterOrWidth")
3. Remove the "Length" property on pipes (in all other segments length has been removed since it is a case by case, not a typology in the Qto data)

Ping @CyrilWaechter thoughts? Without this feature, it would be very difficult to build native IFC authoring for cable carriers.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.