Splitting Rules of IFC Mapping

[Vimal Kumar]

This post is to follow up on the previously published ‘Syncing Zone Cover Fills and Floor Finishes’ article where we mapped the Cover Fill value of the Zones to a custom made IFC property and made it appear in the Zone Stamp, this way saving some time, but most importantly reducing the risk of human errors when the user has to manually update the Floor Finish parameter of the Zones.

We also faced a minor (?) problem: since the naming convention of the Fills is diverse, not all Fills can be used right away to be displayed with their names as Floor Finishes. For example all ‘Pavement xx’ fills should only show ‘Pavement’, instead of showing the full name, including the version number.

Splitting the IFC Mapping rules is a way to solve this problem. A similar case where rule splitting was involved for the Zone Names has already been presented on this blog by Chidam, this post intends to give some detailed explanation on the rule splitting particularly, so it is easier to embrace it. IFC Mapping is NOT ONLY for model exchange purposes!

Let’s open File/Interoperability/IFC/IFC Translator/Property Mapping/Map IFC Properties for Export and look for the Custom property. Say for example, the Custom Property of the Zone that we created in the above mention example. Click the little arrow next to the mapping rule content to Apply Splitting Rule.

Let’s see the settings with a longer value as an example where the original mapped Cover Fill is ‘Brick Floor – Laid on Edge’.

Splitting Rule Settings

1., First we can define a string separator. This can be any kind of text that is part of the value. Whatever we type in here will separate the value into fragments. For example if the separator is ‘Floor’ then the string before ‘Floor’ will become one fragment and the rest after it will also become another fragment. In our case, if we just hit the spacebar into the field, it will mean 5 separators (the 5 spaces) and create 6 fragments in the ‘Brick Floor – Laid on Edge’ string:

• Brick
• Floor
• –
• Laid
• on
• Edge

2., These fragments will be referred to by their numbers in the string. How we want to count from left or right can be set by choosing Beginning or End from the list.

3., Where to split the string? We need to use the number of the fragment also considering where we start counting from. In this example if we want to split at ‘Floor’, we can use Beginning, 2 (or End, 5). As another example, if we want to split at the last fragment, we can use End, 1.

4., Based on the splitting position we can define which part we want to keep from the value string:

• From Start to Fragment: the string from the beginning, finishing with the splitting fragment (if no.2, which is Floor, then results in ‘Brick Floor’)
• Fragment Only: keeps the splitting fragment (‘Floor’)
• From Fragment to End: starts with the splitting fragment, finishing at the end of the string (‘Floor – Laid on Edge’)

Note: The splitting fragment is always part of the result. ‘Start’ and ‘End’ in the 4th field always refer to left and right ends of the string respectively – regardless of the Beginning/End setting.

See the separators (red blocks), the fragments with their numbers starting from left/right (Beginning/End) as well and the result alternatives (dashed arrows) if the splitting fragment is no. 2 (‘Floor’):

The second fragment from the beginning after the space is ‘Floor’, we would like to see everything from the beginning to the fragment which results in ‘Brick Floor’ – This is what we will see in the custom IFC property and eventually in the Zone Stamp as well.

Note: This is just an example, this setup will probably not give us the desired output for every Cover Fill since the naming conventions vary.

In case of the ‘Pavement xx’ fills, we can apply the following settings:

If space is the separator, it will create two fragments. The second fragment from the end is ‘Pavement’, in this case ‘Fragment Only’ and ‘From Start to Fragment’ will show the same results, but in case of a fill that contains more fragments like ‘Roof Tiles xx’ the results would be different: ‘Tiles’ and ‘Roof Tiles’ respectively.

Best practice is to find a working naming convention at least for those fills that are to be used as Cover Fills. All of them can have a number in the end for example which is necessary to distinguish them and store them as Fills, but those numbers will always be hidden whenever we display the names using the mapping to a custom property with a split rule – works in the Interactive Schedules as well! As mentioned… IFC Mapping is not only for model exchange