Incorrect and missing dimensional properties on Pset_CableCarrierSegmentTypeCableTraySegment CABLETRAYSEGMENT

[Moult]

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 which applies to IfcCableCarrierSegmentTypeEnum.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 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.

[aothms]

Your links point to localhost ;)

Did you see this? http://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/Pset_ElementSize.htm

Is this something we can extend or are the geometric properties too shape dependent to be generalized

[Moult]

Hahaha yes that's me being lazy copy pasting text and Github being clever.

That might work if it were extended, like outer / inner diameter and shape, and then potentially all the other psets can be replaced with this one.

[aothms]

and then potentially all the other psets can be replaced with this one.

Maybe that's something to discuss for the ISG soonish? To me it seems like the preferable approach. Single inheritance in the class hierarchy with a bit of "traits-based" modelling extension using psets. But maybe we should ask what the vendors think because it might be a bit of a change in focus/direction.

[CyrilWaechter]

• Add new dimensional / shape properties where missing for every predefined type.

As there is a need for heigh/width for almost any predefined type why not just move it in a pset that apply to all predefined type ? Less cases to handle programmatically no ?

• 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")

Having an oval shape defined by height/width is ok for me. I find more clean to have 3 parameter than a NominalDiameterOrWidth as done for ducts but maybe there is an advantage I do not think of.

• 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)

Not sure to understand what you mean. Maybe we can discuss it vocally.

[Moult]

As there is a need for heigh/width for almost any predefined type why not just move it in a pset that apply to all predefined type ? Less cases to handle programmatically no ?

Yes, Actually I think the new Pset_ElementSize is a good match for this.

Having an oval shape defined by height/width is ok for me. I find more clean to have 3 parameter than a NominalDiameterOrWidth as done for ducts but maybe there is an advantage I do not think of.

If @aothms has time for a very last minute change maybe he can sneak in NominalDiameter (which already exists, just needs to be added)

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)

Measured length is not a property, it is a quantity. It should be removed from the property and stored in quantity.

But actually now rethinking this because fabrication segments do potentially have a length per type.