Skip to content
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

Closed
dvrvb opened this issue Nov 8, 2018 · 12 comments
Closed

IFC4Add2TC1 Entity/TypeClasses #68

dvrvb opened this issue Nov 8, 2018 · 12 comments

Comments

@dvrvb
Copy link

dvrvb commented Nov 8, 2018

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

@WawanSolihin
Copy link
Contributor

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.
However for the IfcDistributionElement thing is a little more difficult. In IFC2x3 the instance of those MEP element may be IfcFlowController (for example) and the associated type is more specific like IfcValveType. In cases that the type is not assigned (e.g. IfcExportAs = IfcFlowTerminal), we could create an instance of IfcFlowTerminal without the type. But in IFC4 IfcFlowTerminal has been made deprecated (and will be made abstract in future, while currently is still a valid entity) and the concrete classes are now paired with the type, e.g. IfcValve and IfcValveType. Therefore, especially for MEP objects, it is better and safer to use the typeclass for IfcExportAs, e.g. IfcExportAs=IfcValveType. This will be valid in both IFC2x3 and IFC4.
And because of the valid and yet deprecated status of the sub-entities of IfcDistributionElement. The entity such as IfcFlowTerminal will still be created but not the IfcFlowTerminalType that is now abstract. I will be looking into some improvements in this area.

Regards,
Wawan

@dvrvb
Copy link
Author

dvrvb commented Nov 13, 2018

Hi Wawan,

Any idea what the future 'proxy' will be instead of IfcDistributionElement (for distribution elements)?
Because of your remark, I just now notice the red change text at the buildingSMART site, that indeed it is deprecated for instantiation and will be made abstract.

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'.
Fortunately there is also a lot of forgiveness & translation in the exporter, like it's correctly translating IfcGasTerminal, while it is not even existing in IFC2x3 as EntityClass. Only IfcGasTerminalType exists as TypeClass (with IfcFlowTerminal as EntityClass): these kind of translations of the exporter are in my opinion good and acceptable, and are really contributing in making IFC a bit more easy to apply in practice.
(I only have doubts about the acceptance of IfcFloor and IfcAssembly ... personally I would like to see them removed)

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.
Anyway, now it's clear for me that the supertypes that I mentioned are deprecated for instantiation.

I will retest some last issues with the PredefinedTypes: https://sourceforge.net/p/ifcexporter/discussion/general/thread/b6a9156b/#f126
and then I think the issues for the Entiy/TypeClasses and PredefinedTypes for IFC4RV are solved. At least based on the use of IfcExportAs on Generic Models. There are a few other issues, like the PredefinedTypes in the mapping table that are not working anymore: #25

Regards,
Dirk

WawanSolihin added a commit that referenced this issue Nov 15, 2018
…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
@dvrvb dvrvb mentioned this issue Nov 18, 2018
@dvrvb
Copy link
Author

dvrvb commented Nov 18, 2018

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

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

image

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

Regards,
Dirk

@WawanSolihin
Copy link
Contributor

WawanSolihin commented Nov 18, 2018 via email

@dvrvb
Copy link
Author

dvrvb commented Nov 19, 2018

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.
For a lot of Classes the PredefinedTypes are not anymore exported. So I also went back to the original 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.
I added a simple Solibri ITO to list the PredefinedTypes next to the SOLL-PredefinedType-parameter. To be sure, I verified some of them also with Notepad (but not all of them, so there can/will be also Solibri issues in some cases).

To be sure that it has nothing to do with the Entity-input-values for IFCExportAs, I now also made the TYPE-variant.
Since the previous testmodel already contained 'EntityClass-alike' values, as well as 'Type-alike' values in 2 separated parameters, I now linked the 'Type-alike' values to the IFCExportAs parameter (although this is an Instance Parameter in the Family of the Generic Model, but that doesn't matter for the export-translation).

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,
Dirk

@dvrvb
Copy link
Author

dvrvb commented Dec 5, 2018

At first, I noticed that I made some mistakes in my test model, at least concerning IFC2x3CV2.0

  • typo: the T was missing in RADIAN'T'HEATER (IfcElectricAppliance)
  • PROGRAMMABLE did not exist in IFC2x3 (so it has to be NOTDEFINED) (IfcController)

For IFC2x3CV2.0 the current status seems to be:

remaining issues with PredefinedTypes for:
-IfcWall (all are now NOTDEFINED)
-IfcSlab (only the one without a value for the PredefinedType is now by default translated to FLOOR, instead of NOTDEFINED)
-IfcSpace (both USERDEFINED and NOTDEFINED are missing)
-IfcRoof (USERDEFINED is translated to NOTDEFINED)
-IfcElectricDistributionPoint (all PredefinedTypes are missing)

-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:
-IfcElectricHeater is now translated to IfcBuildingElementProxy
-IfcGasTerminal is now translated to IfcBuildingElementProxy (of course only IfcGasTerminalType is only existing, but also explicitly exported as IfcGasTerminalType, it is translated to IfcBuildingElementProxy)
-IfcProxy is now translated to IfcBuildingElementProxy with PredefinedType USERDEFINED while IfcProxy is only deprecated in IFC4

Issues with IfcStair/IfcRoof(other than USERDEFINED)/IfcRamp as seen in Solibri are only Solibri-related (not a Revit-exporter-issue)

Regards,
Dirk

dvrvb referenced this issue Dec 5, 2018
Exporting LoadBearing property automatically for stuctural beams, columns, braces
@dvrvb
Copy link
Author

dvrvb commented Dec 11, 2018

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
(leaving out possible IFCAdd2 IFCAdd2TC1 related stuff)

PredefinedTypes:

  • IfcSlab (without PredefinedType) is translated to FLOOR: I would expect NOTDEFINED

  • IfcWindow (without PredefinedType) and IfcWindow.NOTDEFINED: now both are translated to the PredefinedType WINDOW instead of NOTDEFINED

  • IfcDoor (without PredefinedType) and IfcDoor.NOTDEFINED: now both are translated to the PredefinedType DOOR instead of NOTDEFINED

  • IfcSurfaceFeature: all are now translated to NOTDEFINED

  • IfcGrid: all are now translated to NOTDEFINED

Classes:

  • IfcProjectionElement/IfcExternalSpatialElement/IfcAnnotation: strictly spoken they should be translated to IfcBuildingElementProxy since they are out of the scope of IFC4RV1.1
    Probably it is safer to leave it this way until IFC4RV1.2 is really published.

IFC2x3CV2.0

PredefinedTypes:

  • IfcSlab (without PredefinedType) is translated to FLOOR: I would expect NOTDEFINED
  • IfcElectricDistributionPoint: the PredefinedTypes are missing

Classes:

  • IfcSpaceHeaterType is translated to IfcElectricHeaterType, while it should be IfcSpaceHeaterType

  • IfcElectricHeaterType/IfcGasTerminalType is translated to IfcBuildingElementProxy

  • IfcProxy is translated to IfcBuildingElementProxy (while IfcProxy exists in IFC2x3) and the PredefinedTypes are missing: but probably it is OK to leave it this way.

Best regards,
Dirk

dvrvb referenced this issue Dec 11, 2018
…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
@WawanSolihin
Copy link
Contributor

Hi Dirk,

A few of them are assigned default predefinedtype according to the current default assignment behavior:

  • IfcSlab with default FLOOR
  • IfcWindow with default WINDOW
  • IfcDoor with default DOOR
    I am hesitating to change it at the moment because this will change the current behavior and those predefinedtypes look valid too.

I wil check the others.

Thanks for the feedback,
Wawan

@dvrvb
Copy link
Author

dvrvb commented Dec 15, 2018

concerning fix c9aca0e

IFC4RV1.1/2
Ultimate fix :-)

