optimised design methodologies for …eeembedded.eu/wp-content/uploads/2017/09/20160610_eee_d4...0.1...

This project has received funding from the European Union Seventh Framework Programme

under grant agreement n° 609349.

OPTIMISED DESIGN METHODOLOGIES FOR ENERGY-EFFICIENT

BUILDINGS INTEGRATED IN THE NEIGHBOURHOOD ENERGY SYSTEMS

eeEmbedded – D4.5

Multimodel Filter

Responsible Authors: Marc Mosch, Arne Tøn

Co-Authors: Peter Katranuschkov, Frank Noak, Robert Schülbe

Due date: 31.03.2015

Issue date: 10.06.2015

Nature: Prototype

Coordinator: R. J. Scherer, Institute for Construction Informatics, Technische Universität Dresden,

Germany

D4.5 Multimodel Filter

Version 1.0

/72

© eeEmbedded Consortium www.eeEmbedded.eu

Start date of project: 01.10.2013 Duration: 48 months

Organisation name of lead contractor for this deliverable:

Technische Universität Dresden CIB

History

Version Description Lead Author Date

0.1 Deliverable Structure Mosch (CIB) 21.11.2014

0.2 Motivation initial input Mosch, Katranuschkov (CIB)

30.01.2016

0.3 Filtering Methodology Mosch (CIB), Katranuschkov (CIB)

18.02.2016

0.3 Content for FilterIFC Noak , Mosch (CIB) 20.05.2016

0.4 Content Server Side Filtering Tøn (EPM), Mosch (CIB) 23.05.2016

0.5 Structural changes Katranuschkov, Mosch (CIB)

24.05.2016

0.6 Additional input, Revision Mosch (CIB) 26.05.2016

0.7 Content new eeE Functions Schülbe, Mosch (CIB) Stenzel (EAS)

28.05.2016

0.8 Corrections Mosch (CIB) 29.05.2016

0.8 Corrections Mosch (CIB) 31.05.2016

1.0 Final Revision, Proof Reading Mosch (CIB) 10.06.2016


Version 1.0

/72


Copyright

This report is © eeEmbedded Consortium 2015. Its duplication is restricted to the personal

use within the consortium, the funding agency and the project reviewers. Its duplication is

allowed in its integral form only for anyone's personal use for the purposes of research or

education.

Citation

Mosch, M. & Ton A. (2016); eeEmbedded D4.5: Multimodel Filter, © eeEmbedded Consortium, Brussels. Acknowledgements

The work presented in this document has been conducted in the context of the seventh

framework programme of the European community project eeEmbedded (n° 609349).

eeEmbedded is a 48 month project that started in October 2013 and is funded by the European

Commission as well as by the industrial partners. Their support is gratefully appreciated. The

partners in the project are Technische Universität Dresden (Germany), Fraunhofer-Gesellschaft

zur Förderung der angewandten Forschung E.V (Germany), NEMETSCHEK Slovensko, S.R.O.

(Slovakia), Data Design System ASA (Norway), RIB Information Technologies AG (Germany), Jotne

EPM Technology AS (Norway), Granlund OY (Finland), SOFISTIK HELLAS AE (Greece), Institute for

applied Building Informatics IABI (Germany), FR. SAUTER AG (Switzerland), Obermeyer Planen +

Beraten (Germany), Centro de Estudios Materiales y Control de Obras S.A. (Spain), STRABAG AG

(Austria) and Koninklijke BAM Group NV (The Netherlands). This report owes to a collaborative

effort of the above organizations.

Project of SEVENTH FRAMEWORK PROGRAMME OF THE EUROPEAN COMMUNITY

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission

Services)

CO Confidential, only for members of the consortium (including the Commission

Services)


Version 1.0

/72


Abbreviations

AEC Architecture, Engineering and Construction

BACS Building Automation and Control Systems

BIM Building Information Mode

BIMfit BIM Filter and Integration Toolbox

CAD Computer Aided Design

CFD Computational Fluid Dynamics

eeE eeEmbedded

ESIM Energy System Information Model

GAEB Gemeinsamer Ausschuss Elektronik im Bauwesen

HTTP HyperText Transfer Protocol

HVAC Heating Ventilation and Air Conditioning

ID Identifier

IDM Information Deliverable Manual (ISO 29481)

IFC Industry Foundation Classesv (ISO 16739))

ISO International Organization for Standardization

JSON JavaScript Object Notation

KPI Key Performance Indicator

MAS Model Access Service

MVD Model View Definition

OAS Ontology Access Service

RDF Resource Description Format

REST REpresentational State Transfer

SDAI Standard Data Access Interface for the ISO 10303 (STEP) family standards

SOAP Simple Object Access Protocol

SPF Step Physical File

STEP Standard for the Exchange of Product Data (ISO 10303)

URL Uniform Resource Locator

UUID Universally Unique IDentifier

XML Extensible Markup Language


Version 1.0

/72


TABLE OF CONTENTS

Executive Summary ________________________________________________________________ 6

1 Motivation ___________________________________________________________________ 7

1.1 Model Views ____________________________________________________________ 7

2 Filtering Methodology _________________________________________________________ 8

3 Model views ________________________________________________________________ 10

3.1 Model view types _______________________________________________________ 10

3.2 Multimodel views _______________________________________________________ 10

3.3 Model Filtering Technologies in eeE _________________________________________ 11

4 Descriptive filtering ___________________________________________________________ 13

4.1 IfcDoc _________________________________________________________________ 13

4.2 XmlToFilterConverter ____________________________________________________ 14

5 IFC-API _____________________________________________________________________ 15

5.1 Principles ______________________________________________________________ 15

5.2 Filter services ___________________________________________________________ 17

5.3 List of services __________________________________________________________ 20

6 FilterIFC ____________________________________________________________________ 21

7 A BIM Filter Toolbox __________________________________________________________ 25

7.1 The Layer Model Approach ________________________________________________ 25

7.2 Base Functions __________________________________________________________ 27

7.3 Technical Overview ______________________________________________________ 30

7.4 New Functions in the eeE context ___________________________________________ 32

Conclusions _____________________________________________________________________ 34

References______________________________________________________________________ 35

8 Appendix ___________________________________________________________________ 37

8.1 IFC-API – Service Definitions _______________________________________________ 37

8.2 IFC-API – Usage Examples _________________________________________________ 41

8.3 BIMfit – Meta (STEP/SDAI) filter functions ____________________________________ 43

8.4 BIMfit – Core filter functions _______________________________________________ 50

8.5 Bimfit – Extended/Reasoning filter functions __________________________________ 63

8.6 New ee filter functions ___________________________________________________ 66


Version 1.0

/72


Executive Summary

The objective of Deliverable 4.5 “Multimodel Filter” is to provide technologies for Multimodel

filtering. A special filter toolbox for ee-functionalities is developed based on the filter toolbox

formerly developed in the Mefisto project by CIB. This modularized filtering approach allows high

reuse of the filter modules in many different use cases. New ee-functionalities are developed as

well as new ee-query modules and modules needed for the new ESIM (T4.2) and BACS semantic

model and the BACS data format.

D4.5 is structured into seven chapters:

The first chapter covers the motivation and gives an overview of the model view types.

In the second chapter the filtering methodology is presented.

In the third chapter the model view types are presented in more detail.

The fourth chapter covers the technologies utilised for descriptive filtering in eeE.

The fifth chapter is dedicated to the prescriptive filter technology provided by IFC-API, the interface of the EDMModelServer.

The sixth chapter presents FilterIFC, another prescriptive filter technology.

The seventh chapter gives an overview on the filter toolbox BIMfit. It presents the general layer model approach and the toolbox functionality as well as its ee-extension.

CIB, EPM, EAS and SAR were involved and each of those partners contributed according to the

individual expertise as follows:

The deliverable was led by CIB. The content of this deliverable was elaborated and discussed in

frequent web conferences between all above mentioned partners. CIB was leading discussions

and has contributed in all tasks.

CIB: all tasks, deliverable elaboration, content of chapters 1–4 as well as 6–7 and Appendix 8.3-8.6, editing

EPM: content chapter 5 and Appendix 8.1 and 8.2

EAS: input subchapter 7.4 and Appendix 8.6

SAR: discussion and advices


Version 1.0

/72


1 Motivation

1.1 Model Views

The heterogeneity of the domains involved in the building industry as well as the sheer size and

complexity of the most model data lead to a high semantic and structural variety of potential

model views (Scherer&Schapke 2014). An individual model view can correspondingly either be a

valid full partial model or consist of a quantity of selected, reduced or transformed objects. It can

even merely be composed of individually derived aggregated or calculated object information like

features and relationships that describe the information demand in the context of a specific

requirements situation. As depicted in Figure 1 the following model view types can be

differentiated in the context of eeE:

Full model view: As the name suggests, the full model view represents the

complete and unaltered model.

Static/domain model view: A static model view is an independent valid partial model whose

content is defined before the filter process and is assigned to a

specific partial model specification (e.g. HVAC view)

Dynamic/ad-hoc model view: A dynamic model view covers a task specific subset of a model

(e.g. query for the volume of all components of a specific type to

be found in a specific area).

Multimodel view: A Multimodel view is a static or dynamic model view created

taking additional non-BIM data models of external (domain)

information into account (e.g. determination of all rooms in a

specific area that show an increased average temperature)

Figure 1: Model view types relevant in eeE: (A) full model view (B) static/domain model view, (C) dynamic/ad-hoc model view, (D) Multimodel view


Version 1.0

/72


2 Filtering Methodology

The intention of model filtering is to enhance the model’s usability by reducing its content to a

suitable level. The resulting so called model view is a subset of the model which is tailored to the

target application and therefore easier to handle. In addition the model view consumes less

transmission bandwidth and allows excluding potentially confident data from the original model

before handing the data over to the next domain expert. Two basic classes of filtering methods

can be differentiated, descriptive methods which realize the filtering with the help of formal

schemes or languages and prescriptive methods that utilize a set of basic operations that form a

logical procedure executed at runtime.

Descriptive methods can be developed separately and independent of any programming

language or application. They are highly transparent and can be standardised. Then again they

have a limited expressive power on object/instance level and it is not possible to apply reasoning

mechanisms tailored to a specific model context. As a result, descriptive filtering methods alone

are only suitable for large, well-defined and frequently needed model views like the transmission

from architectural to HVAC design.

In contrast to that, prescriptive methods are more flexible and powerful. They enable an easier

extension but are at the same time dependent on the underlying programming language which

makes them less transparent, less adaptable and less suitable for standardisation. Given these

characteristics the application area of prescriptive methods is mainly the filtering of specific

content in specific contexts.

In order to adress the filtering challenge in eeE the methodology for development, use and

implementation of different model views is applied. This methodology was originally proposed for

the generation of BIM-based Multimodel views in (Katranuschkov et al. 2010) as an extension of

the IDM-MVD approach for the development of BIM views (see Figure 2), bringing together

modellers, software developers and end users.

The descriptive filtering method is obviously a filtering on schema level, while the prescriptive

filtering can be classified as either being based on class level, object level or on reasoning.

Filtering on schema level describes the process of reducing the content of a model based on a

predefined subschema which determines the informational content of the resulting partial model.

This is in general realized with a solely descriptive approach where all required transformations

are specified in advance. The suggested IfcDoc approach (see subsection 4.1) provides such

functionality.

Filtering on class level covers the reduction of a model content based on constraints regarding

properties and relationships which are explicitly defined in the model schema. In contrast to

schema level filtering the class level filtering is performed at runtime, by applying the prescriptive

filtering functions in the context of a specific task. Unlike schema level filtering the class level

filtering can be combined with the two following prescriptive filtering mechanisms.


Version 1.0

/72


Figure 2: High level schema of the overall process of development, implementation and use of model views and related filtering types (based on Katranuschkov et al. 2010)

Object (or instance) level filtering allows examining specific properties of individual objects. The

result is at the same time a reduced model. The querying methods needed are more complex

than those of class level filtering resulting in a higher flexibility and better consideration of a given

task context.

The filtering on reasoning level utilises algorithmic and knowledge-based functions which cannot

be directly deduced from the model structure. Nevertheless they are associated with the model

semantic. An example is the derivation of space boundaries on various levels of detail from

defined spaces and building elements in IFC. Other examples are the extraction and re-grouping

of shear walls from all wall elements or the definition of thermal zones.

Independent from the utilised filtering methods the purpose of the filtering process is always the

same: supporting the creation of suitable model views for specific applications, tasks or

engineering system contexts.

To be more specific in addition to an appropriate sub-view of BIM, the eeE scenario requires for

example the use of climate or ESIM models and detailed cost data. Individual applications or

business tasks often involve simpler or even ad-hoc model views, but they may also require

Multimodel queries to generate the needed input data properly. In the following sections these

different model view types are examined with regard to the focused filtering tasks.


Version 1.0

/72


3 Model views

3.1 Model view types

3.1.1 Static model view

Generating a domain model view means to reduce the information content of an overall building

model in accordance with a standardized, domain-specific IFC subschema specification. Such a

subschema specification determines the required information for a specific information exchange

scenario with regard to a specific AEC process, for example the information handover from

architecture to building services engineering or from construction to facility management.

The descriptive technologies (presented in section 4) utilise filtering on schema level. Thus, an

overall BIM schema can be reduced to valid subschemas. The outcome of the filtering process is a

partial model, valid to a certain BIM schema. So filtering on schema level represents the first step

within the proposed overall filtering process. It provides the model data that can be further

processed in order to generate ad-hoc, multimodel or engineering system model views.

3.1.2 Dynamic/ad-hoc model views

The ad-hoc model view method is focused on the utilisation of BIM data in the context of a

specific task where only a subset of the model is of interest or context dependent reasoning has

to be applied. This may include object selection, aggregation and transformation as well as model

querying in a more general way with regard to geometrical, topological or semantical issues for

various application dependent contexts.

Geometrical information is on the one hand needed by non CAD applications – like those of the

