autodesk/revit-ifc

IFC for Revit and Navisworks (2019+)

revit-ifc's Issues

Rebar exports with wrong height

Hi, first github issue! :)

We have been continiously exporting a rebar model to IFC over some time and suddenly the rebars gets exported with some strange heights. This has apparantly occurred without doing anything in the Revit model. We are completely lost as to what the error can be, any clues?

Export Rebars - Rounded values missing

Hi

When Reinforcement Rounding is turned on in Revit, the rounded values is not reflected in the IFC-export.
In this example I expect A=3420 mm also in the IFC (not 3422 mm).
This makes it difficult for us to use IFC in construction documentation.

Wish: Export calculated and combined schedule fields to properties

Schedules with calculated or/and combined fields:

Wish that it can look like this in Solibri:

Use cases:

• Almost all kinds of classification codes are combined of several parameters.
• We usually want to add a prefix to Rebar Numbers to make a unique position number.
• Calculated weights of elements (lifting/transport) as properties. (Revit usually have Volume and Unit Weight as available fields)

IFC4RV branch: commit question

The last commit 8ffa80c
generates the error: CS0103 The name 'certifiedPsetList' does not exist in the current context

Project: Revit.IFC.Export
File: ExporterInitializer_PsetDef.cs

large revit project export IFC error with "There has been an unrecoverable error during export. Export will now be aborted" in Revit 2017 with version 19.1.0.0 export code in Revit2017 Branch.

How to export large revit project?

IFC4RV: MEP export time & runaway pipefitting isolation

R2019
exporter: R19.1 & R19-current-DEV-branch-version

issues:

1. IFC4RV export is 10 times slower than IFC2x3CV2.0 export
2. IFC2x3CV2.0 & IFC4RV: there are some 'runaway' pipefitting isolation objects

Since the model and exports are too big for uploading at GitHub:
Sample model is downloadable at German Revit User Group https://www.rug-dach.de/download/demodatensaetze.html
Direct link: https://www.rug-dach.de/phocadownload/2018_final/Samples.zip

Within the Samples.zip, it is the model: BIM Projekt Golden Nugget - Gebaeudetechnik (1).rvt
Todo:

• upgrade to R2019
• ignore the missing linked model
• create 3D view
• export to (standard setup options)
  IFC 2x3 Coordination View 2.0
  IFC 4 Reference View

1. export time

R19.1 & R19-current-DEV-branch-version
IFC2x3CV2.0: exported in less than 1,5 minute
IFC4RV: 11 minutes

2. runaway pipefitting isolation issue

R19.1
IFC2x3CV2.0: a part of the isolation of a pipefitting is not correctly positioned (is rotated)
IFC4RV: same part is now running more away

R19-current-DEV-branch-version
IFC2x3CV2.0: a part of the isolation of a pipefitting is not correctly positioned (is rotated)
IFC4RV: same as IFC2x3: a part of the isolation of a pipefitting is not correctly positioned (is rotated)

Just one pipefitting isolation is marked on the screenshot, but there are several in the model with the same issue.
(In R2018 with exporter 18.4 there are even 10 pipefittings that are not exported at all, and are missing in the export)

Regards,
Dirk

Note: in another MEP model I was not able to export the mechanical system in IFC4RV.
I don't know if this is a related issue with the export time.
Although with IFC2x3 it only took 9 minutes to generate the IFC-model, with IFC4RV there was overnight still no result (something exponential going on?)
The electrical and the plumbing part was not causing any problem.

Center line for ducts and pipes

We need center line for ducts and pipes to be included in the IFC export. Eg. to be able to measure length between center lines to axix, walls etc.

Missing geometry

1 and the same family with different values for IfcExportAs.
R2019, current-Github-exporter-version:

For IFC2x3CV2 & IFC4RV1: IfcExportAs=IfcBuildingElementProxy(Type): cubes and geometry of modeltext are exported: OK! [correction: not IfcBuildingElement, but IfcBuildingElementProxy)

