Product(s):	OpenBuildings Designer
	Version(s):	CONNECT Edition
	Area:	Import/Export
	Subarea:	IFC

Background

The purpose of each section in a typical IFC_*Filter.set file is unclear, so I'm not sure how to use them to control IFC Export.

These are my areas of interest:

1. EXCLUDE_DOMAIN - What exactly can be excluded here? I see examples such as IfcMaterialList and and IfcRelSpaceBoundary2ndLevel, but what are they and why would I want exclude them?
2. SYSTEMS - What are "systems" in this context?
3. EXCLUDE_REPRESENTATION - From what I've read on buildingSMART I think is this related to SurveyPoints in some fashion?
4. WANT_SOLID_FOR - Where might I want or not want solids?
5. ALLOW_PROPERTY_SET - I understand that this refers to properties as outlined in this wiki. But why does "Pset_*" include an asterisk, @AirHandling used with an @ sign, while BaseQuantities and WallQuantities have no special signs at all? Is here some hierarchy or grouping of properties?

Solution

The general formatting of the IFC_*Filter.set files is as follows:

1. EXCLUDE_DOMAIN defines the Types and Elements to exclude from FM Handover (COBie). For example, IfcBeamType and IfcWall are listed because these are not part of Facilities Management. The same goes for generic element types such as IfcBSplineSurface, IfcPolyline or IfcMaterialLayer, things that do not exist in real-world terms but are instead geometric or symbolic representations. As for the IfcRelSpaceBoundary variations, they are used to define various aspects of spaces and how they are bound to their surroundings. Again, while they make sense from a planning and design perspective, they don’t represent real-world assets. You can read more on these buildingSMART pages:
https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/ifcproductextension/lexical/ifcrelspaceboundary.htm 
https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC1/HTML/schema/ifcproductextension/lexical/ifcrelspaceboundary1stlevel.htm 
https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC2/HTML/schema/ifcproductextension/lexical/ifcrelspaceboundary2ndlevel.htm 

2. SYSTEMS, in purely technical terms, is used to “enumerate xpath of properties used to group, and optionally identifies type of system”. For practical purposes it is used to define, quite literally, elements that belong to a system such as HVAC and Plumbing (based on System ID) or Electrical (based on Circuit_ID).

3. EXCLUDE_REPRESENTATION does relate to SurveyPoints based on the information provided by BuildingSMART.  It is excluded primarily because survey points are not part of the OpenBuildings Designer toolset, at least not in terms of DataGroup enabled tools which is where the primary DGN to IFC mapping takes place. One can enable it by removing the exclusion, but there are no specific element types to be exported from a pure OpenBuildings Designer perspective. Looking forward, buildingSMART is branching out into other disciplines, including civil, and at the same time Bentley Systems is expanding iTwins for IFC export at a multi-discipline level.

4. WANT_SOLID_FOR lists the IFC classes for which a solid representation is preferable to a sheet (shape/surface).

5. For ALLOW_PROPERTY_SET:
- Why does Pset_* include an asterisk?
   o Psets are grouped into a series of individual files that begin with the prefix “Pset_”, as they are for “COBIE_”, so the entries include these items at a file name level.

- Why does @AirHandling use the "@" symbol?
   o @AirHandling, @Door, @Pumps, etc., are specific Catalog types with the “@” used to define the applicable “xpath” - the path to a Catalog type or its property groups/properties.

- Why do BaseQuantities and WallQuantities have no special signs?
   o These are property definitions used by the applicable object types so need no further enumeration.