Fascias and Wall Sweeps not able to override IFC Class from BuildingElementProxy

[jokopperud]

I'm trying to eliminate elements exported as BuildingElement Proxy IfcClass. This has been unsuccessfully even though i am setting them as another IfcClass in the IFC options and also using the "IfcExportAs" parameter. The Fascias and Wall sweeps are nonetheless exported as BuildingElementProxy category. Is there another way to do this?

[Moult]

As far as I am aware, there is no solution. However what I do is edit the user defined parameter mapping file such that the IfcExportAs and IfcExportType fields are exported (by default they are excluded), so that when a client asks why the IFC classes are wrong, I can point them to those parameters and say that we did our best, but unfortunately that's the limit of Revit's capabilities.

[AngelVelezSosa]

I'm working on this now. Question - what should the default for fascias and gutters be? I believe gutters are IfcPipeSegments of type Gutter. Fascias are set to export as roofs by default. Wall Sweeps will still be set to buildingelementproxy by default. Slab Edges will also be proxies. Are there better defaults? The intent is that all will be overrideable, just looking for ideas on best default values.

[Moult]

Gutters indeed are pipe segments of type gutter. I believe fascias are just coverings, not roofs. Slab edges are just a modeling hack but in reality is part of the slab itself, so I'd say it's still an IfcSlab.

[JOuellette-Autodesk]

IfcRoof is meant to be... 1) either an aggregation of all the parts that compose a roof structure, including but not limited to slabs, coverings, rafters, members, skylights, gutters, etc., each with their own shape and semantic representation... OR 2) A single object that represents a monolithic roof plane.

A fascia is not a Roof, but a component of a roof "system".

Thus, my suggestion is that for IFC2x3 and IFC4...

1. a gutter is a IfcPipeSegment.GUTTER (agree with Angel)
2. a fascia is an IfcCovering.MOLDING (can be overridden to USERDEFINED.FASCIA) - which can be part of an IfcRoof aggregation
3. a soffit (the underside covering of a roof eave) is an IfcCovering.CLADDING (can be overriden to USERDEFINED.SOFFIT) - which can also be part of an IfcRoof aggregation
4. a wall sweep... I would use IfcBuildingElementPart.USERDEFINED.Wall Projection as a part of the IfcWall container OR a IfcFeatureElementAddition as part of the IfcWall. The problem with IfcBuildingElementProxy is that it is too vague and meant to be more abstract a concept, especially for IFC4.
5. Slab edges should be treated in the same way as wall sweeps, either IfcBuildingElementPart or IfcFeatureElementAddition.

Comparatively, I know for Wall Sweeps and Slab Edges, Vectorworks defaults to IfcBuildingElementPart for IFC4 CV2.0.

Would love to get feedback from others.

[JOuellette-Autodesk]

For IFC4.3, IfcBuildingElementProxy is NOT to be used any longer. It exists in IFC4.3 only for backward compatibility. And IfcFeatureElementAddition is an Abstract, not to be instantiated. Instead... Wall Sweep and Slab Edge would equal IfcProjectionElement.USERDEFINED, a subtype of IfcFeatureElementAddition. Users could decide what to call the Wall Sweep or Slab Edge.

Of course, I need to double-check to make sure this is in line with the current IFC4.3 Reference View development

[AngelVelezSosa]

IfcProjectionElement makes sense to me, since IfcBuildingElementPart implies a subset of object instead of an add-on.

[Teun1]

I have seen Wall Sweeps beeing used in all kind of context. It is a very flexible and fast way to model all kind of stuff in Revit. Often it is some kind of Covering. But it could also be a part of the Wall just as a Slab Edge is a part of a Slab. In some occasions you can make a Part of the Sweep, and map the Part to something more specific. Not perfect, but it gives an option.

[JOuellette-Autodesk]

Right now, we're just trying to find consensus on the best default setting, knowing that users will customize this according to their particular need. IfcBuildingElementProxy won't work anymore.

[andydandy74]

I think the default export behaviour that @JOuellette-Autodesk proposes makes total sense, but just wanted to add we've also had other requirements in the past so having the export behaviour not hardcoded for these element types would be great. Examples:

• Slab edges hosted on foundation slabs -> IfcFooting.STRIP_FOOTING
• Slab edges hosted on floor slabs -> IfcBeam
• Wall profiles -> IfcCovering (MOLDING &CLADDING and most recently SKIRTINGBOARD)

[Teun1]

In 23.3.1.0 Wall Sweeps seem to be able to map to a specified IFC entity in Revit And nested Wall Sweeps are beeing mapped based on the overall IC export mapping table. I see IfcCovering, IfcMember and IfcBeam. Nice.

[aksel-a]

Hi there! I'm a bit frustrated that I can't get this to work. Certainly I'm doing something wrong, but I don't know what, maybe you can help me to sort this out.

In the picture you see how my IFC looks like and how the export layers files looks for this case. I get the object to be exported in the correct Layer (Ebene) but I don't manage to change its IFC Type which would be great, since I have to avoid having Proxy Elements in my model.

[AngelVelezSosa]

Did something other than IfcBuildingElementPart work? That's a fairly special type, so maybe it is specific to that entity.

[MagneGanz]

Regarding "System Family: Gutter". They export as IfcPipeSegement / IfcFlowSegment Type GUTTER, no matter what I try. Are they hard coded?

However, that's not the real issue here. I am not able to export Type Parameters (IFC 2x3 or IFC4).

FOB_IFC_UserDefinedParameterSets_ARK_NO.txt U_F_BAS_FBU_ARK_XXX.zip

[AngelVelezSosa]

Two issues:

1. The gutter was hardwired, but shouldn't be in Revit 2025. This is an open source update so should be compatible with 2023/2024, which is on our schedule to update.
2. The issue is that you can't currently attach type parameters to instances. Change the "I" to a "T" and it should work. We currently have revamping the UX for parameter mapping on our roadmap. As part of that, we would address the ability to include user-defined type parameters for instance entities (although I doubt the other way around - I don't think it makes sense to try to put an instance parameter on a type entity).