Great: I think for IFC4RV the mission is completed!
Whatever RV1.2 will bring us, the input and output of the exporter is now clear, complete and consistent (based on the use of IfcExportAs on Generic Models).

PredefinedTypes:

  • IfcSlab (without PredefinedType) is translated to FLOOR: I would expect NOTDEFINED
    → due to default behavior: FLOOR is OK
  • IfcWindow (without PredefinedType) and IfcWindow.NOTDEFINED: now both are translated to the PredefinedType WINDOW instead of NOTDEFINED
    → due to default behavior: WINDOW is OK
  • IfcDoor (without PredefinedType) and IfcDoor.NOTDEFINED: now both are translated to the PredefinedType DOOR instead of NOTDEFINED
    → due to default behavior: DOOR is OK
  • IfcSurfaceFeature: all are now translated to NOTDEFINED
    → fixed: OK
  • IfcGrid: all are now translated to NOTDEFINED
    → fixed: OK (only BIM Vision has issue in showing these PredefinedTypes)

Classes:

  • IfcProjectionElement/IfcExternalSpatialElement/IfcAnnotation: strictly spoken they should be translated to IfcBuildingElementProxy since they are out of the scope of IFC4RV1.1
    Probably it is safer to leave it this way until IFC4RV1.2 is really published.
    → OK: At the moment the output is rather RV1.1 'plus', and that seems to be OK (in my opinion).

IFC2x3CV2.0
Penultimate fix ?
→ seems only still an issue with IfcElectricHeaterType, probably also IfcGasTerminalType

PredefinedTypes:

  • IfcSlab (without PredefinedType) is translated to FLOOR: I would expect NOTDEFINED
    → due to default behavior: FLOOR is OK
  • IfcElectricDistributionPoint: the PredefinedTypes are missing
    → fixed: OK (actually it was not a PredefinedType, but the DistributionPointFunction)

Classes:

  • IfcSpaceHeaterType is translated to IfcElectricHeaterType, while it should be IfcSpaceHeaterType
    → fixed: OK

  • IfcElectricHeaterType/IfcGasTerminalType is translated to IfcBuildingElementProxy
    → issue: IfcElectricHeaterType is still translated to IfcBuildingElementProxy
    → ? IfcGasTerminalType is indeed present in the IFC-model, but none of the viewers (FZK Viewer/BIM Vision/Solibri/XBim Xplorer) seems to recognize it as GasTerminal. They all are showing it as BuildingElementProxy.

  • IfcProxy is translated to IfcBuildingElementProxy (while IfcProxy exists in IFC2x3) and the PredefinedTypes are missing: but probably it is OK to leave it this way.
    → OK: now translated to IfcProxy (without PredefinedTypes)

Best regards,
Dirk

@dvrvb
Copy link
Author

dvrvb commented Dec 16, 2018

IFC-sample with the result in IFC2x3CV2.0 for the 2 TypeClasses IfcElectricHeaterType and IfcGasTerminalType, which are now IfcBuildingElementProxy.
IFC2x3_GasTerminal_ElectricHeater_TypeClass.zip

Best regards,
Dirk

@dvrvb
Copy link
Author

dvrvb commented Jan 7, 2019

Thx Wawan!
Mission completed!
With 8187887 this issue is finally finding closure :-)
… and it exposed (again) a flaw in my testfile … due to a typo on the buildingSMART website ...
image

@dvrvb dvrvb closed this as completed Jan 7, 2019
@WawanSolihin
Copy link
Contributor

Phew, finally.
Thanks Dirk for your support too.
I noticed the issue of that GASTERMINAL, but I forgot to tell you. Sorry about that.

Best regards,
Wawan

WawanSolihin added a commit that referenced this issue Sep 4, 2021
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants