IFC Name Attribute Mapping


Overview

Architects exchanging data via IFC found the element ID was not descriptive enough for the name attribute of an element. A user definable naming convention for individual element groups like walls, slabs, zones, objects was created to address this need. The rules for the naming convention are placed in a mapping file.

The mapping file is a set of rules formatted in xml to bring data from different fields in an ARCHICAD project into the IFC Name Attribute field. This mapped data is available in the IFC Manager/settings dialogs and in data exported to IFC files. Currently for all elements the following values are available:

  • IDValue
  • StructureNameValue

Windows, Doors, Stairs, Zones, and any GDL element can additionally add to the IFC attribute name:

  • LibraryPartNameValue
  • ParameterValue

Any of the above mentioned values can be broken into fragments by a character or characters that serve as a separator. These fragments can also be mapped into the IFC name attribute.

Each tool type (wall, slab, window, door, beam, morph, etc) can also have a fixed text added:

  • TextValue

Details

When working with Name Attribute Mapping it is important to note:

  1. The NameAttributeMapping.xml must be located inside the Add-Ons/Import-Export folder.
  2. You must re-launch ARCHICAD to re-read the NameAttributeMapping.xml after editing it.
  3. If the NameAttributeMapping.xml is syntactically incorrect ARCHICAD will silently ignore the file.

For standard structural elements the IDValue and StructureNameValue can be found in the interface in positions similar to the two below examples:

  • WallValues80.PNGRoofValues80.PNG

For Doors and Windows and GDL Objects the StructureNameValue has been given the fixed value “Background." Instead of this value use the following two additional values for Doors, Windows, Zones, and GDL Objects:

  1. LibraryPartNameValue
  2. ParameterValue

The LibraryPartNameValue is self-descriptive. It is the name of the Library part. The ParameterValue takes one xml tag attribute and it is “parameterName.” The available parameter names for any GDL object are found in the parameter section of the GDL editor for that object. See the below screenshot.

  • UsableObjectParameters80.PNG

Mapping Values

Some concrete examples from the sample NameAttributeMapping.xml will make the theory a bit more clear.

Below is the section of the mapping that addresses all elements that were created with the Wall tool:

   <Mapping tool="Wall">
      <StructureNameValue/>
   </Mapping>

This bit of xml grabs the StructureNameValue and copies it into the Name Attribute for every wall object that it meets. It is pretty much the simplest mapping you can do. The topmost hierarchical tag specifies the ARCHICAD tool to which the enclosed rules apply. In this case the tag “<Mapping” has an attribute narrowing the ARCHICAD elements to the tool=”Wall”.

   <Mapping tool="Wall">
   …
   </Mapping>

Here is a mapping for a wall object that brings in a few additional features:

   <Mapping tool="Wall">
      <GroupValue separator=" ">
         <IDValue/>
         <StructureNameValue/>
         <TextValue text ="Wall"/>
      </GroupValue>
   </Mapping>

The GroupValue tag specifies how enclosed xml elements will be separated. In this example the xml elements are separated with a space.

      <GroupValue separator=" ">
      …
      </GroupValue>

Finally within the grouping are three xml empty-elements tags that specify ARCHICAD values:

         <IDValue/>
         <StructureNameValue/>
         <TextValue text ="Wall"/>

The ARCHICAD settings dialog for a selected wall has the following information:

  • wallExampleSettings80.PNG

The mapping creates the following output in the IFC Manager

  • wallExampleIFCManager80.PNG

The LibraryPartNameValue is used in the next example mapping of a Window. Two separators are used. A single space separates the values IDValue, LibraryPartNameValue and a concatenation of GDL parameter values “A” (width) and “B” (height). A multi-character separator “ x “ separates the GDL parameters. The values with parameter names of “A” and “B” will be listed in meters.

   <Mapping tool="Window">
      <GroupValue separator=" ">
         <IDValue/>
         <LibraryPartNameValue/>
         <GroupValue separator=" x ">
            <ParameterValue parameterName="A"/>
            <ParameterValue parameterName="B"/>
         </GroupValue>
         <TextValue text ="Window"/>
      </GroupValue>
   </Mapping>

So given the following settings for a window:

  • windowExampleSettings80.PNG

The following output will be seen:

  • windowExampleIFCManager80.PNG

In the final example mapping, a fragment is displayed from a user defined value in a GDL Object.

   <Mapping tool="Object">
      <GroupValue separator=" - ">
         <IDValue/>
         <LibraryPartNameValue/>
         <TextValue text ="object"/>
         <SplitValue separator=":" index="5" indexFrom="Start" splitType="FragmentAtIndex">
            <ParameterValue parameterName="gs_list_custom1"/>
         </SplitValue>
      </GroupValue>
   </Mapping>

Given the following GDL Object data:

  • GDLObjectExampleSettings80.PNG