construction or facility management domain – that have to deal with the geometry of BIM

objects. On the other hand geometrical information is needed to obtain features of objects that

are not explicitly provided in the model, like global coordinates and axes definitions needed for

the energy simulations of a building’s facade.

Topological concepts for spatial querying and reasoning provide powerful functionality for the

exploring and evaluation of building models in a topological context, for example if the adjacency

of spaces is required for thermal energy analysis.

Semantic queries can be very useful for ad-hoc examination of specific issues of interest, like

extracting walls or windows of a specific material construction type. In short, ad-hoc model views

address the needs of applications that are using non-BIM concepts. In all such cases in addition to

class and object level filtering, appropriate mapping and transformation functionality is needed.

3.2 Multimodel views

Multimodel views are related to use cases similar to the generation of ad-hoc model views. At the

same time, they are not restricted to the information contained within a BIM. The multimodel

approach reaches further to overcome the limitations of an encompassing BIM model by linking

the information from different models with varying data schemata and integrating them into a

single resulting model view. This concept, initially introduced in the German research project


Version 1.0

/72


Mefisto (Fuchs et al. 2011) for the support of the information exchange in private-public

partnership construction projects, is particularly dedicated to the integration of non BIM data

provided on the basis of standard or quasi-standard data models like GAEB-XML, with no further

expansion of the BIM. Thus, the addressed domain/elementary models can be managed

separately without the need for additional mapping between an extended BIM and the native

schemata (Liebich and Katranuschkov 2010).

The methodology for the Multimodel view creation is analogue to that applied for single model

data and has to be supported by the same filtering methods. Thus, Multimodel views can be

generated with prescriptive, descriptive or combined methods. One model might for example be

generated based on a schema definition while the second model which is part of the Multimodel

might be the result of a prescriptive query method.

3.3 Model Filtering Technologies in eeE

This subchapter provides an overview of the utilized technologies and their allocation within the

process of generating model views and filtering types which is depicted in Figure 3.

The technologies themselves are described in detail in the following chapters.

Figure 3: High level schema of the overall process of development, implementation and use of model views and related filtering types, with allocation of the filtering technologies utilised in eeE

In eeE descriptive filtering methods are realized via IfcDoc – a tool developed by buildingSMART

International1 to improve the consistent and machine-interpretable definition of Model View

Definitions (MVDs) as subsets of the IFC specification.

The XMLToFilterConverter presented in chapter 4.2 enables the creation of FilterIFC files from

XML based schema definitions. Thus, it is also possible to use FilterIFC for descriptive filtering.

The prescriptive filtering technologies utilized on server side by service developers are those of

the IFC-API described in chapter 5. In addition the FilterIFC tool described in chapter 6 can be used

1 http://buildingsmart.org/


Version 1.0

/72


on server side. It is based on BIMfit which is more of a client side filter library but can also be used

on server side as foundation for the FilterIFC tool. BIMfit itself is presented in chapter 7.3.

The filtering described here is limited to IFC files. In addition, Multimodel filtering is the

combination of IFC filtering with the filtering of other elementary models for example XML/RDF-

based ESIM-files. This means that for each elementary model its native filtering application is used

(e.g. filter IFC via BIMfit, filter ESIM via Ontology Access Service (OAS)) and that the Multimodel

filtering is achieved by a splitting of the queries and a combination of the individual results as

depicted in Figure 4.

Figure 4: Schematic presentation of a Filter request that involves data from various models


Version 1.0

/72


4 Descriptive filtering

4.1 IfcDoc

In eeE D1.3 “Interoperability and collaboration requirements”(Calleja-Rodríguez&Guruz 2014) the

authors describe the intention to have a separate model view for each design phase of eeE

(Urban, Early and Detailed Design) in order to satisfy occurring exchange requirements. The

following steps are performed to define those eeE model views:

Use IFC baseline to access the corresponding IFC4 schema

Create model views and exchanges

Create or reuse concept templates

Use concept templates to define model views content

Export .mvdxml files and generate MVD documentation

IfcDoc (BuildingSMART 2014) was chosen for the MVD generation because it allows reusing

existing model view definitions or concept templates and thereby speeds up the process of

generating new MVDs. The utilisation of IfcDoc for the creation of MVDs based on exchange

requirements (ERs) is presented in eeE D1.3 (Calleja-Rodríguez&Guruz 2014). So are the resulting

MVDs. eeE D5.2 “Interoperability System” presents amongst others the utilisation of IfcDoc for

model checking as well as IfcDoc-based concepts for the creation of Multimodel View definitions.

The specific elaboration of those concepts will then be part of the upcoming eeE D5.3 “Ontology

System”.

Figure 5: IfcDoc in the eeE workflow and its presentation in the Deliverables 1.3, 5.2 and the

upcoming Deliverable 5.3 [based on eeE D5.2 “Interoperability System” (Stenzel&Kadolsky 2016)]


Version 1.0

/72


4.2 XmlToFilterConverter

The checking functionality defines the basis for an efficient test of any IFC file against a given

MVD. The XmlToFilterConverter tool (Pirnbaum 2016) can be used to create the appropriate filter

files. The XmlToFilterConverter tool enables the user to convert XML documents into the FilterIFC

language. It supports the conversion of XML documents created according to the mvdXML

schema. After the conversion, the resulting FilterIFC specifications can be executed using the

FilterIFC tool. The parsing of all input mvdXML files is based on the official XSD schema (Chipman

2012). As a first step, the input file is validated using the XSD schema. If the validation was

successful, all elements are converted to the FilterIFC language. The mapping process depends on

the content of the input mvdXML file. If the file contains a <View> element the conversion will be

controlled by that, if the file does not contain such an element, all elements will be converted

directly. The mvdXML files are used to check IFC files on several aspects, e.g. if specific IFC

elements are contained or if the values of attributes of these are correct. So the basic FilterIFC

functionality is checking. But since the mvdXML specification does not clearly limit the

functionality to checking the XmlToFilterConverter tool supports filtering as well.

The XmlToFilterConverter is a command line tool which can be called with the following syntax:

$ java –jar XmlToFilterConverter.jar < input-file >

< output-file >

[ -filter ]

The parameters must be in the specified order. Their meaning is described in Table 1.

Table 1: Description of the syntax for XmlToFilterConverter

Parameter Description Declaration

< input-file > The mvdXML or vpl file to convert. obligatory

< output-file > Path and name of resulting file (e.g. /path/to/out). obligatory

[ -filter ] In case of converting an mvdXML file it is possible to activate this flag to convert the rules to filter operations instead of checks.

voluntary


Version 1.0

/72


5 IFC-API

IFC-API is the interface of the EDM Model Access Service (MAS). The basic IFC services allow

element access inside IFC model(s). As long as the GUIDs (UUIDs, Global IDs) are unique across the

entire scope, the “model” can in principle be a collection of models (Multimodel).

The specification of the services is based on REST/JSON service access, although services by

themselves can be used in other contexts as well (internal server application programs, server

queries, SOAP/XML…).

The services are defined as simple as possible, with the number of services kept as low as

possible. The aim is to provide a basic set of services for realizing most common and necessary

functions. Thus, more complex filtering tasks against an IFC (Multi-)model are reserved for the

prescriptive filtering methods.

Detailed service definitions for the IFC-API are given in 8.1 in the Appendix. Usage Examples can

be found in 8.2.

5.1 Principles

In general a REST-API call can be separated into the parts listed in Table 2.

Table 2: Composition of a REST-API call

Operation HTTP operation GET, POST, PUT, DELETE

URL Endpoint

Typically separated into a server/service part and a data location part:

URL: http://bim-api.xyz/e3services/myapi/v03/model/abc123/spatial

Server part: http://bim-api.xyz/

Service part: e3services/myapi/v03

Data location part: /model/abc123/spatial

URL Arguments

(query arguments)

URL: http://bim-api.xyz/e3services/myapi/v03?service=login&name=arne

There are two URL arguments : {service=login, name=arne}

Body argument(s) Often a JSON object, but can be almost anything, like binary “files”.


Version 1.0

/72


Some (single string) arguments can be given as part of the URL, as URL argument or in JSON body

achieving the same effect. That is, the following requests are functionally identical:

Argument as part of the URL: http://example.com/e3services/ifcmodel/1223432

Argument as URL argument: http://example.com/e3services/ifcmodel?ifcmodel_id=122343

Argument in the request body http://example.com/e3services/ifcmodel body:{“ifcmodel_id”:”122343”}

If an argument is specified in multiple places, the following rules apply (mostly):

Argument as part of the URL overrides URL argument

Argument as URL argument overrides argument in the JSON body

The IFC-API URL

For IFC-API the URL is composed as follows:

http://example.com/e3services/ifc-api/0.5/<service URL>

The service URL is composed of a sequence of [reserved word | GUID | name] characterized as

follows:

A reserved word (keyword) identifies a resource type like model, building, property – in short most of the reserved words correspond to IFC entity names, or to IFC_API defined terms. An example of the latter is “ifcmodel” which does not exist in IFC schema.

A GUID is an identifier corresponding to one of the two most used formats for Universally Unique Identifiers (UUIDs):

o FMT-22 as specified in IFC schema: “DgrBQfGf3SuAKkT8DURCG”

o FMT-40 as hex string: “de305d54-75b4-431b-adb2-eb6b9e546014”

Anything that is not recognized as a keyword or a GUID is assumed to be a name.

A sequence of a keyword followed by a GUID is assumed to identify a single “resource”. Example:

…/ifcmodel/122343 identifies the ifcmodel with id 122343.

In some cases, a resource can be identified by a name. For example, a property has no GUID (IFC

GlobalId) so it must be identified as follows:

…/ifcmodel/122343/ifcpropertyset/99887/ifcproperty/myProperty

Which means: The property with name myProperty in the property set with globalid 99887 in the

model with id 122343.

Identifying multiple objects

URL-based identification is limited to single objects. To identify objects in for example two models

at once, the corresponding GUIDs must be supplied as an array, and the only suitable place for

this is in the JSON body, as can be seen in the following example:

2 Please note that the ID 122343 is not a legal ID format, but a simplification to enhance the readability in the context of this deliverable.


Version 1.0

/72


URL: /ifcmodel/ifcpropertyset/99887/ifcproperty/myProperty

Body: [{“ifcmodel_id”:”122343”}, {“ifcmodel_id”:”67877”}]

Which means: The property with name myProperty in the property set with globalid 99887 in the

two models with id 122343 and 67877.

Error handling

If the service invocation fails, an ERROR 500 is returned with the error code and the

corresponding text.

5.2 Filter services

In case of the EDM server a filter is seen as a definition of a subset of a model (or models) – a

partial model. There is a multitude of ways to define filters in IFC-API, some examples are:

By discipline/domain

By spatial structure

By system/ownership

Defined by MVD

By physical location like inside bounding box or similar

Applying a filter can be seen as an EXTRACT operation - the EXTRACT services retrieve partial

information from a model, for example energy system data only. The result is presented as data

according to the model schema (IFC). The underlying definition of the subset is represented by an

endpoint; typical endpoints represent physical objects like buildings or stories, disciplines or

systems.

Extract endpoints are inherent properties of the model itself. Some endpoints are obvious and

always available, like spatial endpoints project, site, building, storey and space. Some may or may

not be available depending on how the IFC model is populated, like discipline, domain and

ownership endpoints. Some have to de defined or applied from outside, like physical location

filters. To some degree available extract endpoints can be maintained with the filter maintenance

services.

In addition to filter maintenance the usage of the filters must of course be enabled. The

corresponding services are labelled filter services.

As explained in eeE D4.4 “Multi-Model Manipulation” (Tøn&Mosch 2016):

A single model service returns data from one model at a time

A combined model service returns data from several models in a single operation.

An important reason to handle filters as instances in their own right is to enable the same filter to

be applied on several data sources at once (combined service) and easily apply the same filter at

separate points in time.


Version 1.0

/72


Filter attributes

Attributes for filters include:

Filter GUID (GlobalID)

Filter name

Filter type

o Filter type is a single string, which is either in the list of “standard” services, or a custom service. See section <TODO> for examples.

o Standard list of services: Domain : “ifcdomain” Spatial : “ifcspatialobject” Topological: “IfcSpatialZone” Geographical: “ifcboundingbox” Ownership: “ifcownerhistory” MVD: “ifcmodelviewdefinition”

Filter description

Book-keeping metadata

o Author o Version o CreationDate o ModifiedDate

In addition, any number of filter specific attributes can be present. This will vary from filter to

filter.

Filter (extract endpoint) URLs

The filter type will in many cases fit nice as a part of service URL as shown in examples below:

Get a system

Get a spatial object

Get a spatial object

Get view according to an MVD specification

All the {xxx_id} above are GUIDs, which means the type part of the URL is superfluous; the

following two URLs will point to the same resource:

GET https://{service-url}/multimodels/12324/extract/ifcsystem/{system_id}

GET https://{service-url}/multimodels/12324/extract/ifcspatialobject/{object_id}

GET https://{service-url}/multimodels/12324/extract/ifcspatialobject/{object_id}

GET https://{service-url}/multimodels/12324/extract/ifcmodelviewdefinition/{mvd_id}


Version 1.0

/72


Filter type grouping

When it comes to types of filters these fall into (at least) three groups:

1) Filters that are defined more or less by the properties of the IFC object. Example: extract a single storey from a multi-storey building.

2) Filters that require external data in addition to the IFC data. Example: extract data for objects inside a bounding box

3) Filters that are defined by a custom query. These filters will be server implementation dependent, as some form of query language will have to be used for defining the filter. Example: extract data for objects assigned to a particular rental contract in the EDMmodelServer.

Supplying arguments to a filter

Some filters, such as a bounding box filter, require additional data that needs to be supplied.

Singular arguments can be supplied as URL arguments ({URL}?arg1=val1&arg2=val2,….,) but in

general arguments are supplied in a JSON request body as shown in the following:

