New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IFC4Add2TC1 Entity/TypeClasses #68
Comments
Thanks Dirk, There are places in the codes that do "special" export, such as Footing, Pile. These are the ones that mostly explain the issues you highlighted above. I will be fixing those. Regards, |
Hi Wawan, Any idea what the future 'proxy' will be instead of IfcDistributionElement (for distribution elements)? Your remark about the TypeClass being more specific than the EntityClass in IFC2x3, is indeed one of the nice improvements of IFC4 where those are 'levelled'. IFC4Add2TC1: So, while IfcDistributionElement and IfcDistributionElementType are deprecated for instantiation and will be made abstract, and as you mentioned, this is also valid for the EntityClass IfcFlowTerminal, but I'm now wondering why then IfcFlowTerminalType isn't deprecated as well ... but that's probably a question for buildingSMART. I will retest some last issues with the PredefinedTypes: https://sourceforge.net/p/ifcexporter/discussion/general/thread/b6a9156b/#f126 Regards, |
…cts related to it (Github issue #68) . (Note: that this changes may introduce some regression and in a IfcRamp export case may see a change in outcome) Work for RV1.2 for structural members (column, beam, member) to remove IfcMaterialProfile related export
R2019 At first some explanation about what and how I tested concerning the export of Entity/TypeClasses and their PredefinedTypes within the scope of IFC4RV1.1 Although a complete test should cover the use of the export-parameters as Instance Parameter as well as Type Parameter, as well as a combination of IfcExportAs and IfcExportType, or with the use of IfcExportAs and the punctuation notation (IfcClass.PredefinedType), I only did a partial test: the test covers only the use of one generic model, with the use of the combination of IfcExportAs and IfcExportType as Instance Parameters. Since the IFC-exporter is evaluating the input value with or without the suffix "Type", regardless if it really exists in IFC, I also made use of this kind of 'translation' to make a list of 'Typeless' EntityClasses.
In the model I added parameters with "SOLL"-values for the EntityClass, the TypeClass, and the PredefinedTypes: these are the values that I would expect after the IFC-export.
I used BIM Vision / FZK Viewer / NotePad to evaluate the results: So, the results:
Since in the exporter (with this commit) there is now a clear distinction between "IFC4 general" and "IFC4RV", there are few more classes that should be excluded for export in IFC4RV (because they are not in the scope of IFC4RV1.1): they should be exported as IfcBuildingElementProxy | IfcBuildingElementProxyType | NOTDEFINED
The table on http://www.buildingsmart-tech.org/specifications/ifc-view-definition/ifc4-reference-view/comparison-rv-dtv is clearly not accurate anymore! Attached: RVT model, IFC4RV export, BIMVision comparison report XLS 20181118_IFC_IfcClass_PredefinedType.zip Minor detail: is it possible to get the space away between IFC & 4 in the option list in the exporter? (and adding a space between IFC & 2x3 COBie...): then the list is a bit more consistent (and also more looking nice; sorry for being such a nitpicker) … or to choose all with a space, or all without a space ... Regards, |
Thank you Dirk for the comprehensive test cases. It is certainly very useful to ensure the export is consistent and complete. Generally the type and predefinedtype should be correct as they are checked against the schema. However, the schema version used is IFC4Add2, not the TC1 yet. I do not have the TC1 version yet. I will ask the buildingSMART guys to make it available. Also there are some codes written specifically for some types of object that may not use the same path as the others.
I will take a look at the report and use the test case to verify any fix.
Thanks,
Wawan
From: Dirk Van Rillaer <notifications@github.com>
Sent: Monday, November 19, 2018 12:25 AM
To: Autodesk/revit-ifc <revit-ifc@noreply.github.com>
Cc: WawanSolihin <wsolihin@outlook.com>; Comment <comment@noreply.github.com>
Subject: Re: [Autodesk/revit-ifc] IFC4Add2TC1 Entity/TypeClasses (#68)
R2019
IFC4RV1.1/1.2(?)
At first some explanation about what and how I tested concerning the export of Entity/TypeClasses and their PredefinedTypes within the scope of IFC4RV1.1
Although a complete test should cover the use of the export-parameters as Instance Parameter as well as Type Parameter, as well as a combination of IfcExportAs and IfcExportType, or with the use of IfcExportAs and the punctuation notation (IfcClass.PredefinedType), I only did a partial test: the test covers only the use of one generic model, with the use of the combination of IfcExportAs and IfcExportType as Instance Parameters.
Since the IFC-exporter is evaluating the input value with or without the suffix "Type", regardless if it really exists in IFC, I also made use of this kind of 'translation' to make a list of 'Typeless' EntityClasses.
* for IFCExportAs: I used as inputvalue a IFC-generic name: for instance IfcGasTerminal, knowing that even in IFC2x3 it doesn't exist, since it should be the Type IfcGasTerminalType, and also knowing that IfcGasTerminalType is deleted in IFC4.
* for IFCExportType: I used all the PredefinedTypes of IFC2x3 and IFC4, regardless if they are deprecated or deleted.
In the model I added parameters with "SOLL"-values for the EntityClass, the TypeClass, and the PredefinedTypes: these are the values that I would expect after the IFC-export.
Some of the basic/general assumptions (for the SOLL-values):
* if IFCExportType is left empty, it should be exported as PredefinedType=NOTDEFINED
* if the Class is deleted or deprecated, it should be exported as IfcBuildingElementProxy | IfcBuildingElementProxyType | NOTDEFINED, unless there is valid translation possible.
* if the Class is abstract (not valid for instantiation), it should be exported as IfcBuildingElementProxy | IfcBuildingElementProxyType | NOTDEFINED
I used BIM Vision / FZK Viewer / NotePad to evaluate the results:
Notice: in BIMVision IfcOpeningElement and IfcVoidingFeature are hidden, so you can not list them somewhere.
IfcDistributionPoint is not yet recognized, and there are also 2 PredefinedTypes that are not recognized: it is IfcReinforcingBar.ANCHORING and IfcTank.BREAKPRESSURE: that's a BIMVision issue, because the Revit-IFC-export is OK.
So, the results:
* IfcBuildingElementProxy is missing its PredefinedTypes
* IfcGrid is missing its PredefinedTypes
* IfcSurfaceFeature is missing its PredefinedTypes
* IfcOpeningElement and IfcVoidingFeature is missing its PredefinedTypes
* IfcDoor and IfcWindow are still missing their matching PredefinedTypes: they are all translated to DOOR or WINDOW
Notice: IfcDoorStandardCase/IfcWindowStandardCase are correctly translated to IfcDoor/IfcWindow, but the PredefinedType is DOOR/WINDOW, and I think it should better be NOTDEFINED (to be consistent with other translations)
* with IFC4Add2TC1 not only the 'ElementedCase' and the 'StandardCase' are deprecated, but especially for Walls some of the PredefinedTypes that were deprecated or now again valid: STANDARD and ELEMENTEDWALL;
therefore
IfcWallElementedCase should in the translation have the PredefinedType ELEMENTEDWALL (instead of NOTDEFINED)
IfcWallStandardCase -> should be translated to the PredefinedType STANDARD (instead of NOTDEFINED)
* on the other hand, IfcSlabElementedCase and IfcSlabStandardCase are translated to IfcSlab | IfcSlabType | FLOOR : I think the PredefinedType should be NOTDEFINED
* IfcSlab with PredefinedType NOTDEFINED, is translated to FLOOR, and should be NOTDEFINED
* there are some Classes (mainly abstract) that are correctly translated to IfcBuildingElementProxy | IfcBuildingElementProxyType, but where the PredefinedType "NOTDEFINED" is missing:
IfcBuildingElement
IfcElectricalElement
IfcElement
IfcElementComponent
IfcEquipmentElement
IfcExternalSpatialStructureElement
IfcFeatureElement
IfcFeatureElementAddition
IfcFeatureElementSubstraction
IfcPort
IfcReinforcingElement
IfcSpatialElement
IfcSpatialStructureElement
and
IfcProxy
* I do see that there is something changed with the Ramps: I have to take a closer look for understanding what is now happening, but at least the PredefinedTypes are fine.
* on the other hand: IfcStair: all the PredefinedTypes are incorrectly translated to NOTDEFINED
* IfcSanitaryTerminal with PredefinedType WCSEAT -> WCSEAT is deprecated -> should be NOTDEFINED
Since in the exporter (with this commit) there is now a clear distinction between "IFC4 general" and "IFC4RV", there are few more classes that should be excluded for export in IFC4RV (because they are not in the scope of IFC4RV1.1): they should be exported as IfcBuildingElementProxy | IfcBuildingElementProxyType | NOTDEFINED
* IfcProjectionElement (now still exports as IfcProjectionElement): http://www.buildingsmart-tech.org/mvd/IFC4Add2TC1/RV/1.1/html/link/ifcfeatureelement.htm<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.buildingsmart-tech.org%2Fmvd%2FIFC4Add2TC1%2FRV%2F1.1%2Fhtml%2Flink%2Fifcfeatureelement.htm&data=02%7C01%7C%7C561aa5b95a9c4bb9ddd608d64d7261dd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636781550988587248&sdata=ttYlJoNMaGKj1o9E1lgZz4OdUqMnnfMi32aR%2BUK0yOY%3D&reserved=0>
* IfcAnnotation (now still exports as IfcAnnotation): http://www.buildingsmart-tech.org/mvd/IFC4Add2TC1/RV/1.1/html/link/ifcproduct.htm<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.buildingsmart-tech.org%2Fmvd%2FIFC4Add2TC1%2FRV%2F1.1%2Fhtml%2Flink%2Fifcproduct.htm&data=02%7C01%7C%7C561aa5b95a9c4bb9ddd608d64d7261dd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636781550988587248&sdata=hAHMarrIXj2qBibDmRumRiTXYo9ATDmXToBCvUH1%2Bns%3D&reserved=0>
* IfcExternalSpatialElement (now still exports as IfcExternalSpatialElement): http://www.buildingsmart-tech.org/mvd/IFC4Add2TC1/RV/1.1/html/link/ifcspatialelement.htm<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.buildingsmart-tech.org%2Fmvd%2FIFC4Add2TC1%2FRV%2F1.1%2Fhtml%2Flink%2Fifcspatialelement.htm&data=02%7C01%7C%7C561aa5b95a9c4bb9ddd608d64d7261dd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636781550988587248&sdata=klIq0emjsY0YeiiIBfz4TYKviaJQ2aoNSrBhW0%2B%2FJRM%3D&reserved=0>
The table on http://www.buildingsmart-tech.org/specifications/ifc-view-definition/ifc4-reference-view/comparison-rv-dtv<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.buildingsmart-tech.org%2Fspecifications%2Fifc-view-definition%2Fifc4-reference-view%2Fcomparison-rv-dtv&data=02%7C01%7C%7C561aa5b95a9c4bb9ddd608d64d7261dd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636781550988743499&sdata=Oul38qJznDR8VEDYI%2FsYfvUuFfPMabfy5RTdAgohPuI%3D&reserved=0> is clearly not accurate anymore!
Attached: RVT model, IFC4RV export, BIMVision comparison report XLS
20181118_IFC_IfcClass_PredefinedType.zip<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAutodesk%2Frevit-ifc%2Ffiles%2F2592960%2F20181118_IFC_IfcClass_PredefinedType.zip&data=02%7C01%7C%7C561aa5b95a9c4bb9ddd608d64d7261dd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636781550988743499&sdata=120QmN9tq6x0Ug4oZlLNFVLka%2BgiuViQ%2BUOzvuUMdWk%3D&reserved=0>
[image]<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuser-images.githubusercontent.com%2F41319048%2F48675188-4c9ef200-eb56-11e8-99d7-2687ccdd5b78.png&data=02%7C01%7C%7C561aa5b95a9c4bb9ddd608d64d7261dd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636781550988743499&sdata=sPrULA4q1EZNk2GiOJrqW0W%2BkSgMpOoCYAAf%2FSrK5eo%3D&reserved=0>
Minor detail: is it possible to get the space away between IFC & 4 in the option list in the exporter? (and adding a space between IFC & 2x3 COBie...): then the list is a bit more consistent (and also more looking nice; sorry for being such a nitpicker) … or to choose all with a space, or all without a space ...
[image]<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuser-images.githubusercontent.com%2F41319048%2F48675179-26795200-eb56-11e8-8c87-61ad6cecb4bb.png&data=02%7C01%7C%7C561aa5b95a9c4bb9ddd608d64d7261dd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636781550988743499&sdata=bt7ZDC3sXAZydlogPE%2Fk2brDWYjRDHmgQ%2BlpuCAs0Dw%3D&reserved=0>
Regards,
Dirk
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAutodesk%2Frevit-ifc%2Fissues%2F68%23issuecomment-439705247&data=02%7C01%7C%7C561aa5b95a9c4bb9ddd608d64d7261dd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636781550988743499&sdata=FscnxDJir5jwWjAxvBOvQU9bzSUjvTX8jSpLJ9z6Q6o%3D&reserved=0>, or mute the thread<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAeYP9rEvcOjfsPCypcc3A9nQLws2abPkks5uwYnZgaJpZM4YUrs-&data=02%7C01%7C%7C561aa5b95a9c4bb9ddd608d64d7261dd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636781550988743499&sdata=aXIJONLmvvOOUGaeEksvaQPKkIOccG5FM9kTOHxMEQA%3D&reserved=0>.
|
There seems to be an issue with the IFC2x3CV2.0 export of the PredefinedTypes, and something got broken during the process since version 19.1. The attached zips are containing the IFC-export with version 19.1 as well as with the current GitHub version of the IFC4RV-cert branch. To be sure that it has nothing to do with the Entity-input-values for IFCExportAs, I now also made the TYPE-variant. The 2 variants of the testmodel are:
In comparison with the previous testmodel, I only corrected 1 value: there was a "0" as value for the IFC2x3 SOLL PredefinedType of an IfcDistributionElement(Type), which I removed. I did not completely verified my own "SOLL-values" since I was planning to do so in comparison with the outcome of the export. Best regards, |
At first, I noticed that I made some mistakes in my test model, at least concerning IFC2x3CV2.0
For IFC2x3CV2.0 the current status seems to be: remaining issues with PredefinedTypes for: -IfcReinforcingBar (the TypeEnum in IFC2x3 was IfcReinforcingBarRoleEnum for the attribute ReinforcementRole of IfcSectionReinformcementProperties, and changed in IFC4 to IfcReinforcingBarEnum as TypeEnum for the PredefinedType of IfcReinforcingBar: so formally it didn't exist in IFC2x3: so it is OK that they all are translated to nothing. IfcClass issues: Issues with IfcStair/IfcRoof(other than USERDEFINED)/IfcRamp as seen in Solibri are only Solibri-related (not a Revit-exporter-issue) Regards, |
Exporting LoadBearing property automatically for stuctural beams, columns, braces
Hi Wawan, Taking into account Solibri/BIMVision issues, but also other mistakes in my testfile, I think I can pinpoint the issues to just only a few minor cases. Perfection is close, very very close :-) IFC4RV1.1/2 PredefinedTypes:
Classes:
IFC2x3CV2.0 PredefinedTypes:
Classes:
Best regards, |
…d IFC2x3 - Code cleanup: removing "Ifc..." for the propertyname in the property calculator. Property set, the Revit parameter name must be the same as the Ifc property name (unless it is mapped using export parameter mapping table) - Adding more support for Material from Parameters
Hi Dirk, A few of them are assigned default predefinedtype according to the current default assignment behavior:
I wil check the others. Thanks for the feedback, |
concerning fix c9aca0e IFC4RV1.1/2 Great: I think for IFC4RV the mission is completed! PredefinedTypes:
Classes:
IFC2x3CV2.0 PredefinedTypes:
Classes:
Best regards, |
IFC-sample with the result in IFC2x3CV2.0 for the 2 TypeClasses IfcElectricHeaterType and IfcGasTerminalType, which are now IfcBuildingElementProxy. Best regards, |
Thx Wawan! |
Phew, finally. Best regards, |
…cts related to it (Github issue #68) . (Note: that this changes may introduce some regression and in a IfcRamp export case may see a change in outcome) Work for RV1.2 for structural members (column, beam, member) to remove IfcMaterialProfile related export
IFC4Add2TC1 Entity/TypeClasses
Since a few newly added classes in IFC4 are already deprecated in IFC4Add2TC1,
there are now a few export translations that are not yet consistent in my opinion.
R2019
Using IFCExportAs
While for instance IFCExportAs = IfcMemberStandardCase is nicely translated in the IFC-export to IfcMember and its IfcMemberType,
there is some inconsistency with:
IFCExportAs = IfcPlateStandardCase (which is deprecated in IFC4Add2TC1) > is now only translated to IfcPlate: IfcPlateType is missing
IFCExportAs = IfcSlabeElementedCase (which is deprecated in IFC4Add2TC1) > still translated to IfcSlabElementedCase: should be IfcSlab + IfcSlabType
IFCExportAs = IfcWallElementedCase (which is deprecated in IFC4Add2TC1) > still translated to IfcWallElementedCase: should be IfcWall with PredefinedType ELEMENTEDWALL + IfcWallType
IFCExportAs = IfcOpeningStandardCase (which is deprecated in IFC4Add2TC1) > still translated to IfcOpeningStandardCase: should be IfcOpeningElement
There is also an issue with:
IFCExportAs = IfcFooting > now only exporting as IfcFooting: the IfcFootingType is missing
IFCExportAs = IfcPile > now only IfcPile: IfcPileType is missing
IFCExportAs = IfcProxy (which is deprecated in IFC4Add2TC1) > still translated to IfcProxy: should be IfcBuildingElementProxy (Why did they deprecate IfcProxy? Retorical question)
I'm also wondering why the following exportable classes are missing their TypeClass in the IFC-export:
IfcDistributionControlElement is missing its IfcDistributionControlElementType
Also an issue for:
IfcDistributionFlowElement
IfcEnergyConversionDevice
IfcFlowController
IfcFlowFitting
IfcFlowMovingDevice
IfcFlowSegment
IfcFlowStorageDevice
IfcFlowTerminal
IfcFlowTreatmentDevice
Note: with missing TypeClass, I don't mean the use of the TypeClass as value for IFCExportAs, I really mean how it is written in the IFC-file, where the EntityClass for the occurence is related to its TypeClass, and that TypeClass is sometimes missing.
Regards,
Dirk
The text was updated successfully, but these errors were encountered: