IFC4Add2TC1 Entity/TypeClasses

dvrvb commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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: https://github.com/Autodesk/revit-ifc/issues/25

Regards, Dirk

dvrvb commented 5 years ago

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
IfcAnnotation (now still exports as IfcAnnotation): http://www.buildingsmart-tech.org/mvd/IFC4Add2TC1/RV/1.1/html/link/ifcproduct.htm
IfcExternalSpatialElement (now still exports as IfcExternalSpatialElement): http://www.buildingsmart-tech.org/mvd/IFC4Add2TC1/RV/1.1/html/link/ifcspatialelement.htm

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

WawanSolihin commented 5 years ago

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

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.ziphttps://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 GitHubhttps://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 threadhttps://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.

dvrvb commented 5 years ago

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:

IFC IfcClass_PredefinedType_ENTITY_R2019.rvt IFC IfcClass_PredefinedType ENTITY.zip
IFC IfcClass_PredefinedType_TYPE_R2019.rvt IFC IfcClass_PredefinedType TYPE.zip

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 commented 5 years ago

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 commented 5 years ago

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

WawanSolihin commented 5 years ago

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 commented 5 years ago

concerning fix https://github.com/Autodesk/revit-ifc/commit/c9aca0e01e39ddd25cb1ef8a75c91db05016f316

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 commented 5 years ago

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 commented 5 years ago

Thx Wawan! Mission completed! With https://github.com/Autodesk/revit-ifc/commit/8187887fb0f18ff2f3fde9ed3a3c3ac864684208 this issue is finally finding closure :-) … and it exposed (again) a flaw in my testfile … due to a typo on the buildingSMART website ...

WawanSolihin commented 5 years ago

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

Autodesk / revit-ifc

IFC4Add2TC1 Entity/TypeClasses #68