3.1. Modelling the Collaborative Process with IDM
Just as in many other places in the world, the Dutch government is going digital. A vast information infrastructure is being built with the aim of making the system more efficient but also making it simpler to use. One part of this is the creation of an information infrastructure the Digital System (
Digitaal Stelsel) [
27]. A part of the Digital System, the Information House Buildings [
28] is devoted to the automation of the process of building registrations. The subject of this workflow is leveraging off this process to obtain 3D legal spaces (if required). Please note that this workflow is modelled in the IDM to facilitate communication with the building industry, not to impose the world of BIM on the world of GIS. A BIM model is the product of many parties. At a certain point in time, there is a merging, but this involves the individual parties overlaying their own version with what they have learnt. A true unambiguous and single-source-of-reference complete model of the building may never actually exist. There is also the issue of intellectual property; the individual owners of the BIM may not like their model being generalised. This is taken into account.
A central goal of the presented research is obtaining 3D parcel data from BIMs. A collaborative workflow would support the reuse of BIM data for 3D Cadastre purposes by improving the alignment of activities. Part of the process of gaining a building permit for a building would involve providing the Land Administration System with appropriate legal spaces. This process is illustrated in Business Process Modelling Notation in
Figure 2 and
Figure 3. With the aim of making this process as clear as possible, text that would usually be referred to the diagram using a number system has been left in the diagram.
Someone wanting to build or to renovate a house first seeks advice from the government concerning, for example, what can be built where and to which Cadastral regulations they should adhere. They are also given access to a digital file in IFC format showing what has already taken place. They then set to work on a 3D BIM for the construction. Part of this process is to create several space objects grouped into a zone to represent the legal spaces in the building. These are customised legal space .ifc files for inclusion in the BGT and Kadastrale Kaart. The resulting 3D BIM is tested digitally to see if it conforms to the advice the Land Registry gave in the original file. In addition, an assessment needs to be made as to whether the definition of the legal spaces is in accordance with the physical artefact as designed. A definitive permit is requested, and, when it has been received, the building is then constructed according to the design that has been submitted. During the building process, things change, and the BIM, which serves as the central point for the collaborative building process, changes with it. The ‘as-built’ BIM becomes different to the BIM that was initially submitted to the authorities. These are typically minor changes that occur out of on-site coordination works or material availability among external suppliers. The building is inspected and, where necessary, the Cadastral regulations are enforced. A further issue is that the building may be subdivided and put up for sale in a different manner than was initially communicated. Therefore, the cadastral database needs to have an ‘as sold’ data set for its records as well. Underpinning the entire process is the use of open BIM standards, which ensure that the data can be used by many for a variety of purposes and for a long time.
This workflow has been given in the manner of a BIM open standard (the IDM) to illustrate how different actors should collaborate. Communicating it in this manner could also be helpful when detailing the Cadastral requirements of a building project. This workflow has been modelled on a similar workflow proposed in the Netherlands for obtaining BIM data for building registrations [
28,
29].
3.2. Mapping the LADM to the IFC
The mapping of the LADM to the IFC has been separated into three parts for easier comprehension; these parts do, however, all connect together. The model in
Figure 4 follows the typical IFC schema decomposition structure of an
IfcProject,
IfcSite,
IfcBuilding, and
IfcBuildingStorey. While there can only be one
IfcProject, there can be multiple sites, buildings, and storeys (ground floor, first floor, etc) within a project. The
IfcSite,
IfcBuilding, and
IfcBuildingStorey hierarchy accommodates this. It is at the
IfcSite level that a BIM’s one set of geo references can be found, something which has been mapped to an attribute of the
LA_SpatialUnit. The LADM allows a legal space to be pinpointed by one point [
1].
The
LA_SpatialUnit has been mapped at the level of
IfcSpace. An
LA_SpatialUnit can be composed of many things like a utility network; for example, underground pipes but also the plumbing on a major building site. This can be in addition to a
LA_LegalSpaceBuildingUnit, an
LA Level or an
LA Group, all of which are specialisations of
LA_SpatialUnit. A space with physical space boundaries can be any of these things, which is why
LA_SpatialUnit has been mapped to it. In common with the
LA_Spatial Unit, an
IfcSpace can also be made up of a number of spaces. While a number of topologically-represented spaces can be stacked in the IFC, they can also be grouped into an
IfcZone, if required. A “spatial unit represents…a single or multiple volumes of space”—hence its reflexive relationship in the diagram.” [
1]. Because of this, both
IfcZone and
IfcSpatialZone have been mapped to
LA_Spatial Unit.
Two potential options for grouping
LA_Spatial Unit are shown in the mapping,
IfcZone and
IfcSpatialZone. The advantage of an
IfcSpatialZone is that each entity “can have its own placement and shape representation”[
6]. An
IfcZone, by contrast, is a group of
IfcSpaces.
The IFC works primarily with solids rather than boundary representation [
6,
14]. There are many types of solids in the IFC, as befits a model of more than 800 entities. In general, these solids are made by extruding from a circle, rectangle, or polygon, although the IFC also allows many types of boundary representation. While the obvious place to look for these many types is in
IfcTopologyResource,
IfcGeometricResource can also provide options.
Our research looks at building a topological 3D Cadastre. A further constraint is that land administration databases generally work with simple geometry. This is illustrated by the geometry of the Dutch
Kadaster’s database [
29]. This database works with polyloops (
lijnketens), consisting of straight line segments and circular arcs in 2D. Other curves are used in other countries in exceptional cases. The Dutch database is a topological database, which uses one ‘
kaartlijn’ to define the boundary between spatial units.
Four forms of geometric boundary representation have been chosen from the many options provided by the IFC (see
Figure 5). The basic building blocks of all of them are points (nodes), edges (straight lines), and surfaces (faces). None of them involve curves, unless they are planar. They are open shell by means of infinite prisms, closed shells, polygonal bounded half-spaces, and faceted boundary representation (brep).
An open shell is a collection of surfaces. It is a topological entity but is not closed. In a Cadastral setting, it may need to be left open at the top or bottom. A closed shell is a space enclosed in a collection of connected faces or surfaces; it encloses a volume and is ‘water tight’. Whereas an open shell has one or more sides missing, thus leaving it open, a closed shell does not. The closed shell is typically part of faceted Boundary Representations (BRep) in the IFC that define a closed volume by providing every bounding face explicitly. This simple form of boundary representation has planar faces and straight edges. The vertices are defined in polygonal loops (IfcPolyLoop), and the edges are implicitly defined as the line segments that span those vertices.
Open and closed Shells and faceted brep can straightforwardly be mapped to the LADM. The cartesian points, which are their most basic building block, map to LA_Point (GM_Point); the polyloops formed from the points equate with LA_BoundaryFaceString (GM_Multicurve) and the connected faces, which edge them (IfcConnectedFaceSet) to LA_BoundaryFace (GM_Multisurface). When these building blocks are put together, they form the open and closed shells with faceted Breps, which represent IfcSpace.
The buildingSMART website describes property sets, modelled in
Figure 6, as ”a way to exchange alphanumeric information attached to spaces, building elements and other components” [
6]. Property sets are a way to extend the IFC model without changing it at a class level. The property sets work as containers to which individual properties (key-value pairs) can be added This can work within the framework of the common or predefined property sets (
p_set), which are included from IFC2*3 [
30], a revision of the IFC, onwards.
IfcSpace, for example, has several predefined properties (
Pset_SpaceCommon). One of these predefined properties, an
IfcPropertySingleValue, could be used in conjunction with
IfcIdentifier to provide a reference ID for each spatial unit. In this instance (see
Figure 6),
IfcIdentifier from
Pset_SpaceCommon has been mapped to an attribute of
LA_LegalSpaceBuildingUnit,
suID, which stands for spatial unit identity number.
Property sets have been included in the IFC model so that attribute definitions from different disciplines can be internationally standardized at a basic level. The use of Pset_SpaceCommon to provide an identifier is an example of this. Just as the LADM itself can be extended and adapted for regional or national use, so can the IFC. These IFC basic property sets can then be complemented by regional property sets or property sets agreed upon in projects.
Once a Model View Definition (MVD) has been put together, a tool—the IfcDoc tool, which is made freely available on the buildingSMART website—can be used to document it fully. This full documentation can be exported in .mvdxml, allowing an automated interface for importing and exporting software, as well as standardized grammar to assert whether exchanged IFC models comply to the MVD [
31]. Instances can then be created within this framework. The IfcDoc tool can be used to create and document, as well as to check that models comply with this framework. In the 3D use case explored in this paper, however, the object (was made in commercial software using the IFC4 Design Transfer View, which allows the inclusion of a larger variety of entity definitions.
3.3. Use Cases
The following use cases illustrate scenarios in which a 3D Land Registry System could be useful.
3.3.1. Scenario 1: Traditional Parcel Columns
The first use case is illustrated in
Figure 7. A central principle of land registry systems around the world is that, although a parcel of land or a spatial unit is recorded in 2D, in reality it alludes to a 3D space. Unless there are other rights or restrictions recorded, this space reaches below the 2D representation to the earth’s core and endlessly up into the sky.
Research has been conducted into how this concept could be geometrically stored in a database. One method would be to take parcels recorded in 2D and convert them into 3D by adding a z-axis [
33]. This z-axis would be added to the nodes of each parcel and would be infinite with a maximum of infinity.
Industry Foundation Classes (IFC) models typically document a building artefact by means of a decomposition of three-dimensional volumes. These volumes are referred to as the
Body geometry. Current research [
33,
34] states that a reinterpretation from two-dimensional Cadastral registrations into three-dimensional entities is necessary, either for a transition period in which the Cadastre is migrated or for a hybrid stage in which two-dimensional parcels exist alongside three-dimensional volumes and need to be checked for interferences. For comparison, three approaches to unify 2D parcel data with IFC models are given below. All approaches have the fact that legal spaces are exchanged as an
IfcSpace element in common.
In its simplest form, a two-dimensional footprint representation is provided for such a space. This footprint is illustrated first as a snippet of code (
Figure 8) and, secondly, as in
Figure 9a.
On the one hand, this is a satisfactory solution as it allows a collection of two-dimensional parcels within an IFC file. One advantage of a Cadastral database in which all parcels are recorded as three-dimensional entities is that situations of conflict are immediately apparent as the intersections of three-dimensional parcel volumes. In a database with both two- and three-dimensional parcel volumes, the two-dimensional volumes would need to be interpreted as three-dimensional prisms when conflicting situations were queried for. Therefore, it would be beneficial to look for approaches to encode such an infinite prism in IFC.
EXPRESS, the modelling language in which the IFC schema is defined, differentiates between integer and real number types of arbitrary precision, but the real number type in EXPRESS does not offer a means to encode the concept of infinity. This contrasts with other technical standards to represent floating point numbers such as IEEE 754, which is the prevalent representation of floating point numbers in hardware and software today. Therefore, from a semantic point of view, it is not possible, for example, to state that the Z-coordinate of some vertex lies at infinity. In reality, however, an arbitrary, large number can be chosen that is ‘infinite enough’ for all practical calculations. Geometric modelling kernels often use arbitrarily large values to represent infinity so that transformations on such infinite points are still meaningful. For instance, the geometric modelling kernel Open CASCADE, which is used by various closed and open source IFC software applications, uses 1 × 10^100 as its absolute value, beyond which a length measure is considered infinite. Note that this is many orders of magnitude greater than the distance from the Earth to the sun in meters and is therefore a sufficient approximation of infinity for Cadastral purposes.
Despite there being no explicit notion of infinity present in the IFC, there are geometric representations with infinite volume or area such as infinite mathematic planes. An
IfcHalfSpaceSolid is the portion of infinite three-dimensional Cartesian space that exists on one side of an infinite surface. This geometrical entity is frequently used to define cutting planes that trim away parts of wall segments under tilted roof slabs. A further specialization of this construct,
IfcPolygonalBoundedHalfSpace, can be used to model an infinite extruded prism in the direction away from the surface normal. The union of two such half spaces in opposite directions can be used to model an infinite prism in both directions. The IFC standard documentation [
6] includes the phrase “half space solids are only useful as operands in Boolean expressions”, but no formal mechanisms are in place to exclude such items from being first-order citizens in geometric representations. Note that these body representations are distinct from the concept of space boundaries discussed earlier, but space boundaries can be used to further qualify the nature of the individual faces of the body representation; in particular, whether such a face marks a physical or virtual boundary.
3.3.2. Scenario 2: Complex Multi-Use Rights with the 3D
The Lakeside Restaurant is a data set made available as an IFC file by the United Kingdom’s National Building Specification [
26]. This specification is a case study project for the National BIM Library, which is used to market the National BIM Library. This library contains proprietary and non-generic objects, which are free to use and platform neutral so that they can be imported into BIM design projects [
26]. The data set is a complex design that is modelled down to the last detail. The data set is used within this paper to illustrate how legal spaces can best be taken from 3D BIMs.
3.3.3. The Lakeside Restaurant in a 2D Cadastre
Buildings built above water pose a problem to a 2D Land Administration System. Imagine a situation in which a privately owned parcel is situated above water belonging to the city council (government). Only the stilts on which the building is touch the ground; the rest of the building is situated higher up and above the water.
Figure 10 illustrates how it could be registered. This method was used for a similar building in Amsterdam, which was positioned above an underground carpark [
34].
The round circles in
Figure 10 represent 41 separate spatial units or parcels, which are part of parent parcel 799, all of which are included in the database. These separate spatial units are the piles that penetrate through the water to the lake bed below. The building itself is positioned above these piles.
There are a few problems with this solution. The first is that, on the basis of these records, someone studying the records can only guess at what the building (
Figure 11) looks like. The second lies in the maintenance of the records. Each one includes the rights, responsibilities, and restrictions associated with the whole building. Not only would updating them all be prone to error, but one could easily be inadvertently skipped while transferring the deed.
3.3.4. The 3D in a 3D Cadastre
An alternate method of registering the 3D would be to do so in a 3D format. The data could be extracted from a 3D IFC model for use by a 3D Cadastre. The 3D would be a particularly interesting space to register. To begin with, it is positioned above water. Not only is it positioned above property belonging to someone else, but the boundary between the two properties is what could be described as an ambulatory natural boundary. In this context, this would refer to the fact that water levels beneath the building are not fixed but rise and fall depending on the weather, rather than the normal definition, where a river or other water boundaries expand in 2D.
A further issue is that, not only does the building encompass an open air (no top) outdoor deck, positioned above the water, but also many other spaces within the building are not fully enclosed. One such space can be seen in
Figure 11, in which an outdoor eating area is shielded by a roof and partially covered walls. Another part of the building is an outdoor terrace, completely open to the sky.
One method of representation would be to represent the building as one simple surface model, as illustrated in
Figure 12. In
Figure 12, the whole restaurant has been redrawn as a closed volume. The terrace has also been reformed, to illustrate that it is a limited space both below and above and that the whole has become one
IfcSpace.
A different option would be to use the notion of IfcZones or IfcSpatialZones to further decompose and specialize that nature of various sections of the building. Parts of the building could then be represented by IfcSpaces but with varying representations The closed part of the 3D could rely on boundary representations to accurately depict the varying heights of the roof. Partially closed sections could be bounded by virtual boundaries, i.e., ones that do not correspond to physical objects.