Door Operation should also work as an Instance parameter in Revit

[Teun1]

We would love to have the IFC override parameter "Operation" for the Doors Category to also work as an Instance parameter. At the moment it doesn't. The IFC operation type in the IFC file is based on both, this Type Operation parameter in Revit (if it is there), and the Instance placement of the Door (Flipped / Mirror) in Revit. I am happy that the exporter already translates the Instance placement to an IFC Type value. But it will be more consistent if it also works with an Instance "Operation" parameter.

• just a thought- Revit and IFC do not have parrallel structures if you think about Type or Instance. And that is ok. Revit is a modelling program. So it should be flexible. And IFC is an exchange format. So it should be basically rigid. The IFC exporter can and should be a way to bridge these differences without troubling Revit or IFC.

[WillemdBr]

@AngelVelezSosa Any update? We've tested some things with a parameter mapping table in Revit 2019 and 2020 (IfcDoorPanelProperties IfcDoorStyle BAM_C_draairichting) but this doesn't work. Only possibility is to use the Type Operation parameter, which is not preferred.

Another posibility is to draw 3D swing lines in a door family, but this only works in Revit 2018, in later versions the door must be wall based and can't be a Shared family for this to work. Did something break in the Revit IFC exporter in 2019 and 2020?

Should we start a new topic with the example files, or are you aware of this issue?

[AngelVelezSosa]

The reason that it is a type parameter is that an instance can be flipped. As such, if you have a single swing left door type, and you flip the instance, it should export as single swing right. What is the use case for a per-instance parameter? Wouldn't you worry about it being wrong?

@willemdebruijn : that sounds like a separate issue? A new topic would be good for that.

[WillemdBr]

Hi @AngelVelezSosa ,

An example is a shared door family (a door panel) that's been hosted in a doorframe family where the instance parameter 'Operation' is linked so it can be controlled with the host frame family. Because a door panel, is just a door panel and the frame defines wether its a right or left swing.

We can check a mirrored door through an API if we want. Because Revit knows when something is Mirrored. But even with a Type parameter a user can flip a door when the Type parameter is filled with (for example) SINGLE_SWING_RIGHT. When flipped, the Type parameter (as well as an instance parameter) will still show SINGLE_SWING_RIGHT instead of SINGLE_SWING_LEFT.

I won't start a new issues because our request is the same as @Teun1 because we prefer a parameter mapping solution instead of a automatic recognition with the 3D swing lines

[AngelVelezSosa]

OK, I think the real request here is really that Revit deal with this better, not anything to do with IFC really. This request is in the system, but I will bring it up again.

[tsolsen]

Following @willemdebruijn 's comments - we don't really have the opportunity to communicate anything towards the door and window panel properties.

There is one PanelWidth parameter in IFC, and that should point to the individual panel. But when setting it up in RVT, we can't convey this info, as we can't reference sub-elements. So we end up with parameters such as PanelWidth1, PanelWidth2 in the export.

Using shared families, is not an option at all for us, as they are exported individually, and loose their export to the door-host. Quite a hassle to load the same panel into all families.. I'm guessing these things end up being related, if Door and WindorPanelProperties are better supported in the future.

What are the schema rules? It looks like the needed individuallity, is supported.

The IfcDoorType can define doors consisting of more then one panel. In this case, one instance of IfcDoorPanelProperties has to be included for each door panel.

ref: https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/schema/ifcarchitecturedomain/lexical/ifcdoorpanelproperties.htm

[WillemdBr]

Hi @tsolsen Thanks for your insight. I guess we differ with using the door panels as Shared Families, because this is exacly what we want, to give te door panel its own properties (such as PanelOperation). That's why we have shared families for doors, glass, panels, etc. which we use in the main frame family.

But you ar right that the relation from door-host is lost, maybe use a custom parameter to get this relation? Our standard method is giving each door or window an unique ID, wich we can use to identify the door-host relation when needed.

[tsolsen]

When we started digging deep into IFC, around 8 years ago, our setup was actually everything shared - Panels, Linings, Hardware. But seeing what that method, it did to our deliverables, having no kind of relations, we chose to un-share everything. In any case, we have to choose one or the other. Neither is satisfying.

I have the same kind of problem, with hardware relating to a sink (SanitaryType, ValveType and WasteTerminalType). Logically I think I should collect that in a IfcElementAssembly, but can't control the relations.

[Teun1]

@AngelVelezSosa First of all this is just a user request. But sometimes an explanation helps.

Using a Familytype Parameter in a project or library can be very efficient and logical. Especially in a design phase. We use it e.g. for Doors - just like @willemdebruijn. It is not possible to link Type Parameters of a Shared Family to its host. In this case the frame. You can only link Instance Parameters. There is nothing wrong with this Revit behaviour. And it does even make a lot of sense. Because this Instance Door Parameter is defined by its host it's save enough. We even link more information from the frame to the Door, so why not the Operation.

IFC has roughly at least 7 different kinds of Door Operation types. But because the IFC exporter is fixed on the Type parameter in Revit. We need to build and maintain Door types for every Door Operation type. Although this does match a real live situation, it does not match a normal LOD goal for a digital project. If we know the dimensions of a Door, the type of glazing and the Operation(text) this is normally enough.

Hopefully this helps to understand this question a little bit better.

Furthermore I agree with @tsolsen that it would be wonderfull to establish and control the relation of Revit elements in IFC better. If a Revit element is nested the IFC exporter should also make a relation of any kind between these objects in IFC. But perhaps this is a different Topic.