Example: get thermal boundaries for a set of IFC spaces

Single-model versus multi-model usage

A multi model scenario for filtering could look like this:

Retrieve energy system from model Alternative-A and combine it with BACS system from model Alternative-B

Now, this is actually applying two extract and one merge operation

Retrieve energy system from model Alternative-A

Retrieve BACS system from model Alternative-B

Combine the two partials models to a new model using merge operation (Tøn&Mosch 2016)

GET https://{service-url}/multimodels/12324/extract/ifcmodelviewdefinition/{mvd_id}

GET https://{service-url}/multimodels/12324/extract/{mvd_id}

GET https://{service-url}/multimodels/12324/extract/{custom_filter_id}

Request:

{ “ifcspace”:[

{“name”:”R201”},

{“name”:”R202”},

{“name”:”R203”},

]

“ifctype”:”thermal-boundaries”

}


Version 1.0

/72


5.3 List of services

Refer to the IFC-API documentation (IFC-API 2016) for a complete list and for details. An overview

is given in the following.

NOTE: To be able to uniquely identify a filter they are equipped with “GlobalID” attribute in the

way as an IFC object.

List available filters/Service Endpoints

The service will return a list of available filter services for a model. Only a few standard fields from

all the possible fields (attributes) for each service will be returned, to enable a table presentation

and avoid data overflow. Typically, the attributes are:

Filter GUID (GlobalID)

Filter name

Filter type

Filter description

Create filter

One particular form of filter is possible to define generally – a combination of a predefined filter

and arguments, like applying domain “BACS” to the predefined “Domain Filter” yielding a new

filter “BACS Domain Filter”.

Other forms of this service will probably be implementation dependent, as the most common not

predefined filters will be “custom filters” defined by the underlying server query language.

Retrieve filter meta-data: detailed data about the filter itself

The available meta-data/information about a filter will vary according to the filter characteristics.

This service will retrieve all available meta-data fields for the service.

Update filter

Update a filter can basically be either of these:

Update filter meta-data

Update definition of the filter itself

The latter operation is only relevant for filters that are not predefined.

Delete filter

Only those filters that are not predefined can be deleted.

Extract data from model according to filter

This is the single operation needed for applying a filter. Depending on the filter, all from no

arguments to a complex structure argument has to be supplied.


Version 1.0

/72


6 FilterIFC

The filtering functionality specified and implemented in the BIMfit library (see subchapter

7.3Fehler! Verweisquelle konnte nicht gefunden werden.) can be applied using the FilterIFC

batch processing tool (Pirnbaum, About FilterIFC, 2015). FilterIFC filters and manipulates IFC files

referring to the basic functions defined in BIMfit. It offers the possibility to extract only the

required information as well as creating new building elements including all extra information

about it. Additionally the tool is able to check IFC files and results of other commands of FilterIFC

to ensure accordance to the expected content.

FilterIFC has to be started from command line. Three obligatory input parameters have to be

specified:

(1) input file … must be a valid file with .IFC extension. The validity is checked while parsing the file. If it fails the program will stop running.

(2) filter file … contains all rules which shall be applied on the input file. The file must fulfil the required specification (Pirnbaum, About FilterIFC, 2015).

(3) output file … contains all calculated results. Possible output formats are the standard IFC format or the JSON format.

In addition to these obligatory arguments an optional geometry parameter can be specified and

used in accordance with the description in Table 3.

Table 3: The geometry flag

Specifier Effect Output

on Default value. With geometry off, the resulting file only contains the

entities satisfying the filters in the filter file without representation

.ifc

off With geometry on, the resulting file contains the entities satisfying the

filters in the filter file and also the representation to them

.ifc

tri With geometry tri, the resulting file contains the entities satisfying the

filters in the filter file in xyz-coordinates

.json

To increase the efficiency, the FilterIFC tool offers macros. Those code snippets are defined before

usage and can store any text or operation even partly. When the macro is used later, the stored

text is inserted at its position. It is possible to apply filters on a result of another filter, that way

enabling sub-filtering or import complete filter files.


Version 1.0

/72


Filter specifications comply with the following syntax which is explained in Table 4:

~filter - <type | guid >

<< specifier (s) … >

| exclude < specifier (s) … >>

[ - recursive ]

[ - tuid ]

Table 4: Description of the filter syntax

Parameter Description Declaration

-< type | guid > Determines whether the entities shall be filtered by the type (based on the Ifc type) or by the global id

obligatory

< specifier (s) … > Specifiers for filter rule. If using as type filter, use the naming from (Model Support Crew of International Alliance for Interoperability 2007)/(buildingSmart 2015) (e.g. "Ifcwall"), otherwise use the global id. Several specifiers can be combined; the single specifiers are separated by one space.

either this or excluded specifiers obligatory

Exclude < specifier (s) …>

Specifiers for filter rule. When using the exclude key word, all entities determined by the specifiers are removed from the underlying data set in the result.

either this or included specifiers obligatory

[-recursive] Optional parameter. If used, the resulting file will contain not only the entities specified previously, but also all entities contained by these excluding the representation. (The representation will be added by the geometry flag on command line)

voluntary

[ -tuid <specifier>]

A temporal user id for the filter. This gives the possibility to use the filter result in other operations where applicable

voluntary

The resulting filter file can contain many different filter queries and constitutes the result of all

specified filter for a collected query. The following code snippet is a simple example of the filter

usage.


Version 1.0

/72


Conditions

In Addition to the simple filtering procedure it is possible to further limit the result via conditions.

Therefore, where is attached to the filter completed by the condition. For all entities, complying

with the simple filter the specified condition is checked. Only those results that pass the check will

be included in the resulting data set. The expanded syntax is:

~filter … [where < condition (s) … >]

The following filter conditions can be specified:

Attribute

Material

Path

Property

Quantity

Relation

Comparison.

The following code snippet is an example of filtering for material as part of a complete filter file.

The next code snippet shows the filtering syntax in the case of property filtering. A filter file can

contain many different filter queries respectively.

01: #type filter to get all walls of an ifc file:

02: ~filter -type "Ifcwall"

03: #instance filter to get entity with global id 3x94dj40kd8

04: ~filter -guid "3x94dj40kd8"

05: #getting entities of several types

06: ~filter -type "Ifcwall" "Ifcwindow" "Ifcspace"

07: #type filter including also sub entities

08: ~filter -type "Ifcwall" -recursive

09: #type filter excluding all walls

10: ~filter -type exclude "Ifcwall"

11: #type filter excluding entitiy with id "3k3jdkds"

12: ~filter -guid exclude "3k3jdkds"

13: #setting the tuid

14: ~filter -type "Ifcwall" -tuid "123abc"

01: #filter all walls made of concrete

02: ~filter -type "Ifcwall" -where material "concrete"


Version 1.0

/72


Checking

In addition to the filter functionality the FilterIFC tool offers the possibility to check whether a

data set contains entities with specific characteristics. Checks have no influence on the filter

result, however if a check fails the program will exit without a result. An error message will then

be shown in the terminal.

Corresponding to the filter specification, several checks can be performed, as listed in the

following:

Entity

Attribute

Material

Property

Path

Quantity

Relation

Aggregation functions.

01: # get all internal Ifcwalls, internal is expressed by value 1

corresponding to jsdai documentation

02: ~filter -type "Ifcwall" -where property "Pset_WallCommon"

"IsExternal" EQUALS "1"

03: # filter all Ifcroot entities having the specified property set assigned

04: filter -type "Ifcroot" -where property "Pset_WallCommon"

05: # filtering with unknown proeprty set

06: filter -type "Ifcroot" -where property "*" "LoadBearing" EQUALS "1"


Version 1.0

/72


7 A BIM Filter Toolbox

7.1 The Layer Model Approach

The batch processing tool FilterIFC (presented in section 6) offers a descriptive method for

generating model subschemas and a respective model views. Nevertheless an additional generic

support for the proposed prescriptive filtering methods is required in order to provide flexibility

and allow for a better consideration of the specific task or application context. The filter

framework described in this chapter was created with the intention to provide the elementary

functionality needed for the generation of various BIM-based model views with regard to

different domain and application contexts. It constitutes a consistent and formalized basis for the

runtime application of model filtering and transformation operations and is built on the concept

of modular base filter functions providing adaptable and reusable building blocks for the model

view generation tasks. This includes especially filtering on class and object level and the related

dynamic generation of ad-hoc and Multimodel views. The filter framework is therefore

complementary to the static filtering on schema level for domain model view generation.

A set of basic filter functions is the foundation of the framework for the definition and realisation

of more complex model filters and transformation operations. Those basic functions can be used

by software developers to create tailor-made extended filter operations for specific contexts and

the targeted engineering tasks.

This can include pre-processing of the model data for advanced reasoning or analysis tasks like

spatial reasoning (Borrmann & Rank 2009) or structural analysis (Romberg et al. 2004), as well as

for model checking and data reduction, simplification, translation and interpretation issues to

achieve appropriate data transformations in energy aware design (Bazjanac & Kiviniemi 2007).

The idea behind the modular filter functions is to break down highly specialised filter functions

into several more general sub functions, that take place on different layers of applications an can

be reused for the creation of other complex filter functions.

To focus the discussion, consider the following example request: Retrieve the volume of all

columns made of a certain concrete type located in the first casting segment of the slab in the 3rd

building storey. To create the corresponding ad-hoc model view it is necessary to identify and

select all column objects that fulfil the given constraints (concrete type, located on 3rd floor level

and the first casting segment). Therefore we need to calculate the global position of all column

objects in terms of co-ordinates related to the global project positioning context. This information

allows us to decide whether a column object is located in the given casting segment or not.

Furthermore we need a concept of a casting segment that matches the requirements of the

application model to provide the geometrical boundaries, and a correct mapping to the

requesting software application. Finally, the volume of every selected column has to be extracted

and calculated if it is not explicitly defined in the underlying data model.

Divided into several sub-functions, the overall filter process can be described as an ordered

execution of a finite set of filter functions. The resulting ad-hoc model view is produced via

stepwise reduction and transformation of the given source model data (by evaluating the object

types, relationships and attributes) and additional computational operations working on the


Version 1.0

/72


attribute values. Thus, each needed sub-function can be assigned to a certain area of application.

The calculation of global (or relative) coordinates or building element volumes are for example

assumed to be helpful for various filter tasks and can thus be seen as neutral core operations that

are independent from a specific domain or application context. In contrast, a casting segment and

its use in filter tasks are a specific issue in the construction domain and are probably not needed

in other domains.

According to the application area the filter functions are organized on three hierarchical layers: (1)

neutral layer, (2) domain layer and (3) application layer (Figure 6A).

Figure 6: The schematic view of the suggested generic filter framework. (A) Layer overview with resulting model views according to layer: Ax,x = application model views, Dx = domain model views; (B) Example Scope of required filter functionality for a specific application Am.

The Neutral Layer consists of a set of predefined base functions providing domain and application

independent resources for the definition of subordinate filter operations on domain and

application level. The base functions enable consistent model access by structural and semantic

mapping of the higher order filter operations to the underlying data model. They enable

identifying, selecting, calculating and extracting the data (objects, attribute, relations etc.) needed

for a specific filter task which is formulated at the application layer (by the end user or the

according application software). In addition, the base functions have to establish several data

transformation and manipulation operations in order to provide fundamental algebraic and

arithmetic functionality as well as advanced data manipulation that is commonly used by several

domains. This covers for example coordinate transformation, the calculation of geometrical or

physical element properties and the geometrical representation transformations.

The Domain Layer covers extended filtering functionality for specific engineering domains. The

according filter operations are specialized for the information requirements of the domain, in our

case energy aware design. Every filter operation consists of a set of base functions defined in the

Neutral Layer and of rules for their combination and execution. The filter operations in the


Version 1.0

/72


Domain Layer are to be defined by end users/software developers. They compose a filter

operation by take a set of neutral base functions and adjust it for their specific, domain-

dependent needs and the envisaged filter tasks in the domain. This task can be performed in

different ways which require no deeper inside knowledge about the underlying data model that is

hidden by the Neutral Layer. The filter operations on the Domain Layer are application

independent and can be utilised by different software applications assigned to the specific

domain. Therefore, the Domain Layer integrates all filter and query functionality that uses

concepts and information requirements commonly shared by different software applications. In

order to implement certain filter functionality in a specific application, such as TRANSYS TUD or

CFD on the eeE platform, the software developer may refer to the appropriate filter operations

defined on the Domain Layer by modifying and adjusting them to match the specific application

requirements. On that level, the adopted filter operation will be suitable only for this specific

application on the Application Layer. Following that approach, an application Am may adopt a

subset of the filter operations defined on the Domain Layer that can use a subset of the base

functions defined on the Neutral Layer for their part (Figure 6B). Thus, the suggested generic filter

framework is focused on the definition of base functions on the Neutral Layer and rules for their

combination, that are generically applicable for different domains, as well as on higher order filter

operations that can be generated and configured on demand for a specific domain.

7.2 Base Functions

In the following the base functions of the neutral layer will be further differentiated. There are

three types of base functions that are hierarchically built upon each other as shown in Figure 7.

Figure 7: Structure and function types of the neutral layer with associated application area and definition range

The most general type is the meta function type. It provides fundamental functionality related to

the modelling paradigm, which for eeE is EXPRESS (ISO 10303-11:2004). The second type covers

the core functions. It is used to specialise the generic base functions with regard to a specific data


Version 1.0

/72


model (for eeE IFC2x3 or IFC4). The third type sums up the algorithmic and reasoning functions

that provide the functionality needed for data transformations which are not directly related to

the model’s data structure, but are described indirectly by the model’s semantic and require

additional knowledge processing. Apparently simple requests like for the dimensions of, distances

between or the volume of elements triggers transformations that rely on this type of functions.

In general, this classification is applicable for a variety of data models. It provides a unified and

consistent access to those models needed for the generation of different (Multi-)model views.

Meta functions

The meta functions constitute the fundamental component of the generic filter framework. They

are used to map semantical concepts of a specific data model to the underlying modelling

concepts. For the IFC data model the modelling concepts are those of the EXPRESS data modelling

language. The scope of the meta functions is to enable object selection on language level, based

on various general selection criteria like object type, object, properties, object references,

constraints involving multiple object properties as well as object reduction. Concepts like

inheritance have to be supported as well as complex data types and additional generic data

processing functionality.

According to their purpose the generic base functions can be conceptually differentiated:

Select (get), for object selection, attributes or references based on various selection criteria;

Project, for information reduction of selected objects;

Set operations, for definition/execution of theoretical operations (e. g. union, intersection)

Support operations, providing additional needed functionality.

These sub types of the meta functions require different types of input parameters and return a

result depending on their type and specific objective. A single meta function can be defined on

type or object level and processes either a functional mapping or an assertion evaluation.

Core functions

The core filtering functions are based on the semantics of a specific data model likeIFC4. They

allow specialising the meta functions according to the related semantic concepts. The core

functions are limited to work on the information that is defined explicitly in the data model in

order to avoid ambivalent data interpretation. Each core function represents a specific and

ordered combination of a finite set of instantiated meta base functions. For example the simple

core function getBuildingStoreys returns the object IDs of all building storey objects contained in a

given object set. Therefore the generic base function getEntitiesOf is utilised. It requires an object

set and a specific object type as input parameter. There are also higher order core functions like

getBuildingElementsInStorey. This function returns the object IDs of the specified building

elements located in a given building or storey. It represents a combination of several instantiated

meta and core functions3, concatenated with select and join operators. The core functions are the

3 These are, specifically, getEntitiesOf (as above) but also getEntitiesWithAttributeValue,

getElementsForSpatialStructure and getSpacesInStorey.


Version 1.0

/72


foundation for the mapping functionality that is needed to assign the concepts of filter functions

and operations defined on the superior layers to the concepts of a specific underlying data model.

The mapping specification itself has to be defined by composing the desired transformation

function or higher order filter operation from core functions. The later can be combined among

themselves to create new functions.

Extended Reasoning functions

The reasoning functions support the filtering on class and object level. They cover the required

data pre- and post-processing for matching information requirements of specific filter operations.

Therefore information defined implicitly in the underlying data model is accessed. This

functionality is an important prerequisite for advanced model filtering and querying. It enables

functional mapping between additional (e.g. geometrical, topological and physical) concepts

jointly used by several domains or applications and the related concepts of the data model the

transformation function operates on. Reasoning functions are defined as combination of a set of

meta and core functions and additional reasoning operations. The later which may be defined

separately, independent from a specific mapping case, perform additional operations on the data

retrieved by the former.

Reasoning functions can be combined with other reasoning or additional core functions to realise

higher order filter operations. The reasoning functions on the Neutral Layer cover mainly

functional mapping for geometrical and semantical issues. Although also addressed, topological

issues, e.g. the identification of adjacent or exterior spaces and building elements are harder to

deal with. The according reasoning functions are complex since topology issues are only sparsely

supported by current BIM-CAD tools. They therefore necessitate high level interpretation of the

geometric modelling concepts used in the IFC data model as well as advanced algorithmic data

transformation operations. Predefined core or other reasoning functions that enable the access to

the required information resources contained in the IFC data model can be used supportively.

Conclusion

Some reasoning functions may fulfil a purpose that closely resembles that of some core functions.

Both function types have different approaches for solving queries: The core functions solve

queries by simply extracting explicit information, whereas the reasoning functions extract implicit

information by comparing, weighting and general processing of model data. Reasoning algorithms

can be applicable where core functions are not able to extract information. For example the query

to retrieve all building elements of a storey could be solved by both function types: The core

functions can only extract this information if the elements have an explicitly defined attribute that

assigns them to a storey. The reasoning functions extract this information for example by

checking and processing geometric information. However this applicability comes with the

expense of higher complexity and therefore implies a higher computational effort. That is why it is

beneficial to employ core functions instead of reasoning functions wherever possible. On the

other hand reasoning functions can be employed to check the validity of explicit information

within the building model.


Version 1.0

/72


7.3 Technical Overview

Based on the concept of modular filter functions the BIM filter and integration toolbox (BIMfit)

was developed as reference implementation for a set of base functions from the meta, core and

the extended reasoning level. The toolbox enables fast and simple creation of higher order filter

operations that fit certain domain or task specific information requirements. It offers a set of tools

for model querying, object selection and user defined constraint checking that is readily

extendable by new filter functions on core and reasoning level, or application filter operations in

any complexity utilizing the existing base functions. BIMfit is currently available as a stand-alone

web-based application, as JAVA archive (jar) and as web service defined via a WSDL service

description under the AGPL license.

For the parsing of EXPRESS based models in SPF data format (ISO 10303-21:2002) BIMfit uses the

JSDAI-API (www.jsdai.net). The Open IFC Tools (http://www.openifctools.org), which are based on

another Java model4, are used for the visualisation of the IFC filter results.

The BIMfit implementation can read and process any EXPRESS based model data of the neutral

layer. On the core and reasoning level model data conforming to version 4 of the IFC-Schema

(buildingSMART 2015) are supported.

For a better understanding of the framework, consider the task of filtering the building envelope

as an example. The goal could be a detailed examination of the influence of airflow on a building

taking advantage of an advanced CFD-based analysis method. The according filtering process

consists of two sequentially executed steps:

(4) Applying the FilterIFC-based descriptive approach to generate the aerodynamic analysis domain model view

(5) Applying a filter operation composed from filter functions defined in the generic filter framework in order to identify all building elements which contribute to the aerodynamic effective building surface.

The first step reduces the architectural BIM to a sub model containing only the objects required

for the aerodynamic analysis. Filtering on schema level is used to establish the engineering system

model view.

In order to identify and select the building envelope elements, the domain specific filter operation

processed in the second step applies the following sub-steps:

(2.1) identify all spaces located on the exterior,

(2.2) identify all building elements related to these spaces,

(2.3) reduce the resulting set of building elements by differentiating between interior and exterior parts of the overall space boundary,

(2.4) validate the final result set by evaluating the boundary type between adjacent exterior and interior spaces.

One of the filter operations which are used by many superior overall filter operations is the

identification of the exact adjacency relationships of the spaces (rooms) in the building. These

adjacency relationships are necessary criteria for the evaluation of the spatial placement of every

4 This necessitates the mapping between the internal JSDAI model and the Open IFC Tools model.


Version 1.0

/72


single space relative to the building exterior. This particular filter operation is composed from the

following filter operations:

Selection of all spaces of the given building,

o Instance selection by object type,

Calculation of the spaces’ footprints using their global positioning context,

- Selection of the spaces’ shape representation and the geometrical representation items that define the footprints,

- Normalizing the representation items by coordinate transformation with regard to the global positioning context,

Calculation of intersecting areas (basically a paired 2D comparison of each space with all other spaces) and final determining of the adjacency on the basis of the result.

The overall structure of the filter framework is depicted in Figure 8 including differentiating

between definitional and implementation parts.

An exemplary set of BIMfit filter functions can be found in 8.2, 8.4 and 8.5 in the Appendix. There

a short synopsis of the function’s purpose, the required input, the produced output, the

dependences or relationships to other functions, and in most cases a short code example in Java

are provided. 8.2 covers meta filtering functions while 8.4 presents core filter functions that

address specifically the IFC model schema on semantic level. The core filter functions are ordered

into three groups: (1) semantic filtering functions for IFC objects, (2) model checking functions

and (3) I/O support functions. Finally 8.5 provides an insight how more complex filtering and

model management operations can be achieved with the help of BIMfit.

Figure 8: Overview of the overall structure of the BIMfit framework


Version 1.0

/72


7.4 New Functions in the eeE context

Through the eeE methodology and the corresponding framework inter-domain and inter-

disciplinary filter operations become necessary. For instance during the preparation of an energy

simulation and during the actual simulation run it is mandatory to extract information out of the

architectural model as well as e.g. the HVAC model. Additionally the extended filter operations

become vital when linking or highlighting results of the simulation or to illustrate and identify

dependencies between elements from different domains, i.e. to illustrate wall breakthrough that

become necessary when implanting HVAC-systems. Furthermore the filter operation need to

support queries that are tailored to identify and analyse systems as it is important to be able to

extract a specific system on its own as well as to analyse the interactions the system has with its

surroundings.

Generally extended filter functions in eeE can be divided into 3 categories:

1. IFC Filter functions:

With the IFC version IFC4 additional domain specific data schemas have been added. This

makes it possible to save and include domain information of the HVAC and BACS domains

directly within the IFC file. Therefore it becomes important to broaden the available filter

functionality (i.e. BIMfit) on IFC to be able to interpret and use the additions. This section will

mainly describe these kinds of filter functions and a more in-depth analysis of this kind of

extension can be found in the sections 7.4.1 – 7.4.3.

2. Proprietary Filter functions:

These functions are filter functions that are only applicable for specific proprietary software

and may become available due to the availability of additional data (i.e. climate data,

occupancy data, etc.). However these filter functions may only be applicable within the

proprietary software, if an export function is not supported. This may make it necessary to

manually process the results. Either way the results will then be processed in the context of

the Multimodel by using the before mentioned Multimodel filter methods.

3. Multimodel functions:

The aforementioned extended filter functions provide additional (eeE) information. To be

able to use this kind of information in the context of the Multimodel it became necessary to

extend the Multimodel filter functions. As with the Multimodel filtering method before this is

done via links between elements: A filter query spanning multiple domains and necessitating

the employment of extended filter functions will at first be solved for each domain separately

(which may employ their Extended Proprietary Filter Functions) and all the results will then

be aggregated and analysed. For example: to retrieve all walls that contain an HVAC-element

and that have an energy parameter below a certain threshold one could at first filter on the

ESIM domain to retrieve all linked elements whose parameter is below the threshold and

afterward through BIMfit the linked elements could be filtered to create a view that only

contains walls. The walls can then be checked on whether they contain HVAC components.


Version 1.0

/72


Since the process in this example could easily be reversed or changed, the actual process to

obtain a filter result may vary from query to query.

As mentioned in this section we will focus on the extensions of BIMfit. However these extensions

can be viewed as exemplary on how to extend filter methods generally to accommodate for

HVAC, BACS and ESIM domains. The meta functions listed in the appendix under 0 are not

changed for the eeE context. The consideration of BACS, HVAC and ESIM entails the necessity to

extend meta, core and extended filter functions which is outlined in the following subsections.

The extension functions are exemplary presented in the appendix under 8.6.1, 8.6.2 and 8.6.3.

7.4.1 eeE Meta functions

In IFC4 new semantical concepts have been included to be able to model and save information of

the BACS and HVAC domain, see Chapter 7 “Domain specific data schemas” of the IFC4

specification (buildingSMART 2015). A generic filter model in the eeE context needs to be able to

address and navigate these new concepts. Therefore it was mandatory to expand the original

meta functions of BIMfit to be able to handle the new concepts. For example the concepts of

chapter 7.2 of the IFC specification (buildingSMART 2015) contain information on BACS elements

and the eeE generic filter framework needs to be able to traverse these concepts.

7.4.2 eeE Core filter functions

The concepts in the IFC4-file format also encompass new property sets and the new entities also

require new semantics to be included. The core filter functions have been extended to be able to

provide the user and other applications with these new sections of information. As with the

original core functions the extended core functions will only operate on information that is

explicitly defined in the data model. For example the core function getSensors does return the

object ID of all elements of an object set, that are of the type IfcSensor, which is a new entity in

IFC4. The getSensors function also still utilizes the meta function getEntitiesOf, which has been

expanded to be able to handle entities of the IfcSensor type. Furthermore eeE core functions

need to be able to extract possible new property sets like the sensor type of an IfcSensor object.

From this new lower order core functions and already existing core functions some new higher

order core function for the eeE context can be derived: getSensorTypeInStorey will return all

sensors within a storey that are of a specific sensor type. This function utilizes the already existing

function getBuildingElementsInStorey and combines it with the new core functions getSensors

and getSensorType respectively.

7.4.3 eeE Extended/Reasoning filter functions

Extended reasoning functions generally represent more complex data that is only implicitly

contained in the model and/or originate through the interaction and dependencies of elements.

Therefore through the inclusion of additional building elements and concepts there are of course

new possible extended reasoning functions. However not all of these functions are included

within the filter framework as some of these operations are being covered by the Ontology

services of eeE which are presented in eeE D5.2 “Interoperability System”

(Stenzel&Kadolsky2016) – especially those that involve extraction, generation and checking of Key

Points, see eeE D2.1 “Holistic multi-disciplinary KPI-based design framework” (Guruz et al. 2015a)


Version 1.0

/72


and eeE D2.3 “Holistic KPI based design methodology” (Guruz et al. 2015b), e.g. operations

determining whether a building has sufficient rooms, height. Extended Reasoning functions are

therefore mostly focused on generating information that is required for simulation or to highlight

dependencies/information for decision making. For example the ESIM simulation needs the

identification and categorisation of the façade of a building. The resulting getFacade function in

turn uses other reasoning functions. Another kind of prominent functions are the ones that check

for spatial dependencies (e.g. getSpatialContainmentOfDistributionElement), that create, extract

and analyse systems (e.g. getPhysicalConnectionOfDistributionSystem) and functions that allow

filtering for complex conditions.

Conclusions

In Deliverable 4.5 the filtering of (Multi-)models is covered in detail. It is needed in nearly any kind

of model management and information handling, for example to prepare the BIM for the Link

Models. To link data with elements, the necessary elements have to be filtered first from the BIM.

The differentiation between mainly static, dynamic and Multimodel views is presented in chapter

1 and deepened in chapter 3. The overall filtering methodology is presented in chapter 2. That

covers the explanation of descriptive and prescriptive filter methods and their further subdivision

into filtering on schema, class, object and reasoning level. Besides the detailing of the model view

types chapter 3 gives an overview of the filtering technologies utilised in eeE and presents their

classification with regard to the overall filtering methodology.

IfcDoc and XmlToFilterConverter, the two descriptive filtering technologies for the generation of

MVDs in eeE are presented in chapter 4. The prescriptive filtering technologies are covered in the

following chapters. The filtering possibilities that were developed as part of IFC-API – the interface

of the EDMModelServer – are explained in chapter 5.

Chapter 6 covers the functionality of FilterIFC and chapter 7 that of BIMfit – the filter toolbox and

underlying technology.

Chapter 7 also contains a comprehensive description of the filter toolbox extension with new ee-

functionalities, ee-query modules and the modules needed for the new ESIM and BACS semantic

model and the BACS data format which were developed in Task 4.5.


Version 1.0

/72


References

Bazjanac V., Maile T., O'Donnell J., Rose C., Marzovic N. (2011); Data Environments and processing in semi-automated simulation with EnergyPlus, Proceedings of the CIB W78-W102 2011: International Conference –Sophia Antipolis, France, (2011) 26-28 October.

Borrmann, A. & Rank, E. (2009). Topological analysis of 3D building models using a spatial query language. Advanced Engineering Informatics, DOI:10.1016/j.aei.2009.06.001.

Calleja-Rodriguez G. & Guruz R. (2014); eeEmbedded Deliverable D1.3: Interoperability and collaboration requirements © eeEmbedded Consortium, Brussels.

Chipman, T. L. (2012). mvdXML specification 1.0. Retrieved 04 28, 2016, from http://www.buildingsmart-tech.org/specifications/mvd-overview/mvdxml-releases/mvdxml-1.0

eeEmbedded: Description of Work, EU Project eeEmbedded, Grant No. 609349, Version 2013-06-13, Brussels.

buildingSMART (2014), IfcDoc development tool – Release 7.9. Retrieved 05 20, 2016, from http://www.buildingsmart-tech.org/specifications/specification-tools/ifcdoc-tool/ifcdoc-download-page

buildingSMART (2015), IFC4x1 [Final Standard]. Retrieved 05 28, 2016, from http://www.buildingsmart-tech.org/ifc/IFC4x1/html/link/ifcbuildingcontrolsdomain.htm

Fuchs, S., Kadolsky, M. & Scherer, R. J. (2011). Formal description of a generic multi-model. In: “Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE)”, Proc. 20th IEEE International Workshop, Paris, France.

Guruz R., Calleja G. & Geißler M.-C. (2015a); eeEmbedded D2.1: Holistic multi-disciplinary KPI-based design framework, © eeEmbedded Consortium, Brussels.

Guruz R., Calleja G. & Geißler M.-C. (2015b); eeEmbedded Deliverable D2.3: Holistic KPI based design methodology © eeEmbedded Consortium, Brussels.

IFC-API. (n.d.). Retrieved 04 28, 2016, from https://github.com/jotne-aet-git/eee-development/tree/master/eeE-IFC-API

Katranuschkov, P., Weise, M., Windisch, R., Fuchs, S. & Scherer, R. J. (2010). BIM-based generation of multi-model views. In: Proc. 27th CIB W78 International Conference “Applications of IT in the AEC Industry & Accelerating BIM Research Workshop”, 16-19 Nov. 2010, Cairo, Egypt.

Liebich, T. & Katranuschkov, P. (2010). Interdisciplinary use of domain models – Who needs “What”, “When” and in “Which” quality (in German). In: Scherer, R. J. & Schapke, S.-E. (eds.) “MEFISTO: Management – Führung – Information – Simulation im Bauwesen”, Proc. 1st Mefisto Congress, 21.10.2010, Dresden, Germany, pp. 79-94.

Model Support Crew of International Alliance for Interoperability. (2007). Ifc2x edition 3 technical corrigendum 1. Retrieved 05 12, 2016, from http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/index.htm

Pirnbaum, S. (2015). About FilterIFC. Institut of Construction Informatics, TU Dresden.

Pirnbaum, S. (2016). The XmlToFilterConverter Tool, Version 1.0. Institut of Construction Informatics, TU Dresden.

Romberg, R., Niggl, A., van Treeck, C. & Rank, E. (2004). Structural analysis based on the product model standard IFC. In: Proc. of International Conference on Computing in Civil and Building Engineering , ICCCBE, 02-04.06.2004.


Version 1.0

/72


Scherer R. J. & Schapke S.-E. (eds.)(2014); Informationssysteme im Bauwesen – Modelle, Methoden und Prozesse (information Systems in Building Construction – Models, Methods and Processes), Springer Vieweg, DOI 10.1007/978-3-642-40883-0, 609 p.

Scherer, R. J., Weise, M. & Katranuschkov, P. (2006). Adaptable views supporting long transactions in concurrent engineering. In: Proc. Joint International Conf. on Computing and Decision Making in Civil and Building Engineering, Montreal, Canada, June 14-16 2006, pp. 3677-3686.

Stenzel, P. & Kadolsky, M. (2016); eeEmbedded D5.2: Interoperability System, © eeEmbedded Consortium, Brussels.

Tøn, A., Mosch, M. (2016); eeEmbedded Deliverable D4.4: Multi-Model Manipulation, © eeEmbedded Consortium, Brussels.

Weise, M., Katranuschkov, P. & Scherer, R. J. (2003). Generalised Model Subset Definition Schema. In: Amor R. (ed.) “Construction IT: Bridging the Distance”, Proc. CIB-W78 Workshop, NZ, 16 p.


Version 1.0

/72


8 Appendix

8.1 IFC-API – Service Definitions

This section depicts services as they are defined at time of writing. Updates and evolutions will be

available at (IFC-API).

NOTE:

For single objects, the type of the object in the URL is in principle superfluous, since 'globalid' will

uniquely identify it. Depending on the implementation, the type may be used for filtering / double

check, but it is not required.

8.1.1 List extract endpoints/Filters

Classes

Extract Endpoint Data

Attribute Type Comment

globalid String Id for the object within model, ref IFC Schema

Name String Name as given in IFC object

Type String Filter type as human readable string / enumeration

isPredefined Bool Indicates if this filter is predefined in server or not

description String Human readable description of the object

url String How to identify the object as a cloud resource

JSON schema:

{

TODO

}


Version 1.0

/72


eeE List extract endpoints service

URL element explanation

ifc-api Short for eeEmbedded Repository Services

version States version of the API to use, allowing multiple versions of API for upgrading

model_id Identifies primary model. Alternatively given as part of JSON body argument

8.1.2 Create filter

One particular form of filter is possible to define generally – a combination of a predefined filter

and arguments, like applying domain “BACS” to the predefined “Domain Filter” yielding a new

filter “BACS Domain Filter”

Other forms of this service will probably be implementation dependent, as the most common not

predefined filters will be “custom filters” defined by the underlying server query language. This

type is not described here (yet).

eeE IFC-API Create Filter Service

URL element Explanation

ifc-api Shorthand for eeEmbedded Repository Services



filter_id GUID (GlobalID) identifying the filter used as base for the new filter. Usually a

predefined filter.

Only those filters that are not predefined can be updated.

Resource URL: *GET /ifc-api/{version}/multimodels/{model_id}/extract

Returns list of extract_endpoint_data for the found objects.

Purpose: Retrieve filter metadata

Resource URL: *POST /ifc-api/{version}/multimodels/{model_id}/extract/filter_id

Request body: filter name, description and arguments as JSON object

Returns: Filter meta-data for new filter as list of JSON object


Version 1.0

/72


8.1.3 Retrieve filter meta-data: detailed data about the filter itself

The available meta-data / information about a filter will vary according to the filter characteristics.

This service will retrieve all available meta-data fields for the service.

eeE IFC-API Retrieve Filter Service





filter_id GUID (GlobalID) identifying the filter


8.1.4 Update filter

Update a filter can basically be either of these:

Update filter meta-data

Update definition of the filter itself

The latter operation is server implementation specific and is not described here (yet)

eeE IFC-API Update Filter Service

Purpose: Retrieve filter metadata

Resource URL: *GET /ifc-api/{version}/multimodels/{model_id}/extract/filter_id/metadata

Request body: none

Returns: Filter meta-data for updated filter as list of JSON object

Purpose: Update filter metadata

Resource URL: *PUT /ifc-api/{version}/multimodels/{model_id}/extract/filter_id

Request body: filter meta-data to update as JSON object

Returns: Filter meta-data for updated filter as list of JSON object


Version 1.0

/72








8.1.5 Delete filter

eeE IFC-API Delete Filter Service






Only not predefined filters can be deleted.

8.1.6 Extract data from model according to filter

eeE IFC-API Extract Service

Purpose: Delete a filter

Resource URL: *DELETE /ifc-api/{version}/multimodels/{model_id}/extract/filter_id

Request body: filter arguments as JSON object

Returns: Filter meta-data for deleted filter as list of JSON object

Purpose: Extract partial model according to an endpoint(axis) as IFC file

Resource URL: *GET /ifc-api/{version}/multimodels/{model_id}/extract/endpoint

Request body: filter arguments as JSON object

Returns: Partial model as IFC file


Version 1.0

/72


URL element explanation




endpoint

Identifies type of extract. While actual layout of endpoint depends on the type of

endpoint, most common is combination of type and id of a filter. Using discipline as an

example it looks like this::

As part of URL: GET /ifc-api/{version}/multimodels/{model_id}/extract/discipline_id=guid

As URL argument: GET /ifc-api/{version}/multimodels/{model_id}/extract?discipline_id=guid

As JSON body: GET /ifc-api/{version}/multimodels/{model_id}/extract {"discipline_id"="guid"}

8.2 IFC-API – Usage Examples

Filter maintenance functions

List Extract Endpoints

The filter function List Extract Endpoints retrieves information about available extractable subsets

in the model. Extract endpoints are not defined by service calls; they are inherent properties of

the model itself.

Example: List system extracts endpoints in model

GET https://example.com/ifc-api/0.4/multimodels/12324/extract?filter_type="ifcsystem"

Request: none

Response:

[{ "filter_id":"522110",

"filter_name":"Energy System"

"filter_type":"ifcsystem"

},

{ "filter_id":"522111",

"filter_name":"BACS System"

"filter_type":"ifcsystem"

}]


Version 1.0

/72


Retrieve filter data

Example: Retrieve full metadata for a filter

Apply filter – Extract

Extract data

Example: Extract according to spatial endpoint; building storey 02

Example: Extract according to system endpoint; Energy System

GET https://example.com/ifc-api/0.4/multimodels/12324/extract/522110/metadata

Request (body): none

Response:

[{

"filter_id":"522110",

“filter_type”:”ifcsystem”

"filter_name": "Energy System",

"description": "Retrieve data for energy system from a model ",

“author”: “………”

“date”: “………”

“version”: “………”

"url":" https://example.com/ifc-api/0.4/multimodels/12324/extract/522110"

}]

GET https://example.com/ifc-api/0.4/multimodels/12324/extract

Request: {"spatial_object_id"="98202"}

Response: Building Storey 02 as IFC

GET https://example.com/ifc-api/0.4/multimodels/12324/extract?filter_id=522110

Request: none

Response: Energy System data as IFC


Version 1.0

/72


8.3 BIMfit – Meta (STEP/SDAI) filter functions

The STEP/SDAI functions (ISO 10303-22:1998) adapt and extend the open source JSDAI library.

The underlying data types shown in parenthesis after the description of the input/output

parameters are specified in (ISO/TS 10303-27:2000), (JSDAI, 2008) and the current Java online

documentation. The ordering of the functions corresponds to their logical structure and the order

of their use.

parseModel

Synopsis Creates a new StepDataModel object in which all instances of a specific type are arranged into separate hash sets. All model level operations are subsequently executed on that object.

Input EXPRESS model definition (String or Enum{IFC2X3,IFC2X4, IFC4}) STEP physical file (File)

Output The Step Data Model ( StepDataModel )

Dependencies None

Code example StepParser parser = new StepParser(null);

StepDataModel model = parser.parseModel(IFC2x3, new

File("Kassel_building.ifc"));

exportModel

exportModelAsXML

Synopsis Exports a new model with the given entities and attributes as a STEP physical file according to ISO 10303-21:2002 or as a XML file according to ISO 10303-28:2007 respectively.

Input The entities to export; if not provided, defaults to all entities in the model The EXPRESS schema of the model (String or Enum{IFC2X3,IFC4}) The filepath for the exported data file

Output True if successful and false otherwise (the specified file is creating in the background)

Dependencies None

Code example model.exportModel(model.getEntities(),IFC2X3,"D:\\Kassel_building_v2.ifc");

model.exportModelAsXML(model.getEntities(),IFC4,"D:\\Kassel_building_v2.xml");


Version 1.0

/72


getEntities

Synopsis Returns all entities in the model

Input None

Output Array of all entities in the current model ( Entity[] )

Dependencies None

Code example Entity[] entities = model.getEntities();

getEntitiesOf

Synopsis Returns an entity array containing all instances of the specified entity data type and all instances of all its subtypes collected going through the StepDataModel. This function can be useful e.g. to select all (types of) spatial structure elements in a given building complex, regardless of the number of buildings and respective BIM files used to model it.

Input An entity data type (Entity)

Output Array of all entities of the input type ( Entity[] )

Dependencies getInstances (entity data type), private method of StepDataModel

Code example Entity[] spaces = model.getEntitiesOf(IfcSpatialStructureElement.class);

getEntitiesOfExactType

Synopsis Returns an entity array containing all instances of the specified entity data type collected by going through the StepDataModel; the instances of any subtype of the specified entity data type are not included. This function can be useful e.g. to select all building storeys or all “standard case” walls in a given building complex, regardless of the number of buildings and respective BIM files used to model it.

Input An entity data type (Entity)

Output Array of all entities of the input type ( Entity[] )

Dependencies getExactInstances (entity data type), private method of StepDataModel

Code example Entity[] storeys = model.getEntitiesOfExactType(IfcBuildingStorey.class);

getAttributes

Synopsis Returns all attributes of an entity.

Input The entity to process (Entity)

Output Array of all attributes of the input Entity ( Attribute[] )

Dependencies None


Version 1.0

/72


getAttributeNames

Synopsis Returns all attribute names of the given entity and all derived attributes from super classes, e.g. for an IfcWallStandardCase entity it will return the attributes Description, Name, OwnerHistory, GlobalID, ObjectType, Representation, ObjectPlacement and Tag.


Output Array of all attribute names of the entity and their super classes ( String[] )

Dependencies None

Code example Entity firstStorey = stepDataModel.getEntitiesOf(IfcBuildingStorey.class)[0];

String[] attributeNames = stepDataModel.getAttributeNames(firstStorey);

getAttribute

Synopsis Returns a specific instance of the entity "attribute" defined in the "SDAI_dictionary_schema" describing EXPRESS schemas on the meta level.

Input The entity to process and the name of the entity attribute, possibly, with the simple entity name as prefix ( Entity, String )

Output Instance of the entity describing the entity attribute ( Attribute )

Dependencies None

Code example Entity[] storeys = stepData.getEntitiesOf(IfcBuildingStorey.class);

IfcBuildingStorey storey = (IfcBuildingStorey) storeys[0];

Attribute att = model.getAttribute(storey, "LongName");

getDataType

Synopsis Returns the data type of an attribute for a given entity.


Output The data type of the attribute ( <Class T> )

Dependencies None

Remark: This function is seldom used and may be declared obsolete in a next update of BIMfit.

getValueOfAttribute

Synopsis Returns the value of an attribute for a given entity.


Output The value of the attribute (Object)

Dependencies None

Code example: Entity wall = model.getEntitiesOfExactType(IfcWallStandardCase.class)[0];

// search the depth of a wall (referenced in IfcExtrudedAreaSolid)

Object value = model.getValueOfAttribute(wall,"depth");


Version 1.0

/72


unsetAttributeValue

Synopsis Deletes the value of an attribute for a given entity. This is a supporting function that may be needed in higher level composite functions to clear up values before applying another filter operation; it is not intended to be used separately as it leads to low-level change of the BIM.

Input The entity to process and the name of the entity attribute which value should be “unset”.

Output None

Dependencies None

Code example: Entity wall = model.getEntitiesOfExactType(IfcWallStandardCase.class)[0]; model.unsetAttributeValue(wall,"depth");

getEntitiesWithAttributeValue

Synopsis Searches all entities where the specified attribute has the given value (a) regardless of the entity class, or (b) for the given class only – see below. This function does not search in a set of values; for that purpose use getEntitiesWithAttributeValueContainedInSet.

Input (a) Name of the entity attribute and the value to search for (String, Object)

(b) Class type of the searched entity, as well as the name of the entity attribute and the value to search for ( Class <T>, String )

Output (a) Set of all entities that have the specified value as reference

(b) Set of all entities of the specified input type that have the specified value as reference (both: Entity[])

Dependencies getEntitesOf, getValueOfAttribute

Code example Entity[] ent = model.getEntitiesWithAttributeValue("globalid", globalID);

getEntitiesWithMaximumAttributeValue,

getEntitiesWithMinimumAttributeValue,

getEntitiesWithAttributeValueGreaterThan,

getEntitiesWithAttributeValueLowerThan,

getEntitiesWithAttributeValueNotEqual

Synopsis These functions return the entity with the highest value, the lowest value, the value greater than, lower than or not equal to a specified input value respectively.

Input Name of the entity attribute and, for the last three functions, the numeric value to test against (String, Number)

Output Array of entities where the specified attribute value fulfils the given condition ( Entity[] )

Dependencies getEntitesOf, getValueOfAttribute

Code example: // searches the elements with maximum value of attribute 'elevation'

// (this should be the top IfcBuildingStorey)

Entity[] entities = model.getEntitiesWithMaximumAttributeValue("elevation");


Version 1.0

/72


getAllReferences

Synopsis Returns all referenced entities, i.e. the totality of all relation attributes.


Output Array of all referenced entities ( Entity[] )

Dependencies getDirectReferences x getInverseReferences

Code example Entity slab1 = (IfcSlab)model.getEntitiesOfExactType(IfcSlab.class)[0];

Entity[] entities = model.getAllReferences(slab1);

getEntitiesWithAttributeValueContainedInSet

Synopsis This function has four different variations of use. Basically, it has the same functionality as getEntitiesWithAttributeValue above, but here an attribute can be a set of values.