The following formatted output will be in the IFC Manager and exported IFC files.

  • GDLObjectExampleIFCManager80.PNG

Splitting Values

The rule for splitting a value into fragments has the following form:

   "<SplitValue"   a description of what fragment of a string you want >”
      < The value you want to fragment. Can be simple value or a group of values concatenated together with GroupValue, …/> 
   "</SplitValue>"

There are 4 xml tag attributes that specify which fragment(s) will be selected.

  • separator
    • Any group of one or more characters used to break the string into fragments

    index

    • Using splitType= FragmentAtIndex
      • A value starting with 1 and ending with the number of fragments in the string
    • Using splitType = ToSeparatorAtIndex or splitType = FromSepartorAtIndex
      • A value starting with 1 and ending with the number of separators in the string

    indexFrom

    • index fragments progressing from the Start of the string to the end (Start)
    • index fragments progressing from the End of the string to the start (End)

    splitType

    • select only the indexed fragment (FragmentAtIndex)
    • select everything from the beginning of the string To the indexed separator (ToSeparatorAtIndex)
    • select everything From the indexed separator to the end of the string (FromSeparatorAtIndex)

Examples of Splitting Values into Fragments

Example 1.

Several characters can be used to separate a string into fragments. In example 1 the second fragment is output of a string with two fragments.

   <SplitValue separator=":::" index="2" indexFrom="Start" splitType="FragmentAtIndex">
      <ParameterValue parameterName="gs_list_custom1"/>
   </SplitValue>

input: whap: bing ::: do wow: zing

output: do wow: zing

Example 2

The same string used in example one is broken into 6 fragments when the separator is changed to a single ":". Note that fragments 3 and 4 are empty.

   <SplitValue separator=":" index="2" indexFrom="Start" splitType="FragmentAtIndex">
      <ParameterValue parameterName="gs_list_custom1"/>
   </SplitValue>

input: whap: bing ::: do wow: zing

output: bing

Example 3

   <SplitValue separator=":" index="5" indexFrom="Start" splitType="FragmentAtIndex">
      <ParameterValue parameterName="gs_list_custom1"/>
   </SplitValue>

input: whap: bing ::: do wow: zing

output: do wow

In examples 4 through 7 the IndexFrom is toggled between Start and End showing how the same index will select a different fragment depending on whether the counting is started from the beginning or end of the string.

Example 4

   <SplitValue separator=" " index="1" indexFrom="Start" splitType="FragmentAtIndex">
      <FieldName/>
   </SplitValue>

input: whap bing do wow zing

output: whap

Example 5

   <SplitValue separator=" " index="1" indexFrom="End" splitType="FragmentAtIndex">
      <FieldName/>
   </SplitValue>

input: whap bing do wow zing

output: zing

Example 6

   <SplitValue separator=" " index="2" indexFrom="Start" splitType="FragmentAtIndex">
      <FieldName/>
   </SplitValue>

input: whap bing do wow zing

output: bing

Example 7

   <SplitValue separator=" " index="2" indexFrom="End" splitType="FragmentAtIndex">
      <FieldName/>
   </SplitValue>

input: whap bing do wow zing

output: wow

If the index is not valid for the string the output will be empty.

Example 8

   <SplitValue separator=" " index="6" indexFrom="Start" splitType="FragmentAtIndex">
      <FieldName/>
   </SplitValue>

input: whap bing do wow zing

output: <empty> the 6th fragment does not exist

If the index is invalid the output is empty.

Example 9

   <SplitValue separator=" " index="0" indexFrom="Start" splitType="FragmentAtIndex">
      <FieldName/>
   </SplitValue>

input: whap bing do wow zing

output: <empty> index = 0 not valid

In examples 10 and 11 FromSeparatorAtIndex is used to select several fragments that start from the index and go to the end of the string.

Example 10

   <SplitValue separator=" " index="2" indexFrom="Start" splitType="FromSeparatorAtIndex">
     <FieldName/>
   </SplitValue>

input: whap bing do wow zing

output: do wow zing

Example 11

   <SplitValue separator=" " index="2" indexFrom="End" splitType="FromSeparatorAtIndex">
      <FieldName/>
   </SplitValue>

input: whap bing do wow zing

output: wow zing

In examples 12 and 13 several fragments that start from the beginning of the string and include the index

Example 12

   <SplitValue separator=" " index="2" indexFrom="Start" splitType="ToSeparatorAtIndex">
      <FieldName/>
   </SplitValue>

input: whap bing do wow zing

output: whap bing

Example 13

   <SplitValue separator=" " index="2" indexFrom="End" splitType="ToSeparatorAtIndex">
      <FieldName/>
   </SplitValue>

input: whap bing do wow zing

output: whap bing do

Sample Name Attribute Mapping file

NameAttributeMapping.xml