Parametric profiles as geometry

[TZwielehner]

We can already use parametric profiles for the creation of 3D geometries. But I guess it is not possible to use the profiles in e.g. annotations or as 2D geometries directly. Can we integrate profles in geometries somehow?

[aothms]

You could argue that the parametrized profile definitions are subtypes of IfcBoundedCurve just like composite curves and polylines. And then we can maybe skip the profile subclasses completely. Just extrude closed curves. I don't think we need extrusions of open curves in the physical world. We'd loose derived profiles and composite profiles, but I think there should be other generic ways to handle transformations and (de)compositions.

^ that would obviously not go in 4.4

You could also argue that the profiles should be subtypes of Ifc(Geometric)RepresentationItem. I think that's conceptually not wrong. Can anybody think of objections?

[Moult]

A profile is not the same as a curve.

A profile is a first class citizen to a structural engineer. So profiles as distinct objects (ideally rooted, like materials) should continue to exist, with names (standard steel sections for example). They can then be managed as a profile library and are critical for structural analysis with structural properties.

However the double up and slight misalignment between profile geometry and raw curve geometry is the true issue here. I'd be in favour of ensuring the curves are complete, then a profile would simply reference a curve.

[aothms]

I think we're agreeing, but can we paint the complete picture here. When a profile is a rooted thing it would naturally move outside of the representation resource and wouldn't participate in the extrusion itself anymore. It would just be a product with a curve representation?

[Moult]

Yes. That would be beautiful :)

[aothms]

Or maybe, what also been discussed. Make profile / mls the geometry definition of some higher order objecttype instance and abolish the procedural geometry definitions altogether and make it more so that you combine the various aspects of your geometry by looking at the hierarchy of type elements.

[TZwielehner]

Abolish the procedural geometries? Like the I-shape steel profile? I would like to have more of them, actually. Or another way to use them, like the door lining / panel predefined property sets. Those would reduce representation data even more (mostly extrusions and unfortunately Breps). Parametric, pset driven geometry / profiles would be really great.

[aothms]

abolish the procedural geometry definitions

Well, what I was sketching here was sth like:

IfcTypeObject - Profile=IPE200
  |
IfcTypeObject - Length=1000mm
  |
IfcBeam

I.e that at various levels of a type hierarchy you could define semantics/geometrical aspects without a need to create a representation item that puts all the pieces explicitly together in a single directed graph.

This without going into detail on what it really means and how it would be represented in detail. This is probably too much of a change with the core principles behind IFC, but it could be useful as a thought experiment.