For IFC2x3CV2 & IFC4RV1: IfcExportAs=IfcChimney(Type)/IfcShadingDevice(Type)/IfcRampFlight(Type)/IfcStairFlight(Type): cubes are not exported.
For IFC4RV1: IfcExportAs=IfcCovering(Type)/IfcFooting(Type)/IfcPile(Type)/IfcRamp(Type)/IfcRoof(Type)/IfcSlab(Type)/IfcStair(Type)/IfcWall(Type): geometry of modeltext is not exported.

Sample file is attached.

2018-08-13 RVT IFC.zip

Appending "(Type)" in Pset

Feature from previous versions:
Append "(Type)" to all internal Revit type property sets, to avoid having multiple property sets with the same name assigned to the same IFC entity.
is not available in current.
Best would be having an opportunity to merge Type and Instance parameters into one Property Set.

Character encoding issues with import class mappings in German locale

These are actually several interconnected issues occurring when using the UI for the import class mappings (Open > IFC Options) in the German Revit UI.

1. German Umlaute are not displayed correctly when using a UTF8-encoded import class mapping file.
   
   (Should say "Luftdurchlässe"...)

2. When editing the import class mappings in the UI and subsequently saving them, the file is ANSI-encoded.
   Previous state:
   
   After saving:
   

3. Using an ANSI-encoded import class mapping file with "corrected" Umlaute will result in import errors for the affected categories when linking / importing an IFC file.
   

Tested in 18.4

Workaround:

• Do not use the UI.
• Keep the import class mapping file UTF8-encoded.
• Maintain/edit the file outside of Revit.

Expected behaviour:

• UI should display Umlaute correctly
• Encoding used when saving from UI should not produce the abovementioned errors when linking/opening IFC files.

StairRiserTreadsCalculator