Input For all variations the class type of the searched entities and the name of the requested entity attribute must be provided, i.e. <Class ? extends Entity>. The four variations occur in the last input parameters as follows: (a) Attribute value to search for (String, Number or String, String) (b) Entity reference to search for (here, unlike case (a) above the value is of type Entity, i.e. the examined attribute sets are expected to contain entity references) (c) Set of entity references to search for (the value is of type Entity[], i.e. the examined attribute sets are expected to contain arrays of entity references (string, Entity[])

(d) Class type to be filtered from the attribute sets (String, Class <? extends Entity>)

Output Set of entities of the input class type that have a set containing all specified entities as reference (Entity[])

Dependencies getValueOfAttribute

Code example // searching a specific wall which is in an IfcRelAssociatesMaterial instance

// related by 'relatedobjects'

Entity[] containedInAggregate

=

model.getEntitiesWithAttributeValueContainedInSet(

IfcRelAssociatesMaterial.class, "relatedobjects", walls[12]);

getReferences

Synopsis This function has three variations depending on the input parameters. It provides a filtered subset of the entities referencing the given base entity. The three distinguished cases are as follows: (a) return the reference entities filtered by attribute name and reference type (b) return all reference entities of a given class type (c) return all reference entities that match a given set of attributes

Input The entity to process (Entity), as well as: (a) the name and type of the sought attribute (String, Class <T> ) (b) the class type to search for ( Class <? extends Entity> ) (c) a list of 1..n attribute names to match (String[])

Output Array of entity references matching the given search type (a), (b) or (c)

Dependencies None


Version 1.0

/72


Code example Entity material=model.getEntitiesOfExactType(IfcRelAssociatesMaterial.class)[0];

// searching IfcBuildingElementProxy referenced to a IfcRelAssociatedMaterial

Entity[] references =

model.getReferences(material,"relatedobjects",IfcBuildingElementProxy.class);

getDirectReferences, getInverseReferences

Synopsis Returns all direct/inverse references resp. specified via an attribute of the examined entity.

Input The name of the entity and the attribute to process

Output Array of entity references

Dependencies None

getSubelements

Synopsis Returns all references specified via an attribute of the examined entity and all references to sub elements (i.e. all referenced nodes in the sub-tree of relationships with root the specified reference attribute). Optionally, the output set can be filtered by testing for the presence of one or more attributes in the referenced entity instances.

Input The entity to process and optionally a list of 1..n attributes to match (Entity, String[])

Output Array of entity references ( Entity[] )

Dependencies None

Code example Entity wall = model.getEntitiesOfExactType(IfcWall.class)[0];

// retrieve all references to a wall and references to referenced elements

Entity[] subElements = model.getSubElements(wall);

union, unionWithDuplicates, intersection, difference

Synopsis Returns the union, intersection or difference of two given entity sets respectively. unionWithDuplicates is similar to union but allows for duplicates in the resulting entity set.

Input 2 x Array of Entities ( Entity[], Entity[] )

Output Array of Entities ( Entity[] )

Dependencies None

Code example Entity[] walls = model.getEntitiesOf(IfcWallStandardCase.class);

Entity[] slabs = model.getEntitiesOf(IfcSlab.class);

Entity[] ws = model.union(walls,slabs);


Version 1.0

/72


count

Synopsis Counts how many entities of a given class type are in a given set

Input Array of entities – if not provided, i.e. null, the whole model is assumed (Entity[]) The class type to check ( Class <? extends Entity > )

Output The number of entities found (int)

Dependencies None

Code example Entity[] buildingElements = model.getEntitiesOf(IfcBuildingElement.class);

int numberOfWalls = model.count(buildingElements, IfcWallStandardCase.class)

existInstances, existReferences

Synopsis Checks if there are instances of or references to a specific class type in the model, respectively

Input The entity data type (Entity)

Output True, if instances / references of the given type are found and false otherwise

Dependencies getEntitiesOf (entity data type)


Version 1.0

/72


8.4 BIMfit – Core filter functions

The functions are ordered into three groups: (1) semantic filtering functions for IFC objects, (2) model checking functions and (3) I/O support functions.

8.4.1 Semantic filtering functions for IFC objects

getBasicModel

Synopsis Returns the StepDataModel as the current active object in memory, on which all subsequent model level operations, including all meta functions can be executed.

Input None for the first function

Output The StepDataModel

Dependencies None

getGlobalID

Synopsis Returns the global ID of the specified entity or null if such an ID does not exist.

Input Entity of class IfcRoot or any of its subclasses

Output The global ID of the queried entity (globalID)

Dependencies getValueOfAttribute

Code example Entity buildingElement = model.getEntitiesOf(IfcBuildingElement.class)[0]; String guid = model.getGlobalID(buildingElement);

getName

Synopsis Returns the name of the entity with a given global ID

Input GlobalID (String) and optional Entity Class to constrain and speed up the search

Output The name of the queried entity (String) or an empty String if no name found

Dependencies getEntitiesOf, getEntitiesOfExactType

Code example Entity space = model.getEntitiesOf(IfcSpace.class)[0];

String name = model.getName(model.getGlobalID(space));


Version 1.0

/72


getIfcEntity

Synopsis Returns an IFC entity which matches a given ID.

Input GlobalID (String) and optional Entity Class to constrain and speed up the search

Output The Entity found (instance of a subclass of IfcRoot) or null if no such entity exists.

Dependencies getEntityWithAttributeValue

Code example Ifcroot root = model.getIfcEntity("29N_BnBvTCc81bL76C5C7J");

getAssignedPropertySets, getAssignedProperties

Synopsis Returns an array of all IfcPropertySets or the assigned properties in all property sets of a given object, respectively.

Input Entity of class IfcObject or any of its subclasses

Output (a) Array of IfcPropertySet (b) Array of properties (IfcProperty[])

Dependencies getAssignedProperies uses getAssignedPropertySets

Code example IfcSpace space = model.getIfcEntity("29N_BnBvTCc81bL76C5C7J",IfcSpace.class);

IfcPropertySet[] ps = model.getAssignedPropertySets(space);

getPropertyValue

Synopsis Returns the value of a specific property (IFC properties are represented as name-value pairs).

Input Entity of class IfcProperty

Output Value (IfcObject) of given property

Dependencies None

getIfcAttribute

Synopsis Extension of the meta function getAttribute, which checks if the specified attribute exists in the IFC schema and if positive, returns a respective instance of the entity IfcAttribute describing IFC attributes on meta level.

Input The IFC Entity to process and the name of the entity attribute, possibly, with the simple entity name as prefix ( IfcEntity, String )

Output Instance of the entity describing the entity attribute ( IfcAttribute )

Dependencies getAttribute

Code example IfcSpace space= model.getIfcEntity("29N_BnBvTCc81bL76C5C7J",IfcSpace.class);

IfcAttribute attr = model.getIfcAttribute(space,"longname");


Version 1.0

/72


getIfcIndirectAttribute

Synopsis As getIfcAttribute above, but “traces” the attribute from the given base entity to check to the target entity where it is specified. If the check is positive, returns a respective instance of the entity IfcAttribute describing IFC attributes on meta level.

Input The IFC Entity to process, the target IFC Entity containing the sought attribute and the name of the entity attribute, possibly, with the simple entity name as prefix ( IfcEntity, IfcEntity, String )

Output Instance of the entity describing the entity attribute ( IfcAttribute )

Dependencies getAttribute, getAttributes, getDirectReferences

getIfcProject

Synopsis Returns the found IfcProject instance.

Input None

Output IfcProject

Dependencies getEntitiesOf

Code example Ifcproject project = model.getIfcProject();

getIfcNamedUnits

Synopsis Returns the globally assigned to the project named units (Entity type: IfcNamedUnit). E.g. LengthUnit specifies what length measure (m, cm, mm etc.) are used by default if no such unit is provided explicitly in an instance of IfcProduct or any of its subclasses.

Input None

Output Set of IfcNamedUnit

Dependencies None

Code example Set<IfcNamedUnit> units = model.getIfcNamedUnits();

getRepresentations

Synopsis Returns the provided representations of a specific representation type for a given IfcProduct instance, e.g. IfcShapeRepresentation. If no type is specified, the function returns all available representations.

Input An instance of IfcProduct or any of its subclasses The representation type, optional (String)

Output Set of IfcRepresentation

Dependencies None

Code example EEntity wall = model.getEntitiesOf(IfcWallStandardCase.class)[0]; Set<IfcRepresentation> representations = model.getRepresentations(wall);


Version 1.0

/72


getBuildingIDs, getBuildings

Synopsis Returns all buildings or building IDs in the current BIM model, respectively.

Input None

Output (a) List of GlobalID (String) (b) Map(IfcBuilding.GlobalID)


Code example List<String> buildingGuids = model.getBuildingIDs();

getBuildingStoreys, getBuildingStoreysSorted

Synopsis Returns all building storeys in the model (in the second case, sorted by elevation).

Input None

Output Set of IfcBuildingStorey


Code example IfcBuildingStorey[] storeys = model.getBuildingStoreys();

getCountStoreys

Synopsis Returns number of building storeys in the model

Input None

Output Number of Objects of the type IfcBuildingStorey

Dependencies getBuildingStoreys, getCountOfObjects

Code example int count = model.getBuildingStoreys();

getElementsForSpatialStructure

Synopsis Returns for an arbitrary spatial structure the elements contained in it.

Input An IfcSpatialStructureElement or its global ID (String) The element Class to use as filter, optional ( Class <? extends Entity > )

Output Set of instances of IfcProduct or any of its subclasses


Code example IfcSpatialStructureElement spatial = model.getSpatialStructureForElement(

"2pcXa4skr8mxNB_fdp_3ll",IfcOpeningElement.class);

Set<IfcProduct> products = model.getElementsForSpatialStructure(spatial, null);

// get the IfcDoor of the opening if available

Set<IfcProduct> ps = model.getElementsForSpatialStructure(spatial,

IfcDoor.class);


Version 1.0

/72


getBuildingElementsInStorey, getSpacesInStorey

Synopsis Returns a (filtered) set of IfcBuildingElements or IfcSpaces contained in a given building storey, respectively.

Input Instance of IfcBuildingStorey and optionally, for the first function only, the element Class to use as filter ( Class <? extends Entity > )

Output (a) Set of IfcBuildingElement or any of its subclasses (b) Set of IfcSpace

Dependencies getBuildingElementsInStorey uses getSpacesInStorey; both functions use getEntitiesOf, getEntitiesWithAttributeValue and getElementsForSpatialStructure

Code example IfcBuildingStorey firstStorey = model.getBuildingStoreySort()[0];

Set<IfcBuildingElement> elements =

model.getBuildingElementsInStorey(firstStorey,IfcDoor.class);

getBuildingStoreyForElement, getBuildingStoreyForSpace

Synopsis Returns the building storey on which the given element / space is located.

Input (a) Instance of IfcBuildingElement or any of its subclasses; (b) Instance of IfcSpace

Output IfcBuildingStorey

Dependencies getBuildingStoreys and (a) getBuildingElementsInStorey, (b) getSpacesInStorey

Code example EEntity firstWall = model.getEntitiesOf(IfcWallStandardCase.class)[0];

IfcBuildingStorey storey = model.getBuildingStoreyForElement(firstWall);

getBuildingElements, getBuildingElementsByType

Synopsis Returns all instances of IfcBuildingElement or its subclasses in the model, corres-ponding, for the second function, to the respectively specified IfcBuildingElementType or any of its subclasses.

Input (a) None, (b) Subclass of IfcBuildingElementType.class

Output Set of IfcBuildingElement

Dependencies getEntitiesOf, getReferences, getValueOfAttribute

Code example IfcBuildingElement[] elements = model.getBuildingElements();


Version 1.0

/72


getSpaces, getWalls, getWallsStandardCase, getWallsWithWindows,

getCurtainWalls, getSlabs, getRoofElements, getColumns, getBeams

Synopsis Returns the respective IFC elements (spaces, walls, ‘standard case’ walls, walls with windows, curtain walls, slabs, roofs, columns or beams) contained in the model. In the case of walls with windows and exterior walls, the respective attributions of an IfcWall are examined to decide containment.

Input None

Output Set of instances of the respective subclass of IfcBuildingElement

Dependencies getEntitiesOfExactType, getAttributeValue (for getWallsWithWindows) getBuildingStoreys, getBuildingElementsInStorey

Code example IfcSpace[] spaces = model.getSpaces();

IfcSlab[] slabs = model.getSlabs();

IfcWall[] wallsWithWindows = model.getWallsWithWindows();

// etc.

getCountOfBuildingElementsByType

Synopsis Returns the number of all instances of the specified IfcBuildingElementType within a set of building elements.

Input IfcBuildingElementType, set of IfcBuildingElements

Output Number (Int) of IfcBuildingElements


Code example int count = model.getCountOfBuildingElementsByType(IfcBuildingElementType,

BuildingElementSet);

getOpenings, getFillingElements, getWindows, getDoors

Synopsis Returns the respective openings / filling elements / windows / doors contained in a given building element (usually IfcWall or IfcWallStandardCase).

Input Instance of IfcBuildingElement or any of its subclasses

Output Set of (a) IfcOpening, (b) IfcElement, (c) IfcWindow, (d) IfcDoor

Dependencies getEntitiesOfExactType, getEntitiesWithAttributeValue getFillingElements, getWindows, getDoors use getOpenings

Code example IfcBuildingElement[] elements = model.getBuildingElements();

for(IfcBuildingElement element : elements) {

Set<IfcOpeningElement> openingElems = model.getOpenings(element);

// processing the set ...

}


Version 1.0

/72


getWindowPanelStyle

Synopsis Returns the window panel style for a given window instance, i.e. is the glazing single, double etc., is it divided in two, three or more parts and so on.

Input Instance of IfcWindow

Output The panel style (String)

Dependencies getAttribute, getValueOfAttribute

Code example String panelStyle;

Entity firstWall = model.getEntitiesOf(IfcWallStandardCase.class)[0];

Set<IfcOpeningElement> openingElems = model.getOpenings(firstWall);

for(IfcOpeningElement opn : openingElems) {

if(opn instanceof IfcWindow) panelStyle = model.getWindowPanelStyle(opn);

}

getElementQuantity

Synopsis Returns dimensional properties of an element, such as length, width, volume etc., represented via an IfcElementQuantity object

Input Instance of IfcProduct or any of its subclasses

Output Set of specified element quantities

Dependencies getRepresentations

Code example // The example assumes that the GUID of the queried element is known

IfcSpace space = (IfcSpace) model.getIfcEntity("000000002O14ruRW407VMr");

Set<IfcQuantityVolume> quantityVolumes =

model.getElementQuantity(space,IfcQuantityVolume.class);

getWallDimensions, getWallDimensionsStandardCase,

getSlabDimensions, getRoofDimensions

Synopsis Shortcuts for the more general function getElementQuantity above.

Input An instance of IfcWall, IfcWallStandardCase, IfcSlab or IfcRoof respectively

Output List of IfcMeasureWithUnit (packages unit of measure and the resp. physical quantity (length, width, depth)

Dependencies getElementQuantity, getRepresentations

Code example Entity secondSlab = model.getEntitiesOf(IfcSlab.class)[1];

List<IfcMeasureWithUnit> measuredUnits= model.getSlabDimensions(secondSlab);


Version 1.0

/72


getElementsWithMaterial

Synopsis Returns all instances of an IFC entity class which have / have not the given material assigned. Material is identified by its name.

Input The class of the IFC entities to process ( Class <? extends Entity > ), the material name (String), discriminator whether or not the material should be assigned to the resulting filtered entities (boolean)

Output The elements which have / have not the specified material assigned (IfcProduct[])

Dependencies getEntitiesOf, getEntitiesWithAttributeValue, getEntitiesWithAttributeValueContainedInSet

Code example

IfcWall[] wallelements =

(IfcWall)model.getElementsWithMaterial(IfcWall.class,"Concrete",true);

getAssociatedMaterial, getAssociatedMaterialLayers

Synopsis Returns a set / ordered list of materials associated with an IFC Element. If no element is provided, the first function will return all materials available in the current BIM. The second function is a specialisation of the first, specifically applicable for elements with layered material construction such as walls and slabs.

Input Instance of IfcElement or any of its subclasses

Output Set of IfcMaterial

Dependencies getEntitiesOf, getValueOfAttribute

Code example IfcSlab firstSlab = (IfcSlab)model.getEntitiesOf(IfcSlab.class)[0]; Set<IfcMaterial> material = model.getAssociatedMaterial(firstSlab);

getSpaceBoundaries, get2ndLevelSpaceBoundaries/get2LSB

Synopsis Returns the space boundaries for a given space (the second function additionally checks if the provided space boundaries correspond to the Level 2 specification – see ISO 16739:2013)

Input Instance of IfcSpace Type of boundaries, optional, if not given all types are assumed (IfcPhysicalOrVirtualEnum – PHYSICAL, VIRTUAL or NOTDEFINED)

Output Array of space boundaries found (IfcRelSpaceBoundary[])

Dependencies getEntitiesOf, getEntitiesWithAttributeValue

Code example IfcSpace space = (IfcSpace)model.getIfcEntity("000000002O14ruRW407VMr");

IfcRelSpaceBoundary[] spaceBoundaries = model.getSpaceBoundaries(space);


Version 1.0

/72


getWallBoundaries, getSlabBoundaries,getRoofBoundaries

Synopsis Same as above, but filtered for the respective Wall / Slab / Roof boundaries only.

Input Instance of IfcSpace


Dependencies getEntitiesOf, getEntitiesWithAttributeValue, getSpaceBoundaries

getSpaceBoundariesForElement

Synopsis Determines the space boundaries for a given IFC element.

Input Instance of IfcElement or any of its subclasses


Dependencies getEntitiesWithAttributeValue

Code example IfcSlab firstSlab = (IfcSlab)model.getEntitiesOf(IfcSlab.class)[0]; IfcRelSpaceBoundary[] sbs = model.getSpaceBoundariesForElement(firstSlab);

getAdjacentSpaces

Synopsis Determines the spaces adjacent to a given space on the basis of the specified space boundaries. The function uses IFC model semantics but not geometric reasoning. It assumes that adjacent spaces share same space boundaries - a necessary but not sufficient condition. In most cases this provides fully correct result and is much faster than a geometric test.


Output Array of IfcSpace objects sorted according to their centre point distance to the given space

Dependencies getSpacesInStorey, getSpaceBoundaries

Code example IfcSpace firstSpace = (IfcSpace)model.getEntitiesOf(IfcSpace.class)[0];

IfcSpace[] candidates= model.getAdjacentSpaces(firstSpace);

8.4.2 Model checking functions

existInstances

Synopsis Checks if instances of the given type exist in the model.

Input The class of the IFC entities to check ( Class <? extends Entity > )

Output True or false


Code example boolean existSpaceBoundaries =

model.existInstances(IfcRelSpaceBoundary.class);


Version 1.0

/72


existInstancesOfType

Synopsis Checks if instances of elements corresponding to a given typed element are defined in the model.

Input The class of the typed IFC entities to check ( Class <? extends Entity > )



Code example boolean existType = model.existInstancesOfType(IfcWallType.class);

belongsStoreyToBuilding,belongsSpaceToStorey,belongsElementToSpace

Synopsis Checks if a storey belongs to a given building, if a space belongs to a given storey, or if an element is associated to a given space, respectively.

Input (a) Instances of IfcBuildingStorey, IfcBuilding; (b) Instances of IfcSpace, IfcBuildingStorey (c) Instances of IfcElement or any of its subclasses and IfcSpace


Dependencies getEntitiesOf, getValueOfAttribute, getEntitiesWithAttributeValueContainedInSet

isEmptyPropertySet, isEmptyProperty

Synopsis Checks if property sets or a specific property contain any data.

Input The entity to process and (a) Instance of IfcPropertySet, (b) Instance of IfcProperty


Dependencies getAssignedProperySets


IfcPropertySet ps1 = model.getAssignedPropertySets(firstSpace)[0];

boolean isEmpty = model.isEmptyPropertySet(firstSpace,ps1);

isAdjacentSpace

Synopsis Checks if a space is adjacent to another given space. This function uses the same assumptions as getAdjacentSpaces, i.e. it works on semantic, and not on geometry level.

Input Two instances of IfcSpace


Dependencies getSpacesInStorey, getSpaceBoundaries

Code example IfcSpace [] spaces = (IfcSpace)model.getEntitiesOf(IfcSpace.class);

if spaces.length >= 2

boolean isAdjacent = model.isAdjacentSpace(space[0],space[1]);


Version 1.0

/72


existSpacesUnassignedToStorey, getSpacesUnassignedToStorey

Synopsis Checks if there are spaces that are not assigned to any storey in the model

Input None

Output (a) True or False, (b) Set of IfcSpace fulfilling the condition

Dependencies getEntitiesOf, getBuildingStoreys, getSpacesInStorey

Code example boolean unassignedSpaces = model.existSpacesUnassignedToStorey();

existElementsUnassignedToSpaces, getElementsUnassignedToSpaces

Synopsis Checks if there are IFC elements that are not associated with any spaces in the model.

Input None

Output (a) True or False, (b) Set of IfcBuildingElement fulfilling the condition

Dependencies getEntitiesOf, getElementsForSpatialStructure

exist2ndLevelSpaceBoundaries

Synopsis Checks if second level space boundaries are defined in the model. This is a primary prerequisite for most energy simulations.

Input None

Output True or False


Code example boolean exist2ndLevelSpaceBoundaries= model.exists2ndLevelSpaceBoundaries();

Further functions of the type existBuildingElements/Walls/Spaces/Slabs etc. conforming to given

criteria are not listed for brevity. They correspond to the getXX functions described above used to

actually filter out subsets of the IFC elements in a BIM model.

8.4.3 I/O support functions

parseIfcModel

Synopsis Convenience function, as short cut to the generic parseModel function.

Input STEP physical file (File)

Output The IfcDataModel

Dependencies None

Code example StepParser parser = new StepParser(null);

IfcDataModel model = parser.parseIfcModel(new File("TestBuilding.ifc"));


Version 1.0

/72



Version 1.0

/72


exportIfcModel

Synopsis Convenience function, as short cut to the generic exportModel function. It writes out a SPF file in accordance with the current IFC schema.

Input The entities to export (optional) and the filepath for the exported data file


Dependencies exportModel

Code example model.exportIfcModel("D:\\export.ifc");

exportIfcProduct, exportIfcProductWithGeometry

Synopsis Exports an IFC Element with / without its corresponding geometry as SPF file. The export can be partial (only the specified element) or complete (i.e. a valid SPF file with all dependencies provided, so that it can be completely read and parsed back without formal parser errors).

Input Instance of IfcProduct or any of its subclasses The filepath for the exported data file Boolean (false = partial, true = full) - optional parameter, defaults to false


Dependencies None


model.exportIfcProductWithGeometry(firstSpace,"D:\\one_space.ifc");


Version 1.0

/72


8.5 Bimfit – Extended/Reasoning filter functions

getAbsolutePoint, getAbsolutePoints

Synopsis Transforms the local coordinates of a 3D point (in the second case: all 3D points) related to an IfcProduct object to their global coordinate system values This requires that IfcGeometricRepresentationContext is available, which provides the reference to the global coordinate system of the BIM. These functions change also the association of the addressed IfcProduct object to the respective geometric description in the model.

Input Instance of IfcProduct or any of its subclasses, A Point in local coordinates (IfcPoint) – required only for the first of the above functions

Output True if the operation was successful, and false otherwise (the coordinate transformations are performed in the background, resulting to created new IFC objects)

Dependencies getAttributeNames, getReferences, existReferences, getIfcIndirectAttribute

Code example IfcSlab firstSlab = (IfcSlab)model.getEntitiesOf(IfcSlab.class)[0];

Point3d[] points = model.getAbsolutePoints(firstSlab);

getGlobalOrientation

Synopsis Transforms the orientation of the axes of an IfcProduct object to the global axes of the BIM. This is particularly useful when elements have to be checked against the actual geographic position of the facility.

Input Instance of IfcProduct or any of its subclasses, Instance of one of the subclasses of IfcPlacement

Output The reference point and the orientation of the axes of the IfcProduct object in global coordinates. Thereby the axes are the same as for the existing global coordinate system, but the coordinate origin for the given IfcProduct object is respectively shifted.

Dependencies getAttributeNames, getReferences, existReferences, getIfcIndirectAttribute

Code example IfcWall W1 = (IfcWall)model.getEntitiesOf(IfcWall.class)[0];

Point3d[] points = model.getGlobalOrientation(W1);

mapToGlobalCoordinates

Synopsis Transforms all coordinates of all IfcProduct objects to global 3D coordinates.

Input None

Output New version of the BIM model where all geometry data is represented in the global coordinate system.

Dependencies Several meta level functions, getIfcEntity, getIfcIndirectAttribute


Version 1.0

/72


getBuildingElementsInZone , getSpacesInZone

Synopsis Find all building elements / spaces lying within the geometrically specified zone. The zone is described via a polygon of connected points projected onto a specific building storey.

Input An IfcSpatialStructure instance or a set of IfcPoint defining the zone Instance of IfcBuildingStorey, optional

Output (a) Set of instances of IfcBuildingElement (b) Set of instances of IfcSpace

Dependencies Several meta level functions, getBuildingStoreys, getBuildingElementsInStorey, getSpacesinStorey, existSpacesUnassignedToStorey

Code example IfcSpatialStructure zone =

(IfcSpatialStructure)model.getEntitiesOf(IfcSpatialSstructure.class)[0];

Set<IfcBuildingElement> elems = model.getBuildingElementsInZone(zone);

getAdjacentSpacesWithGeometry

Synopsis This function has the same effect as getAdjacentSpaces but calculates adjacency using an accurate geometric algorithm. Depending on the complexity of the space geometry it may take long time to execute

*).


Output Set of IfcSpace objects

Dependencies Several meta level functions, getAdjacentSpaces, getGlobalOrientation (createAdjacentListOfSpaces may be used in specific application contexts to speed up the procedure if many adjacency queries are to be performed)

Code example IfcSpace space = (IfcSpace)model.getEntitiesOf(IfcSpace.class)[0];

Set<IfcSpace> adjacentSpaces = model.getAdjacentSpacesWithGeometry(space);

isAdjacentSpaceWithGeometry

Synopsis Checks if a space is adjacent to another given space. This function has the same effect as isAdjacentSpace but calculates adjacency using an accurate geometric algorithm. Depending on the complexity of the space geometry it may take long time to execute.

Input Two instances of IfcSpace


Dependencies Several meta level functions, isAdjacentSpace


Version 1.0

/72


createAdjacentListOfSpaces

Synopsis Uses a special algorithm to create an adjacency matrix on which basis subsequent adjacency tests can be executed quickly.

Input Instance of IfcBuildingStorey (if not provided, an adjacency matrix is created for each storey)

Output None (the adjacency matrix data structure, specific to BIMfit is created in the background)

Dependencies Several meta level functions, getBuildingStoreys, getSpacesInStorey, getAdjacentSpaces

create2ndLevelSpaceBoundaries

Synopsis Using the algorithm developed by partner Granlund creates Second Level Space Boundaries for a given IfcSpace object on the basis of First Level Space Boundaries available in the model

Input Instance of IfcSpace and geometry from BSPro library

Output Array of space boundaries (IfcRelSpaceBoundary[])

Dependencies Several meta level functions, getSpaceBoundaries

Code example BSProGeometry geo = new BSProGeometry(“D:\\sbGeometry.xml”);

IfcSpace[] spaces = (IfcSpace)model.getEntitiesOfExactType(IfcSpace.class);

IfcRelSpaceBoundaries[] sb2nd =

model. create2ndLevelSpaceBoundaries (IfcSpace[0], geo); // See next section 4.5 for a more detailed example.

getFacadeElements, getFacadeWalls

Synopsis Returns all façade elements / the wall elements for a building storey or for the whole building.

Input Instance of IfcBuildingStorey or IfcBuilding; The façade orientation ( ENUM{N,S,E,W,NE,NW,SE,SW} or vector providing the direction )

Output (a) Set of IfcElement instances, (b) Set of IfcWall instances

Dependencies Several meta level functions, getBuildingStoreys, getSpacesInStorey, getAdjacentSpaces, getElementsForSpatialStructure, getGlobalOrientation

Code example IfcBuilding bld =

(IfcBuilding)model.getEntitiesOfExactType(IfcBuilding.class)[0];

Set<IfcBuildingElement> elems = model.getFacadeElements(bld,N);


Version 1.0

/72


8.6 New ee filter functions

8.6.1 ee Meta functions

getDistributionElements

Synopsis This function queries all objects/instances of class IfcDistributionElement.

Input void

Output Set of IfcDistributionElement objects

Dependencies None

Code example Set<IfcDistributionElement> distributionElement =

model.getDistributionELement();

getDistributionControlElements

Synopsis This function queries all DistributionControlElements

Input void

Output Set of IfcDistributionControlElement objects

Dependencies None

Code example Set<IfcDistributionControlElement> distributionControlElement =

model.getDistributionControlELements();

The following functions are specializations of getDistributionControlElement:

getActuators

getController

getSensors

getUnitaryControlElements

getDistributionFlowElements

Synopsis This function queries all IfcDistributionFLowElement objects

Input void

Output Set of IfcDistributionFlowElement objects

Dependencies None

Code example Set<IfcDistributionFlowElement> distributionFlowElement =

model.getDistributionFlowELements();


Version 1.0

/72


The following functions are specializations of getDistributionFlowElements to query the

corresponding IFC specializations within the HVAC domain:

getDistributionChamberElements

getDistributionControlElement

getDistributionFlowElement

getEnergyConversionDevice

getFlowController

getFlowFitting

getFlowMovingDevice

getFlowSegment

getFlowStorageDevice

getFlowTerminal

getFlowTreatmentDevice

getProperySetOfDistributionElement

Synopsis This function queries all Property Set for a IfcDistributionElement object (occurrence driven property sets)

Input IfcDistributionElement object

Output IfcPropertySet objects

Dependencies getObjectDrivenPropertySet()

Code example IfcPropertySet propertySet=

model.getPropertySetOfDistributionElement(distributionElement);

getDistributionPort

Synopsis This function queries all IfcDistributionPort objects

Input IfcDistributionElement object or IfcDistributionElementType object

Output Set of IfcDistributionPort objects

Dependencies None

Code example Set <IfcDistributionPort> distributionPorts =

model.getDistributionPort(distributionElement);

Further functions to access attributes (direct, indirect) and property sets/quantity sets of

distribution port objects are necessary.


Version 1.0

/72


getDistributionSystems

Synopsis This function queries all IfcDistributionSystem objects

Input void

Output Set of IfcDistributionSystem objects

Dependencies None

Code example Set<IfcDistributionSystem> distributionSystems = model.getDistributionSystems();

Further functions to query subsystems or system of a specific type should be possible:

getSubSystemsOfDistributionSystem(distributionSystem)

getSystemOfPredefinedType(PredefinedType)

8.6.2 ee Core functions

getDistributionElementType

Synopsis This function queries the corresponding Object Type a given IfcDistributionElement object


Output Set of IfcDistributionElementType objects

Dependencies getIfcEntity, getDistributionElements

Code example IfcDistributionElement distributionElementType =

model.getDistributionElementType(distributionElement);

getDistributionControlElementType

Synopsis This function queries the DistributionControlElementType for a DistributionControlElement object

Input IfcDistributionControlElement object

Output IfcDistributionControlElementType objects

Dependencies getIfcEntity, getDistributionControlElement

Code example IfcDistributionControlElementType distributionControlElement =

model.getDistributionControlELement();


Version 1.0

/72


The following functions are specializations of getDistributionControlElementType:

getActuatorType

getControllerType

getSensorType

getUnitaryControlElementType

getDistributionFlowElementType

Synopsis This function queries the corresponding IfcDistributionFlowElementType object for a DistributionFLowElement object

Input IfcDistributionFlowElement object

Output IfcDistributionFlowElementType object

Dependencies getIfcEntity, getDistributionFlowElement

Code example IfcDistributionFlowElementType distributionFlowElementType =

model.getDistributionFlowELement(distributionFlowElement);

The following functions are specializations of getDistributionFlowElementType:

getDistributionChamberElementType

getEnergyConversionDeviceType

getFlowControllerType

getFlowFittingType

getFlowMovingDeviceType

getFlowSegmentType

getFlowStorageDeviceType

getFlowTerminalType

getFlowTreatmentDeviceType

getProperySetOfDistributionElementType

Synopsis This function queries all Property Set for a IfcDistributionElementType object (type driven property set)

Input IfcDistributionElementType object

Output Set of IfcPropertySet objects

Dependencies getTypeDrivenPropertySet()

Code example Set <IfcPropertySet> propertySet=

model.getPropertySetOfDistributionElementType(distributionElementType);


Version 1.0

/72


The following list of property set should be accessible:

Pset_ActuatorPHistory

Pset_ActuatorTypeCommon

Pset_ActuatorTypeElectricActuator

Pset_ActuatorTypeHydraulicActuator

Pset_ActuatorTypeLinearActuation

Pset_ActuatorTypePneumaticActuator

Pset_ActuatorTypeRotationalActuation

Pset_AlarmPHistory

Pset_AlarmTypeCommon

Pset_ControllerPHistory

Pset_ControllerTypeCommon

Pset_ControllerTypeFloating

Pset_ControllerTypeMultiPosition

Pset_ControllerTypeProgrammable

Pset_ControllerTypeProportional

Pset_ControllerTypeTwoPosition

Pset_FlowInstrumentPHistory

Pset_FlowInstrumentTypeCommon

Pset_FlowInstrumentTypePressureGauge

Pset_FlowInstrumentTypeThermometer

Pset_SensorPHistory

Pset_SensorTypeCommon

Pset_SensorTypeConductanceSensor

Pset_SensorTypeContactSensor

Pset_SensorTypeFireSensor

Pset_SensorTypeFlowSensor

Pset_SensorTypeGasSensor

Pset_SensorTypeHeatSensor

Pset_SensorTypeHumiditySensor

Pset_SensorTypeIonConcentrationSensor

Pset_SensorTypeLevelSensor

Pset_SensorTypeLightSensor

Pset_SensorTypeMoistureSensor


Version 1.0

/72


Pset_SensorTypeMovementSensor

Pset_SensorTypePHSensor

Pset_SensorTypePressureSensor

Pset_SensorTypeRadiationSensor

Pset_SensorTypeRadioactivitySensor

Pset_SensorTypeSmokeSensor

Pset_SensorTypeSoundSensor

Pset_SensorTypeTemperatureSensor

Pset_SensorTypeWindSensor

Pset_UnitaryControlElementPHistory

Pset_UnitaryControlElementTypeCommon

Pset_UnitaryControlElementTypeIndicatorPanel

Pset_UnitaryControlElementTypeThermostat

8.6.3 ee Extended/Reasoning functions

getPhysicalConnectionOfDistributionSystem

Synopsis This function provides the physical port connection among distribution elements containing to a distribution system.

Input IfcDistributionSystem object

Output The physical port connection of a distribution system.

Dependencies i.e. getDistributionElements; getDistributionElementType; getDistributionFlowElements; getDistributionFlowElementType; getDistributionControlElements; getDistributionControlElementType; getDistributionPorts;

getLogicalConnectionOfDistributionSystem

Synopsis This function provides the logical port connection among distribution elements containing to a distribution system.


Output The logical port connection of a distribution system.

Dependencies i.e. getDistributionElements; getDistributionElementType; getDistributionFlowElements; getDistributionFlowElementType; getDistributionControlElements; getDistributionControlElementType; getDistributionPorts;


Version 1.0

/72


getSpatialContainmentOfDistributionElement

Synopsis This function provides the spatial containment of a distribution elements containing to a distribution system.

Input IfcDistributionElement object and/or IfcDistributionSystem object

Output Set of IfcSpatialStructureElement.

Dependencies i.e. getDistributionElements; getDistributionElementType; getDistributionFlowElements; getDistributionControlElements; getDistributionSystem

getDecompositionOfDistributionElement

Synopsis This function provides the decomposition of a distribution element containing a distribution system.


Output Set of IfcDistributionElement.

Dependencies getIfcDistributionElements, getIfcDistributionSystem

Code example Set <IfcDistributionElement> subElements =

model.getDecompositionOfDistributionElement(element);

getDecompositionOfDistributionSystem

Synopsis This function provides the decomposition of a distribution system into sub-systems.


Output Set of IfcDistributionSystem.

Dependencies getDistributionSystem

Code example Set <IfcDistributionSystem> subSystems =

model.getDecompositionOfDistributionSystem(system);

optimised design methodologies for …eeembedded.eu/wp-content/uploads/2017/09/20160610_eee_d4...0.1...

Documents