9.4.1.1.  Product model

In IFC, a construction work is decomposed into a set of products. These products can have multiple representations. For example, a wall can be described as a solid body as well as a two-dimensional axis. These representations facilitate different views on the same data: an editable line segment or an easily visualized volume. The Object-relational nature of the IFC EXPRESS schema allows intricate relationships such as a representation context that communicates additional intent for the representation or presentation styles that can be granularly assigned to individual faces.

At the same time, such a product separates the placement (an hierarchical transformation) from the actual geometry definition. The consequence of this is that in spite of its object-relational nature, IFC product representations cannot be used for building-level topological relationships between solids, because even if two solids are touching in 3D, the fact the the placement is externalized out of the geometry definition (or the fact that faces are constructed procedurally and do not exist explicitly), means that the two faces cannot be opposite oriented twins. As such, relational geometric constructs such as space boundaries are provided as additional supplementary geometries.

In principle, the IFC schema has been designed in a modular fashion with independent modules for, for example, geometry, materials and meta-data. However in other cases, semantics and geometry are intertwined such as tapered extrusions (lofts) where the begin and end profile of a duct carry important semantics.

IFC also allows for decomposition, where a whole is aggregated into multiple parts for richer semantics. This allows for example to connect materials and meta-data to the frame and the glazing separately, while still being able to identify the aggregate as a single window. This is not used as frequently, partially due to inability to efficiently instantiate such aggregates as geometry instances.

9.4.1.2.  Evolving views on geometry

IFC is heavily influenced by the ISO 10303 (STEP) family of standards, but over time adopted its own geometric paradigms:

Especially the handling of tolerances means that the standard cannot effectively prescribe a consistent outcome in all cases. Tolerances are needed for BRep model with non-linear underlying geometry and/or fixed precision coordinate values, e.g higher degree nurbs curves are typically intersected with numerical approximation, so a vertex that connects two of such curves needs to have seen as a sphere with the local tolerance as its radius. This tolerance is also applied to boolean operations: an subtraction volume can be slightly inwards of the first operand but is still expected to pierce through the volume and increase surface genus. This contrasts with the desire of using IFC as a legal basis in contracts. NB Tolerances stand in the way of using existing approaches for SFA geometry predicates such as PostGIS+SFCGAL which is based on arbitrary precision boolean logic as implemented in CGAL without tolerances.

9.4.1.3.  Use cases

The most successful use case on BIM data is coordination and visualization where multiple aspect models are geometrically overlaid in order to find issues, which are then communicated to the authoring software where they are addressed. This approach works, because it respects that individual disciplines all have their own specialistic software.

Design to design workflows are much harder to realize, although some Model View Definitions have been developed on top of IFC that enable the transfer of design intent in specific and constrained scenarios, such as precast concrete and structural steel.

Long-term preservation of building information is difficult because of the fact that IFC models are difficult to mutate, because they are so explicit and don’t contain the vendor-specific design intelligence. Therefore native software cannot always re-import IFC models, but also the native models degrade over time because of the need to migrate to newer editions of the software. Software that can directly operate on IFC to make modifications is still experimental.

BIM-GIS integration is challenging because it requires familiarity with both domains on where to draw the line between euclidean and non-euclidean geometries and acceptable error metrics.

Simulations on IFC building models are often challenging because the ‘bag of individual elements’ does not provide a good foundation higher order topological representations required for flow-of-energy type of simulations. For e.g thermal simulation a topological view of space boundaries is required. They have been added as secondary set of ternary relationships, but usage of more specific-purpose and simpler schemas sees still more usage in industry. In general, IFC models are created for a specific purpose and wide-spread usage of those models in nieghbouring domaisn remain challenging because modelling for those neighbouring purposes requires alignment on the worldviews and levels of detail that is often beyond the scope in which such models are procured.

9.4.1.4.  Implications and questions:

9.5.2.1.  OpenCASCADE-inspired BRep ontology

Perzylo, A., Somani, N., Rickert, M., & Knoll, A. (2015, September). An ontology for CAD data and geometric constraints as a link between product models and semantic robot task descriptions. In 2015 IEEE/RSJ international conference on intelligent robots and systems (IROS) (pp. 4197-4203). IEEE.

https://ieeexplore.ieee.org/abstract/document/7353971

[7]

9.5.2.2.  Topologic

Jabi, W., & Chatzivasileiadi, A. (2021, January). Topologic: exploring spatial reasoning through geometry, topology, and semantics. In Formal Methods in Architecture: Proceedings of the 5th International Symposium on Formal Methods in Architecture (5FMA), Lisbon 2020 (pp. 277-285). Cham: Springer International Publishing.

https://topologic.app/

[1]

10.1.1.1.  Vocabulary

GeoSPARQL 1.1 defines a class Geometry as a subclass of SpatialObject.

An instance of Geometry is not restricted to two dimensions.

A fine-grained classification of Geometry can use the Simple Features Vocabulary (TODO: add link) which extends the class Geometry with further types, such as Point, Polygon etc.

The Simple Features vocabulary allows for the definition of 3D variants of:

It does not include commons 3D primitives, such as Cube or Mesh surfaces which are integral parts of 3D representations.

Concerning metadata of 3D models, GeoSPARQL 1.1 provides properties which can be reused in 3D contexts. In particular, the properties are:

Further 3D-related metadata properties such as projection matrices are not part of the current GeoSPARQL 1.1 standard.

10.1.1.2.  Geometry Relations

Relations between geometries have been defined using three different sets of rules:

All geometry relations are only defined for 2D geometries and do not take into account the third dimension.

10.1.1.3.  Literals

A first requirement for 3D support is the ability to save 3D data in a knowledge graph. GeoSPARQL 1.1 defines a variety of String literal formats, which are investigated for the storage of 3D data.

Table 1

GeoSPARQL 1.1 also does not restrict the usage of coordinate reference systems with 3D support. There are currently almost 300 coordinate reference systems in the database epsg.io which can be used to describe 3D data encoded in the GeoSPARQL graph literals listed above.

10.1.1.4.  Query functions with 3D support

GeoSPARQL 1.1 functions currently do not offer fully-featured 3D support. However, there are functions which may take into account the Z coordinate, if they are available.

Table 2

These functions check for the presence of Z coordinates or filter out maximum and minimum Z coordinates of the given geometry.

11.1.1.1.  Extension 1: 3D representations

11.1.1.2.  Extension 2: Relations of 3D geometries

11.1.1.3.  Extension 3: Appearance of 3D geometries

11.1.1.4.  Extension 4: Multi-component 3D geometries

11.1.1.5.  Extension 5: Positioning of 3D geometries

11.1.1.6.  Extension 6: Alignments of GeoSPARQL 3D

11.1.1.7.  Extension 7: Alignments of Engineering CRS to Geospatial CRS

11.1.1.8.  Extension 8: Geometry Extrusion

11.1.1.9.  Extension 9: Geometry Attributes

11.1.1.10.  Extension 10: Non-topological Query Functions — 3D Extension