Is the StairRiserThreadsCalculator.cs missing in Exporter\PropertySet\Calculators,
or can the line 131 <Compile Include="Exporter\PropertySet\Calculators\StairRiserTreadsCalculator.cs" /> `be eliminated in
revit-ifc-IFC4RV-Certification\Source\Revit.IFC.Export\Revit.IFC.Export.csproj ?

IfcSpatialElement

2018-08-27 IfcSpatialElement.zip
R2019.1 / regular 19.1 exporter version vs. current-Github-master-version

Compared to the "regular" 19.1 exporter version, there seems to be an issue with the export of the entities of the class IfcSpatialElement in the current-Github-master-version.

Situation:
Model In-Place cubes (no modeltext this time, just cubes) with IfcExportAs =

• IfcExternalSpatialElement
• IfcSite
• IfcBuilding
• IfcBuildingStorey
• IfcSpace / IfcSpaceType
• IfcSpatialZone / IfcSpatialZoneType

IFC4RV export:

• with the regular 19.1 exporter version: these entities are exporting OK.
• with the current-Github-version: these entities are exporting, but are not visible anymore in the FZKViewer or in BIM Vision. If I look into the IFC-model with Notepad, I notice a lot of $-signs in the definition attributes (see screenshot in the ZIP-file)

Attached: the RVT-model and the IFC4RV exports of both versions of the exporter.

export/import IFC specific parameter is lost

Hello
sea IFC2REVIT en perd des bouts.pdf

1. Make a very simple model : 4 walls 1 space
2. Create a specific parameter for objects space (IfcSpace)
3. Put a value of test for the space create here
4. Export it in IFC
5. Check that the parameter was well recorded in the IFC with a notepad or a IFC viewer
6. Open the model IFC with REVIT and see if the space guards its parameter ... the parameter is lost :c

Export Mapping file - PredefinedType

Making use of the export mapping file seems not to set the PredefinedTypes (values listed in the column IFC Type) anymore in the resulting IFC export. In the export it results in a PredefinedType = NOTDEFINED.

R2019.1 and current-Github-Master-version
IFC4RV

Export Mapping file (File > Options > IFC Options).
I did try 2 mapping files (attached in ZIP):

1. with the values in the column "IFC Class Name" defined as EntityClasses (f.i. IfcCovering)
2. with the values in the column "IFC Class Name" defined as TypeClasses (f.i. IfcCoveringType)
   The PredefinedTypes in the column "IFC Type" are (of course) the same in both mapping files.

Only making use of these mapping files (not using IFCExportAs, because with IFCExportAs the PredefinedTypes are set correctly, with a few exceptions which are listed elsewhere as issue)
seem to result in an export where the PredefinedTypes are NOTDEFINED (except in the case where the export is hardcoded)

4 cases:

1. System Family with hardcoded export setting: export is OK: f.i. System Family Compound Ceiling, Basic Ceiling exports (hardcoded) as IfcCovering with PredefinedType CEILING
2. System Family without hardcoded export setting: PredefinedType is not set correctly in export: f.i. System Family Cable Trays
3. Loadable Family: PredefinedType is not set correctly in export: f.i. Loadable Family Sprinklers
4. Model in Place: PredefinedType is not set correctly in export: f.i. Model in Place Sprinklers, Ceilings

(as I look to the sample file in issue #11, #11 , I assume that issue concerns the use of IFCExportAs and IFCExportType)

[2018-08-28 Export Mapping.zip](https://github.com/Autodesk/revit-ifc/files/2328671/2018-08-28.Export.Mapping.zip)

IFC4RV: issues with last commit

@WawanSolihin
Sorry, there seems to be some regression. With the last commit something is not going well with the tessellation of irregular shaped objects, probably something to do with the fix of the large meshes.
Also some stairs and railings and some walls seems to kind of explode now: when I select them, the bounding box is huge. Before, with version of 08-sept-2018, these objects and the tessellation was OK.
(I do notice that a big sitemesh of the sample at https://sourceforge.net/p/ifcexporter/discussion/general/thread/75a87f43/ , which was not exporting before, is now exportable.)

The offset issue of some walls is fixed, but now some plates of a curtain wall are getting an offset.

It will take some time to prepare samples to isolate these issues.

Prevent Revit from resetting a room to the base point, upon IFC import?

Is there a way to prevent Revit from resetting a room to the base point, upon IFC import?

Files: https://github.com/OpeningDesign/FreeMVD_WorkFlow/tree/5eb690fa18ef1c9674df34a6e53dde0a2eefea49/Specifications%20test%20files/Rooms/from%20Revit

Link IFC needs options for placement and rotation

We need Revit to handle different ways of placing the IFC upon linking.

Eg when the IFC is decided to be in true north, we are able to export it properly by exporting with surveypoint. This should also be possible on linking in.

hidden shared parameters are not exported to ifc

hi i tried to export a series of hidden shared parameters to IFC unfortunately they are ignored by the exporter.
approaches:

1. export user defined property sets ( in IFC export)
2. create a schedule name it IFC-Test and populate it with the hidden shared parameters
3. create a schedule name it IFC-Test and use a calculation parameter that is mapping the hidden parameter

result: no export for all 3 options.
yes the parameters had content and were not empty

flipped = true will never be set on a door

This line of code will never result in flipped == true:

flipped = MathUtil.IsAlmostEqual(Math.Abs(zVec.Z), -1.0);

Because it's comparing a positive number to -1

revit-ifc/Source/Revit.IFC.Export/Utility/DoorWindowInfo.cs

Line 193 in 2b32380

flipped = MathUtil.IsAlmostEqual(Math.Abs(zVec.Z), -1.0);

IFC2x3CV2.0: error with floors exported as IfcWall

Today I exported a batch of models, but this time in IFC2x3CV2.0 (with the current version of the IFC4RV-branch)
Unfortunately with 9 of the 11 models an error window popped up, with errors that could be ignored.
In 2 cases no model at all was generated.
I did a quick test now with the version of the DEV-branch, but unfortunately the same errors are popping up.
It seems mainly related to floors which are exported as IfcWall.
In IFC4RV1.2 they are exported fine (as IfcWall).
In IFC2x3CV2.0 not.
See attached sample.

2018-10-05 floors2IfcWall.zip

IFC2x3CV2.0: door issue & regression

IFC2x3CV2.0
R2018 & R2019

Issue of the orientation of the parametric swing-symbol, and regression of the generation/translation to the correct OperationType, making use of the flip-functionality of doors.

Initial situation:
A door with a nested and shared doorpanel (with a plan swing line, without a value for Operation).
One door is modeled as single swing right (door_SSR)
One door is modeled as single swing left (door_SSL)

Action:
door_SSR is flipped over the Y-axe (resulting in 'door_SSR_Yflip')

Expectation:
door_SSR_Yflip should result in a door identically as door_SSL.

Result:
With 18.4 and 19.1: the operationtype is indeed correctly generated, but there seems to be an issue with the IFCAXIS2PLACEMENT3D, which causes a wrong orientation of the parametric symbol that is displayed in Solibri
Changing value 13
"#295= IFCAXIS2PLACEMENT3D(#293,#19,#13)"
to value 11
"#295= IFCAXIS2PLACEMENT3D(#293,#19,#11)"
seems to solve the direction, at least for Solibri.

But with the R19-current-version-in-the-DEV-branch, some disturbing regression is taking place.
The OperationType of the flipped one is not (anymore) correctly generated, and even the 'as is door_SSL' is now exporting as SSR.
And there is also the issue of the orientation of the parametric symbol.

Attached, only the sample for R2018, since it's also upgradable to R2019.

R2018_door.zip

Regards,
Dirk

Different IFC export behavior for slab/floor from Revit 2018 and Revit 2019

Revit 2018 exported f.ex. floor/slab that was "divided" in the "edit boundary" as separate IFC elements.
Revit 2019 export them as one IFC element.

Is this intended or a bug?

I think most user would like to keep it the way it was in Revit 2018 or a possibility to override it.
Please see attachments.

Dividing them in separate revit instances, means more editing time for the user in case of changes.
This is similar to the issue that`s reported with use of parts. The objective is to make modeling procedures most efficient as possible.

