IFCTerrain Developer Documentation - dd-bim/City2BIM GitHub Wiki

The developer documentation provides important information from the developer's point of view.

In the following the general structure is explained. If you are already familiar with it you can also read about the following topics: Code Structure & Databinding.

---

For the basic structure, the following figure is intended:

The program flow can be described by following essential steps.

First of all, a distinction is made in the usage. Here, a decision is made between IFCTerrain GUI and IFCTerrain Command. To use the GUI, the user must provide input. This can be read here: here

To use the Command, the user must provide input data (JSON file). This can be read here: here

The file path: BIMGISInteropLibs/IfcTerrain/ is essential for the control of the entire program flow. Different classes are stored here:

• Config.cs - All essential settings for configuration are made here.

---

To store for the export of the metadata:

• configDin18740.cs - according to DIN 18740-6
• configDin91391.cs - according to DIN SPEC 91391-2

---

Another essential file for successful execution of a conversion is: BIMGISInteropLibs/IfcTerrain/ConnectionInterface.cs

This is used by both program parts (GUI and Command) to read the input data set and write it as an IFC file.

First, a file reader (depending on the settings in config) reads the file (in its specific format) and prepares it for further processing.

Each reader is stored as "ReaderTerrain.cs" in the folder "BIMGISInteropsLibs" - in the corresponding subfolder.

For the exchange between file reader & IFC writer the class (Result) from is used: BIMGISInteropLibs/IFCTerrain/Result.cs This is therefore the most important element for the short data exchange.

Input data can be cropped by using a boundingbox, defined by xExtend and yExtend. Extends are calculated relative to customOrigin. Therefore setting customOrigin to true is mandatory. When a Boundingbox(Envelope) is used, all points outside the envelope are removed. Along with the points all connected triangles are removed and edges are intersected with the envelope. When a envelope is applied Triangulation (Step 7) is called to re-mesh borders where triangles where deleted.

For point-only based, or re-meshing input data a meshing is done using Triangle.NET. Breaklines and envelopes are set as constraints, existing triangles are added as hole-regions, which prevents remeshing and keeps them untouched. In a merging step all triangles from Triangulation are merged with triangles from input data.

If a value for filtering is set, each point of the mesh from step 7 along with its connected neighbours is used for a plane fit. If point to plane z-distance is below given threshold, point is removed. If points where removed triangulation (step 7) is called again.

Now the corresponding (depending on the settings) IFC - Writer is called.

For more information about IFC-Writers the following page can be used: here

The IFC Writer creates the desired export file. This step does not fail in most cases. Only if: the file path cannot be accessed (unlikely) or the model is empty.

The program also writes the following files:

• log file, controlled via: BimGISInteropsLibs/Logging/LogWriterIfcTerrain.cs

  ---

  only in IFCTerrain GUI:

• setting file (*.json; reusable for the use of IFCTerrain Command)

• metadata json file (if seleceted as as export)

The log file writes (depending on settings) the corresponding events. This can be read: here

The setting file will be exported under the use of IFCTerrain GUI. In the code-behind of the "MainWindow.xaml.cs". A json parser is used here. This also exports (depending on the setting / input) the metadata as another separate JSON file.

In this step (caused by ConnectionInterface.cs) the user gets a feedback about the conversion done.

Hint: This is also done once an error has been caught in the program. (e.g.: TIN is empty after processing via the file readers)

For testing of IFCTerrain a TestProject was used. A folder containing different Testdata can be set in TestDataPath. The Folder is searched for supported filetypes and Testcases are generated by different combinations of IFC-Version, and gemetry type. Additionaly combinations for envelope and filtering settings are tested. This leads to currently 37 Testcases per file!

As tests can be executed in parallel it can lead to XBim limitations. In that case, re-running the testscases can help.

Each test gets an unique ID which makes it possible to refer to the corresponding ifc-output. Ifc files results are stored in City2BIM\UnitTest\bin[Debug/Release]\net8.0-windows\TestArtifacts.