I am Bim Engineer. I am assigning the ifc parameters since one year . I have searched Google fully to know , why we need ifc parameter?
I know we need ifc for open Bim means so that it can be used in other softwares . But why we need ifcexportas , ifcexporttype and ifcname these parameters. Please help me in this . I need clear picture .
Please keep discussions here in the forum rather than sending SMS. I’m here because I want to read the discussions.
Ok,Sir. Sorry , will keep discussion here only.
This question should be oriented towards the team that develops the Revit IFC Add-in. They chose to use custom Revit parameters (IfcExportAs…) to give the user the ability control over the way a Revit Element can be translated into a chosen IFC class (overriding the general Revit Category - IFC Class mapping that you can control in the Ifc Options dialog).
Hi Gurdev_Singh!
check IFC-Manual-2018-ENU.PDF on the autodesk website. explains how to manage the ifc parameters and class mapping exporting and importing.
cheers!!
Sir, I tried that also I need proper reason why we need all these ifc parameters. I know why we need all cobie parameter i.e. CAFM CMMS and energy realted paramter please help me out with ifc parameters. Any video or anything . I am searching since days.
I don’t quite understand the question, but here’s my attempt at an answer. Apologies if I have misunderstood.
In short, if you do not provide any IFC parameters, then your IFC objects do not have any data. If your IFC objects don’t have any data, then your BIM model cannot be used for intelligent analysis (such as energy analysis, as per your example) in other BIM programs. This means that your model is useless outside the software that you initially created it. In addition, when your software inevitably becomes obsolete, or even moves to the next version, your BIM model is also at risk of being obsolete.
Revit does not classify BIM objects the same way as the IFC standard does. For instance, underslab insulation in Revit is often modelled as a floor, or a ceiling. In IFC, it should be modelled as an IfcCovering (please correct me if I am wrong). Therefore, Revit needs a way for you to map your Revit BIM objects to IFC BIM objects. Revit provides an IFC Options dialog in its menu, but it is not a very granular way to map objects. Therefore, Revit also provides the IfcExportAs, etc parameters for custom, granular mapping.
Hope that made sense.
Dear Moult , Thanks i got it very clear. So there are maily two ways for mapping . One is by using the IAI file(Just an example) that we select in option button and second way is by providing values to IFCExportAs and IFCExportType. Am i right ? So is there any use of IFCName parameter? And for mapping manually do we need only two parameters i.e. IFCExportAs , IFCExportType ? Please correct me if i am wrong ?
You are correct. I highly recommend you read the IFC-Manual-2018-ENU.PDF recommended by @dca. As it explains, the IfcExportAs is an arbitrarily established convention to override a Revit object’s IFC class and IFC type. If you wanted your fancy generic model to be some form of undefined vertical separator instead, you can put IfcSlab as the value of your IfcExportAs field. If you were a bit more specific, you can put IfcSlab.ROOF as a value to define the class and type.
Revit, for whatever reason, has additionally created an IfcExportType field. This is a superfluous field as the IfcExportAs field can serve the same function. For instance, IfcExportAs=IfcSlab && IfcExportType=ROOF is the same as IfcExportAs=IfcSlab.ROOF.
In addition, Revit also supports 4 more fields to override: IfcName, IfcDescription, IfcObjectType, IfcLongName (if you want, Revit is a bit inconsistent and allows you to also call these NameOverride, DescriptionOverride, ObjectTypeOverride, and LongNameOverride).
IfcName overrides the name parameter of the Ifc element. Every single Ifc element (i.e. all that extend IfcRoot) has an optional human readable name. Same with description.
For IfcObjectType, this allows you to specify an arbitrary type of your choice for any IfcObject, as long as you say that the Ifc type is USERDEFINED. For instance, IfcExportAs=IfcSlab.USERDEFINED && IfcObjectType=Foobar.
For IfcLongName, this overrides the LongName attribute for all IfcSpatialElement. For instance, an IfcBuilding. Personally, I don’t see the point of a LongName and it sounds like it is a double up of Description. Hopefully somebody else on this forum can advise.
Thats a very nice explanation. I got all clear. The more parameters we fill the more is the information we are providing ( building smart provided parameters). Am I correct ? I am still studying the manual .
Yes. People usually fill them out to fit the purpose of the MVDs they are seeking to deliver, not for the sake of filling out information.