UseOnlyTriangulation export setting can be exported to JSON but is not saved in project

The export setting UseOnlyTriangulation a.k.a. "Keep Tesselated Geometry as Triangulation" ("Advanced" tab) can be exported to JSON but not saved in project.

Tested in 18.4

Steps to reproduce:

• In the export settings dialog, check the abovementioned checkbox
• Save the export setup to disk
• Leave dialog with OK
• Click on "Modify setup"
• Notice that the checkbox is now unchecked again
• Load the previously saved setup from disk
• Notice that the checkbox is now checked again
• Leave dialog with OK
• Click on "Modify setup"
• Notice that the checkbox is now unchecked again

IFC4RV: some walls are getting an offset on export

R2019.1
exporter: current-Github-version-Master-branch
IFC4RV

Some walls (straight or curved) are getting an offset on export (IFC4RV) compared to their original location (1)(2)(3)
On export in IFC2x3CV2 these walls remain in place. But on IFC2x3 export there is the issue that the wall cut (4) isn't successful (probably due to the low tesselation of the wall).

Sample rvt and resulting IFC's are attached (in ZIP).

[2018-09-10 walls - offset on export.zip](https://github.com/Autodesk/revit-ifc/files/2366426/2018-09-10.walls.-.offset.on.export.zip)

Export with PsetMapping - Unwanted Unit Conversion Occurring

Unwanted Unit Conversion Occurring

When exporting the type parameters using the property set mapping the NominalLength, NominalWidth and Nominal Height converts the values to feet, whilst the source attributes are written in millimeters as expected.

Ifcxml

Original Params in one part of the ifc (exporting the Revit Parameters as property sets)

Mapped Params in another part of the ifc (exporting the Mapped Parameters using the IFC2x3 Extended FM HandOve View.txt )

Ifc

At first I thought it was just ifcxml, but then checked the ifc output and the same appears there too.

Original Params in one part of the ifc (exporting the Revit Parameters as property sets)

Mapped Params in another part of the ifc (exporting the Mapped Parameters using the IFC2x3 Extended FM HandOve View.txt )

IFC4RV branch: commit question

@WawanSolihin
The last commit 2641d6b
generates an error while building the solution for Revit.IFC.Common.dll

Something changed in Revit.IFC.Common.csproj

If I use the previous version of this file, the common.dll is building fine.

R2018 exporter question

Is my impression correct that there will be no more updates of the R18 exporter?

Regards,
Dirk

Moving Wiki

Is there any plans to move the wiki over from source forge or start from scratch?
I can't help much with code, but here I and other might be able to lend a hand with documentation.

The same goes for the various files for download - pset files, shared parameters and so on. They might need a separate repo?

Moving new Issue posting from Sourgeforge to Github

I'm wondering if more needs to be done, to move posting of new issues from Sourceforge to GitHub?
Currently it's a bit confusing for new users to find out where to ask questions - I'm guessing it should be here?

IFC4RV: IFC Export Mapping Table: Subcategories of MiP-Ceilings|Floors|Walls

R2019.1

tested with exporter versions:

• regular exporter 19.1
• github current version branch Master
• github current version branch IFC4RV

IFC4RV (& IFC2x3CV2)

issue: In the IFC Export Mapping Table the functionality of 'Not Exported' for the SubCategories isn't working anymore for the Model-In-Places of the Categories Ceilings, Floors, Walls IF the Class is IfcCoveringType, IfcSlabType, IfcWallType: the SubCategories (f.i. Hidden Lines, HuppelDePup) are exported even if they are on 'Not Exported' (attached sample 1)
Only if they are exported to another Class, f.i. IfcBuildingElementProxyType, the use of 'Not Exported' is working as intended (attached sample 2).

The attached IFC4RV-exports are produced with the current Github version of the Master branch.

2018-09-16 MiP Ceilings-Floors-Walls SubCategories.zip

Manually assigning IFCLOCALPLACEMENT/BUILDING STOREY to a IFCelement

This issue is the same as earlier reported in monthly meeting.

When we creates structural floors and associated beams in Revit we usally use the nearet level as reference level with a smal offset or without a offset.

Revit will automatically use the elementhost/reference level when assigning BUILDINGSTOREY to the IfcElement. This is often not correct according to the elements floor affiliation that's defined by our projects BIM manuals.

A workaround is to assign the elementhost (floor and beamsystems) to a "correct" reference level below and with a large offset. We will then lose the opportunity to easy change the element z-location when the relative height for a storey changes. That's common in early stages of a project.

I would like to have the opportunity to manually override a element relations to IfcBuildingStorey.

If i can convert rvt to ifc without revit or forge?

I want to convert rvt to ifc through C#,without revit installed and don't use online forge.
If it's possible?

Which version of VS can run this code rightly?

I use VS 2015 run it,but get some error.So, which version of VS can run this code rightly?
thanks in advance.

Wish: Split by Level. Include Pipes.

The option "Split Walls, Columns, Ducts by Level".
Any Reason why it doesn't include Pipes?

IFC Export config for Site

It would be good to have an option to add a fixed Site to the export config. This way, we are no longed dependant on the correct site being set when doing multiple exports. This is an issue on projects where we operate with multiple sites, and some users change sites from what is correct for the IFC export.

Link IFC does not create Room/Space from IfcSpace

We need IfcSpace to create a Room or a Space in Revit when linking in IFC.

IFC4 and MVD-restrictions

Some questions about IFC4 and MVD-restrictions.

I assume that an IFC-model exported according a particular MVD only can/may contain entities that are defined within the scope of the MVD.
So, if IfcAnnotation isn't part of the scope of IFC4RV1.1, it should not be present in the IFC-model, right?

According to:
http://www.buildingsmart-tech.org/specifications/ifc-view-definition/ifc4-reference-view/comparison-rv-dtv
these entities are not making part of IFC4RV, but are currently exportable with the exporter as IFC4RV:
IfcAnnotation
IfcBeamStandardCase *
IfcColumnStandardCase *
IfcDoorStandardCase *
IfcMemberStandardCase *
IfcPlateStandardCase *
IfcSlabElementedCase *
IfcSlabStandardCase *
IfcWallElementedCase *
IfcWallStandardCase *
IfcWindowStandardCase *
IfcOpeningStandardCase *
IfcVoidingFeature
IfcSurfaceFeature
IfcVirtualElement
IfcProxy *
IfcExternalSpatialElement []

( * = status changed to Deprecated in IFC4_ADD2_TC1: "this definition may be imported, but shall not be exported by applications." )
( [] = I've mentioned IfcExternalSpatialElement in my issue "IfcSpatialElement", but I suppose that after all for IFC4RV it should not be present in the model )

What would be a solution to prevent that these entities are not present in a IFC4RV-model?

Sidenote:
At the moment it is also possible to export IfcSite/IfcBuilding/IfcBuildingStorey as separate geometry on buildingstoreys (example of cubes with the use of IFCExportAs).
I suppose it is OK that these entities can have independent geometry, but the geometry should than be related directly to the entities in the "spatialstructuralelement"-tree, according to rule WR41, isn't ?
(in the way now the IfcSite geometry is produced by the use of a Topography)

Beams and Columns missing Properties - Steel Connections

Hi
Revit 2019:
When beams and columns are part of a steel connection, they export to IFC without the usual properties.

Attachment: Ifc as zip. See below.

Normal:

Connected:

2019 connections.zip

IFC4RV: door & window: export of voids

R2019.1

Apparently something changed in the generation of some doors and windows for the IFC4RV export.

IFC4RV export:
With the regular version 19.1 of the exporter: the IFC-export of the doors and windows is OK.
With the current-Github-Master-branch-version, it seems that the voids (void extrusion / opening cut) are also exported as IfcDoor and IfcWindow.
For IFC2x3CV2 the export is still fine.

Sample rvt and resulting IFC's are attached (in ZIPs)

Notice: the breakdown in separate objects is intended (shared nested families)

2018-09-10 door-window void.zip.002.zip
2018-09-10 door-window void.zip.003.zip
2018-09-10 door-window void.zip.004.zip
2018-09-10 door-window void.zip.001.zip

Exporting IfcElement with type parameters from a host to a divided or merged part

This issue is both a IFC and parts issue, but maybe it could start a project in Autodesk to improve the parts feature.

We use parts to divide large revit instances like floor and wall into for example concrete pouring/production stages. Or we create parts from an original instance with many layers to export them as separate object or to redefine the geometry for some of the layers, for example insulation layers in a floor. Its much faster using divided parts instead of editing a bunch of connected isolated elements if its perhaps get decided to move the line for a production stage or similiar changes.

We dont have the possibility to access the "Edit type" properties to override the original-/host type parameter for a part. This is of course because its not a family type. But we need a possibility to use parts in the same way that we work with Revit instances or the possibility to harvest/export all of the type parameters from the parts host to the IFCelements that`s created from a part.

Its possible to have a duplicate of the host type parameters as instances parameters for the parts, and use Dynamo to copy-paste this parameters value. Buts it`s a very timeassuming workaround.

PitchAngle in Pset_SlabCommon always reports 0° for floor slabs

While IfcSlabs in IfcRoofs correctly report their PitchAngle in Pset_SlabCommon, IfcSlabs generated from Revit floor slabs do not - they always report 0°, regardless of the actual slope.

Tested in 18.4

Expected behaviour:
Either report the actual slope using the method already available for roofs or only export this property for horizontal slabs.

Steps to reproduce

• Open and export the file below
  https://github.com/andydandy74/MyIssues/raw/master/RevitIFC8/SlabCommon_PitchAngle.rvt
• Examine the PitchAngle values in Pset_SlabCommon of the respective floor slabs
• Notice they all are 0°

IFC4RV: runaway footprints of stairway

Probably it is better to post it as separate issue (referring to my last comment in the closed issue #40 ):
Despite the fix of runaway objects, the footprints of the attached stairway are still dislocated.

2018-10-24 runaway footprint.zip

Regards,
Dirk

The state of the checkbox "Export only schedules containing IFC, Pset, or Common in the tile" is not saved.

Version:
Revit 2019.0.1
IFC for Revit 2019 v19.1

Issue:
The state of the checkbox "Export only schedules containing IFC, Pset, or Common in the tile" is not saved when creating custom export setup.

Steps to reproduce:

1. Create new export setup
2. Under the tab "Propery Sets" check "Export schedules as propery sets" and "Export only schedules containing IFC, Pset, or Common in the tile"
3. Export a file
4. Start a new IFC export and go to the "Property Sets" tab. The checkbox "Export only schedules containing IFC, Pset, or Common in the tile" is now unticked.

First when a new export setup is created:

Second on nect export and the same setups is chosen:

IFC4RV & IFC2x3CV2.0: level association regression

R2019
IFC4RV & IFC2x3CV2.0
issue: level association regression

There seems to be a regression issue with some generic models and their level association.
While with 19.1 they are correctly associated with the most close level underneath, which is marked as Building Story (in this case level 03),
they are now (with the current-DEV-branch-version) associated with the lowest of all levels (in this case 00).

2018-10-24_levelassociation_regression.zip

Regards,
Dirk

Some IFC types are no longer set on export

The following export mappings no longer work completely:

Revit object	Previously possible	Result with 18.4
Wall	IfcFooting.STRIP_FOOTING	IfcFooting.NOTDEFINED
Loadable Family (Structural Foundations)	IfcFooting.PAD_FOOTING	IfcFooting.NOTDEFINED
Loadable Family (Structural Foundations)	IfcPile.SUPPORT	IfcPile.NOTDEFINED

This is a regression that must have slipped in at some point between (probably) 18.2 and 18.4

Steps to reproduce

• Open the following model
  https://github.com/andydandy74/MyIssues/raw/master/RevitIFC11/MissingTypeAssignments.rvt
• Export with older exporter version
• Export with newer exporter version
• Compare the two IFC files in a text editor and notice that in the newer file all element types are assigned the NOTDEFINED value

Parts: location offset

Parts: location offset of exported geometry

• R2019**.1**, current-Github-master-exporter-version
• IFX2x3CV2 and IFC4RV1

for a Model In Place, as well as for a Loadable Family, category Generic Model:
Create Parts > Divide Parts > Edit Sketch: draw line: on export the parts are located with an offset to their original location: issue.

sample file attached

Note 1: I added floors underneath the Generic Models as reference location
Note 2: with R2019.1 there is only an offset in x & y direction // with R2019 there was also an offset in Z-direction
The offset increases if the distance to the 0-point increases.

[2018-08-15 Parts.zip](https://github.com/Autodesk/revit-ifc/files/2291214/2018-08-15.Parts.zip)

Copy/paste error suspected in DistributionPort creation process.

In ConnectorExporter.AddConnection method there is two calls to AddNestedMembership method, the first for the In port, the second for the Out port. But in both calls the inElementIFCHandle is used as parameter.
So the two ports are nested to the same object.

Look at the if (isIFC4AndAbove) condition:

         // ----------------------- In Port ----------------------
         {
            string guid = GUIDUtil.CreateGUID();
            IFCFlowDirection flowDir = (isBiDirectional) ? IFCFlowDirection.SourceAndSink : IFCFlowDirection.Sink;

            IFCAnyHandle localPlacement = CreateLocalPlacementForConnector(exporterIFC, connector, inElementIFCHandle, flowDir);
            string portName = "InPort_" + inElement.Id;
            string portType = "Flow";   // Assigned as Port.Description
            portIn = IFCInstanceExporter.CreateDistributionPort(exporterIFC, null, guid, ownerHistory, localPlacement, null, flowDir);
            IFCAnyHandleUtil.OverrideNameAttribute(portIn, portName);
            IFCAnyHandleUtil.SetAttribute(portIn, "Description", portType);

            // Attach the port to the element
            guid = GUIDUtil.CreateGUID();
            string connectionName = inElement.Id + "|" + guid;
            IFCAnyHandle connectorIn = null;

            // Port connection is changed in IFC4 to use IfcRelNests for static connection. IfcRelConnectsPortToElement is used for a dynamic connection and it is restricted to IfcDistributionElement
            // The following code collects the ports that are nested to the object to be assigned later
            if (isIFC4AndAbove)
               AddNestedMembership(inElementIFCHandle, portIn);
            else
               connectorIn = IFCInstanceExporter.CreateRelConnectsPortToElement(ifcFile, guid, ownerHistory, connectionName, portType, portIn, inElementIFCHandle);
         }

         // ----------------------- Out Port----------------------
         {
            string guid = GUIDUtil.CreateGUID();
            IFCFlowDirection flowDir = (isBiDirectional) ? IFCFlowDirection.SourceAndSink : IFCFlowDirection.Source;

            IFCAnyHandle localPlacement = CreateLocalPlacementForConnector(exporterIFC, connected, outElementIFCHandle, flowDir);
            string portName = "OutPort_" + outElement.Id;
            string portType = "Flow";   // Assigned as Port.Description

            portOut = IFCInstanceExporter.CreateDistributionPort(exporterIFC, null, guid, ownerHistory, localPlacement, null, flowDir);
            IFCAnyHandleUtil.OverrideNameAttribute(portOut, portName);
            IFCAnyHandleUtil.SetAttribute(portOut, "Description", portType);

            // Attach the port to the element
            guid = GUIDUtil.CreateGUID();
            string connectionName = outElement.Id + "|" + guid;
            IFCAnyHandle connectorOut = null;

            // Port connection is changed in IFC4 to use IfcRelNests for static connection. IfcRelConnectsPortToElement is used for a dynamic connection and it is restricted to IfcDistributionElement
            // The following code collects the ports that are nested to the object to be assigned later
            if (isIFC4AndAbove)
               AddNestedMembership(inElementIFCHandle, portOut);
            else
               connectorOut = IFCInstanceExporter.CreateRelConnectsPortToElement(ifcFile, guid, ownerHistory, connectionName, portType, portOut, outElementIFCHandle);
         }

I will make a pull request for that.

IFC4RV: IfcColourRgb(List) question

It's merely a question rather than an issue (as I assume), but looking at the colors of the models generated for the different MVD's, there are some differences.
In the IFC2x3CV2.0 and IFC4DTV1.0 output only IfcColourRgb is used, and viewers are capable of showing these colors.
In the IFC4RV1.2 output mostly IfcColourRgbList is used, and in a few cases IfcColourRgb: is there a viewer that can handle IfcColourRgbList? Or what is the cause that the colors in IFC4RV are 'different'?
Regards,
Dirk

DEV branch: error build solution

Unfortunately, compiling the dll's gets stuck on:

Project: Revit.IFC.common
File: MathUtil.cs

• Type 'MathUtil' already defines a member called 'IsAlmostEqual' with the same parameter types
• The call is ambiguous between the following methods or properties: 'MathUtil.IsAlmostEqual(double, double, double)' and 'MathUtil.IsAlmostEqual(double, double, double)'

Regards,
Dirk

Handle very large cartesianpoints

Sometimes we get IFC files (mainly from Archicad) where the file has huge numbers in the IfcCartesionpoints. When opening these IFC files in Solibri, they look fine with normal coordinates in "location". However, when linking/opening the same files in Revit, the models tend to be placed very far away from the Revit Origin.

I have sent an example of such an IFC directly to Angel Velez, and I can supply this again upon request.