An Automatic Process for the Application of Building Permits

Abstract

Building Information Modeling is an essential element for the digitization of the construction industry and forms the basis for the exchange of model-based data. In order to exploit the full potential of digitization, it is necessary for all stakeholders to operate digitally and avoid media discontinuities and format changes. A particular part in this process is given to the building authority, which has to examine and approve every application for a building permit. Our long-term goal is to automate the approval process in Austria; to reach this goal, we investigate which tasks have the highest potential for automation. We address this research question by interviewing the main stakeholders, by evaluating the tasks for the ability to automate them, and by clustering them in order to identify common subroutines and algorithms. As a result, we identify eight algorithmic tasks that can be automated and that are a part of every approval process, and we implemented these algorithms to prove the automation concept. This proof of concept is the basis for future automation steps in the processes of building authorities, whose implementation requires not only changes in the technical but also in the social, societal and political environments.

1. Introduction

The digitization of the construction industry is a process that has been taking place for several years [1]; nevertheless, the construction industry is by far not the leading industry in terms of digital transformation [2].

Communication is of particular importance in this context, and a major milestone has been reached with the introduction of Building Information Modeling (BIM). According to Borrmann et al., BIM is based on the idea of the continuous use of digital building models throughout the entire life cycle of a built facility, starting from the early conceptual design and detailed design phases, to the construction phase, and the long phase of operation. BIM significantly improves information flow between stakeholders involved at all stages, resulting in an increase in efficiency by reducing the laborious and error-prone manual re-entering of information that dominates conventional paper-based workflows [3].

In the last few years, the communication changed significantly from so-called closedBIM to openBIM [4]. While closedBIM only allows data exchange between software products of one manufacturer or a selected product range, openBIM offers the potential to exchange data between software products of many different manufacturers due to a freely available, open, and fully documented interface.

This development is particularly important for the development of BIM with regard to the legal framework conditions, with its requirements and warranty specifications under public procurement law, which do not allow a restriction of the possible software products in the planning and establishment of the planning team or the execution. The openBIM concept guarantees above all small- and medium-sized enterprises (SMEs) their access to all projects which would have been accessible only to large structures under closedBIM, and also allows the uncomplicated combination of several SMEs to form joint ventures for large projects. In general, the SME sector offers a more diverse range of software, which makes the use of a uniform data interface indispensable.

Although BIM is already practiced in many construction projects throughout the entire world, the fragmented nature of the construction industry still impedes its more widespread use. Government initiatives around the world play an important role in increasing BIM adoption: as the largest client of the construction industry in many countries, the state has the power to significantly change its work practices. Legislative and administrative responsibilities are often diverse and not coordinated, even within individual countries, meaning that the preconditions for a digital process are not optimal [5].

In order to exploit the full potential of digitization, it is necessary for all stakeholders to operate digitally and avoid media discontinuities and format changes. A particular part in this process is given to the building authority, which has to examine and has to approve every application for a building permit.

The long-term goal of many e-government initiatives is to automate the approval process. In a first step, we investigate which tasks have the highest potential for automation. We address this research question by interviewing the main stakeholders, by evaluating the tasks for the ability to automate them, and by clustering them in order to identify common subroutines and algorithms. The algorithmic tasks that can be automated and that are a part of every approval process were implemented in order to prove the automation concept. This proof of concept is the basis for future automation steps of the processes of the building authority, whose implementation requires not only changes in the technical but also in the social, societal, and political environments.

In this article, we describe a geometric, technical approach towards digitizing the approval process without going into detail about the legislative and administrative framework.

2. Related Work

The approval process is strongly interwoven with the planning phase and is at the intersection of several domains: geographic information systems (GIS) and cadastral data provide the planning basis for the initial situation to describe the geographic prerequisites and the existing building stock. Designation and development plans, as well as legal requirements, form the regulatory context. This setting forms the requirements model that encompasses and describes the space of all planning possibilities. A possible manifestation of the planning options (a concrete construction plan), which is submitted to the authorities for approval, is the so-called candidate model. These three aspects (GIS, legal framework, and model checking) span the field of interest of this work.

2.1. Geographic Information System

Over the past few decades, GIS have become an increasingly familiar aspect of urban planning. These systems integrate a range of geographical information into a single analytical model, in which diverse data are geographically referenced [6].

These different focuses have historical roots that are still reflected in different ways of working and approaches in practice today: While the GIS and BIM domains clearly overlap, e.g., in the modeling of cities, each domain retains its own focus, the BIM domain focuses on information about the design, construction, and operations of building sites, and thus has very detailed and semantically rich information about all the physical elements that comprise an individual building as it is designed, built, or used. Meanwhile, GIS represent information about the environment “as built” (or as captured) at different points in time, thus yielding less detailed but regularly updated datasets covering wide regions [7].

Despite the thematic closeness of BIM and GIS, the combination of both techniques and models is a complex challenge: important elements of metadata for any BIM model are its location and orientation on the surface of the Earth. In most cases, engineering design is based on Cartesian coordinate systems. However, as facilities are placed in a geospatial context, discrepancies result from the transformation from the Earth’s curved surface to the orthogonal Cartesian coordinate system [8].

The trend of increased usage of both BIM and GIS and the similarity between the two has led to an increase in the overlap between them. A key application of such overlap is providing geospatial context data for BIM models through importing GIS data to BIM software [9]. However, this need for data exchange is not a one-way street. The conversion of detailed architectural models (BIM) to semantic 3D city models (GIS) is a topical subject. Because CityGML (City Geography Markup Language; an open standardized data model and exchange format to store digital 3D models of cities and landscapes) is a data model designed for the geospatial world, much information during the conversion from IFC (Industry Foundation Classes; a CAD data exchange file format intended for description of architectural, building, and construction industry data) is inherently lost. Such loss of information is not necessarily a disadvantage because, usually, there is no need to generate an equally detailed counterpart in the geospatial domain, as use cases—especially those focusing on the urban scale and covering multiple buildings—would even suffer from excessively rich datasets [10].

In addition to the mutual complementation through context and details, further potentials of the GIS and BIM data integration open up [11]. Zhu et al. summarize these potentials and outline the current state of the art [12].

2.2. Approval Processes and Legal Frameworks

Because of its focus on ease of interoperability between software platforms, the government client of the AEC/FM (Architecture, Engineering, Construction, and Facilities Management) sector from the US, Denmark, Finland, Norway, and the Netherlands issued a commonly signed “Statement of Intention to Support Building Information Modeling with Open Standards” on January 17th 2008, making the commitment to facilitate the use of the IFC standard very explicit. This starting signal was used to address the problems caused by legal, social, and technical barriers.

Concerning the approval processes, the question of how to translate building regulations into algorithms and machine-readable code quickly arose. Eilif Hjelseth presents a methodology to convert regulations into computable rules in BIM-based model checking [13]. The adaptation strategies of different countries around the world could not have been more different [14]; however, almost all of them have in common that the results of the strategy are far behind the expectations [15]. The “Comparative Analysis of International and National Level BIM Standardization Efforts and BIM adoption” by Ruwini Edirisinghe and Kerry London suggests that the national governance and institutional frameworks influence BIM adoption. Hence, the authors recommend that the governments in the countries where BIM is becoming established should consider proliferation of national standards and compliance for a wider spread of BIM adoption [16]; i.e., for a successful BIM implementation, there must be targeted BIM initiatives at national level to ensure wider adoption of BIM [17].

Due to the different legal frameworks in different countries, the comparison at international level is relatively difficult [5]. Nevertheless, all digitization processes and e-government initiatives face similar problems: The digital transformations involve the interaction of many institutions and bodies and are not always supported by all of them. In “Legal barriers to 3D cadaster implementation: What is the issue?” the authors [18] phrase it as follows: “In conclusion, it is highly likely that the main barrier to cadastral innovation lies not in technological or legal issues, but more fundamental social and cultural issues that make up the institutional framework underpinning cadastral systems and its inherent processes.” This opposition is not surprising, as digitalization has been identified as one of the major trends changing society and business. Digitalization causes changes for companies, governments, and everyday life due to the adoption of digital technologies in society, in organizations, and in the operation environment [19].

As information and communication technologies began to support new forms of interaction between governments and their constituents, the concept of e-government emerged [20] with the goal to use information technology to enable and improve the efficiency with which government services are provided to citizens, employees, businesses, and agencies. The building approval process is particularly resistant to digitization. Most planning processes have been digital for a long time. However, digitization often ends in the approval process because most authorities are not yet set up accordingly [21].

In addition to the technical issues of a digital construction approval process [22], such as a lack of mapping of legal entities in IFC format [23], numerous other factors can be identified for successful digitization: in “The BIM-Based Building Permit Process: Factors Affecting Adoption” the authors reveal ten factors that influence BIM adoption for building permits via a thematic analysis of semi-structured interview data [24]; the study confirms that organizational factors are a key aspect [25].

Environmental factors are another significant concern—especially the legal context. The relevant laws, rules, and regulations are not only spread across many responsibilities; they have also grown historically and were never intended to be processed and checked algorithmically—let alone be machine-readable [26,27,28,29]. Exemplary also are the six unaddressed barriers to BIM implementation found by Zhou et al. In “Barriers to BIM Implementation Strategies in China” the main barriers are “insufficient government lead/direction, organizational issues, legal issues, high cost of application, resistance to change of thinking mode and insufficient external motivation” [30].

2.3. Model Checking

Conformance testing of 3D models is a necessary process to establish a common quality standard in collaborative environments [31]. This process has several pitfalls and is inherently complicated in CAD [32]—even without the specifics of BIM and GIS.

Model checking not only serves the approval process but can also be used internally for design [33] and quality assurance [34]. These internal usage scenarios are easier to accomplish due to the reduced external influences. In detail, model checking between stakeholders may connect users and manufacturers to promote the circulation of modular building products, as well as provide designers with standardized modular BIM objects for design purposes [35].

The external usage scenarios cause the most problems and are still only partially solved [36,37]. A working solution has not yet emerged, but prototypes now exist for (partial) verification of compliance with building laws in individual countries [38]: United Kingdom [39], South Tyrol (Italy) [25], South Korea [40], etc.

Current solution approaches often take a semi-automatic approach to implement algorithmically elusive constraints and specifications [41]. Since the design and concept of a building is a form of communication, in addition to automation, i.e., communication with a computer, improving the submission process through new means of communication is also a goal of current research. If the approval process is not fully automated, augmented reality technology may help an employee of a building authority to understand a building’s design and concept [42].

Only individual special cases can be checked fully automatically at the moment. The complexity of the generalization currently still prevents comprehensive solutions. The work of Harish Narayanaswamy exemplifies how many constraints are currently necessary to be able to realize a prototype and how great the challenges are to transfer this work to other legislative areas: the “study presents the automated checking of zoning regulations according to the City of Edmonton municipal bylaws related to residential zoning designs and the Alberta Building Code part 9 related to housing and small buildings for light-frame residential buildings” [43].

The complicated algorithms required (if they can be described in algorithmic terms at all) also vary because of the different legal frameworks in different countries; so there is an opportunity to learn from the differences in each country and combine the best of all approaches [44] with the long-term goal of completely automating the approval process [45].

2.4. Open Problems

In the BIM adoption process, the countries Norway and Singapore have a leading role. Nevertheless, it is not clear how their success can be transferred to other countries. In “Public BIM-based model checking solutions: lessons learned from Singapore and Norway” Eilif Hjelseth identifies that their success “is the balance between the three perspectives: integrated process, collaborating people and interoperable technology” [46]. Despite the great advantages [47], multistakeholder involvement in construction is a challenge in BIM implementation. In the transition period to BIM, the three main challenges are: the compatibility of supplier companies with BIM, the need for two-dimensional drawings, and contractual issues related to BIM [48].

The context of an official approval authority increases the complexity of a BIM transition. Building permit processes differ even within the authorities of a state or a country and have been mostly developed traditionally [49]. In general, building permit processes worldwide are complex, difficult, and inefficient. The existing approaches focus on improvements through digital transformation and neglect to examine the fundamentals [44]. A common foundation of all building permit processes would focus the current research on technical problems, such as data loss in conversion [50], algorithmic complexity [51], and incompatible software [52]. With a common foundation, the solutions to these problems can be applied worldwide.

3. Methodology: Approval Process

The approval process described is based on the technical possibilities and the currently (theoretically) available data. Legal framework conditions, distributed responsibilities, and administrative hurdles are not taken into account in this Utopian ideal process planning.

The data basis for the process analysis was collected with the relevant stakeholders in Austria via workshops and via telephone interviews. The following institutions were addressed:

• City of Vienna (MA41).
• City of Graz.
• City of Linz.
• Land Surveying Office Lower Austria.
• Land Surveying Office Burgenland.
• Land Surveying Office Upper Austria.
• Land Surveying Office Salzburg.
• Land Surveying Office Styria.
• Land Surveying Office Tyrol.
• Land Surveying Office Vorarlberg.
• Land Surveying Office Carinthia.
• Building Department Lower Austria.
• Building Department Burgenland.
• Building Department Graz/Styria.

The responses were mostly short; however, a few contacts provided enough insight to identify the commonalities of the most frequent approval test requests and to automate the largest amount of work according to a Pareto process. Afterwards, the commonalities were grouped together so that configurable, local attributes could be parameterized, i.e., allowable building height, for example, is a configurable parameter that varies in different regions but is checked in almost all regions.

With these simplifications in mind, the following process description is to be interpreted as a long-term objective. Only the intentions of the regulations were taken from the existing ones in order to keep the assumptions on a generic basis.

3.1. Data Sources

Currently, the information and data relevant to a construction project are located in different places, require different access authorizations, are sometimes subject to a charge, or have to be surveyed and measured at great expense [5].

In an ideal process, a building applicant receives this information bundled and legally reliable from a single provider:

• Site plan and views.
• Land register excerpt.
• Cadastral map.
• Dedications.
• Height levels.
• Adjacent property information.
• Infrastructure and interfaces.
• Requirements and legal (especially local) regulations,
  e.g., protection of historical monuments.
• ….

This selection is not exhaustive and is for illustrative purposes only. The information provided should include all necessary information and (except where there are other reasons not to do so) any useful additional information.

In the ideal process, this information forms the requirements model, which consists of three parts:

• Textual information: E.g., the addresses of adjacent property owners to obtain any necessary consents.
• Geometric/geographical information: The GIS model of the construction site should be the basis for geometric geographic information. In particular, all constraints that can be represented by a geometric reference (e.g., the maximum building height by a correspondingly high hull geometry) should be included in the model.
• Complex information: Constraints that cannot be represented by simple geometric objects, or that have no geometric representation at all, should be checked automatically; the validation routines should be executed in a way to reduce the workload of the authorities and to offer short development cycles with rapid feedback.

Based on these considerations, the approval process can be designed as outlined in Figure 1:

• In the first step, the building applicant expresses the construction interest to the building authority.
• The authority then begins to gather all the necessary and useful information and sends the resulting requirements model to the building applicant automatically.
• This requirement model is the planning basis and serves as the first sketch and the first draft. All sketches, drafts, designs, and plans are called candidate models.
• A candidate model can be prechecked at the building authority automatically and without obligation. The pretest corresponds to the final assessment and serves to provide quick feedback.
• Rule conformities and rule violations of a candidate model are documented and communicated to the building applicant as a protocol.
• Any necessary changes will result in a design loop or lead to a final submission.
• In the ideal case, this process should be fully automated.

3.2. Requirement Model and Candidate Model

In order to illustrate the concept and to show the feasibility of the proof-of-concept, several use-cases and datasets were designed. One of these examples is visualized in Figure 2; it shows a requirement model (left) and a candidate model (right) meeting the desired requirements.

4. Algorithms

Due to the numerous regulations in the construction industry, the proof-of-concept of a research project obviously cannot check all rules; as representative examples of many manual checks that could be automated, several algorithms were designed and implemented.

4.1. Containment Check

The containment check verifies that any geometry of the candidate model lies within the defined containers of the requirements model. Each container consists of a set of oriented hyperplanes whose intersection defines the valid space. A hyperplane is a subspace whose dimension differs by one in relation to the surrounding space, e.g., a line in a 2D plane is a hyperplane, as well as a 2D plane in 3D space. Each hyperplane divides its surrounding space into two halfspaces; in case of an oriented hyperplane, the halfspaces can be distinguished. In this way, any convex container can be defined. Figure 3 illustrates this concept in a 2D plane and in 3D space.

The calculation is performed in two steps. In the first step, for each polygon of the container, the plane equation of the plane containing this polygon is determined. The result is a normalized equation

$$a·x+b·y+c·z+d=0\mathrm{with}\left|\left|\left(\begin{array}{c}a\\ b\\ c\end{array}\right)\right|\right|=1.$$

(1)

Points of the plane satisfy this equation; all other points with coordinates $\left(x\right|y\left|z\right)$ deviate positively or negatively and can thus be assigned to one of the two halfspaces:

$$a·x+b·y+c·z+d\lessgtr 0.$$

(2)

By convention, the negative halfspaces are considered valid; the positive ones are invalid.

If all three points of a triangle are in the same halfspace, the complete triangle is in the very same halfspace. The containment check uses this property and checks if all triangles of the triangulated candidate model lie in the negative halfspaces of all hyperplanes.

4.2. Projected Limit Check

The projected limit check analyzes the building and site density. The test checks whether the surface sealing exceeds any limits in absolute values (in square meters) or in relative proportion (in percent). This geometric test uses a cell grid approach: The property is extracted from the requirements model and its axis-aligned bounding box is determined. This rectangular structure is converted into a 2D grid with a predefined cell size, which determines the resolution and accuracy of the test. In this grid, each cell is initialized as buildable (inside the property) or nonbuildable (outside the property).

After initialization, the triangulation of the candidate model is registered in the cell grid structure. For this purpose, each triangle is projected into the ground plane, and all grid cells that have a non-empty intersection with the triangle are marked as built.

Finally, the built-up and nonbuilt-up cells are counted, and their number and ratio are compared with the limit values. If the limit values are not exceeded, the test is considered to have been passed. Figure 4 sketches the main data structure of the algorithm. The inaccuracies due to the cell grid structure are negligible if the resolution is sufficiently high, e.g., using a resolution of 1 square centimeter per cell.

4.3. Roof Gradient Check

The roof gradient check inspects the slope of the roof: the roof inclination has to be within a specified range. This test algorithm uses a grid structure storing the maximum height in each grid cell. Figure 5 illustrates the purpose of the grid approach: on a “micro”-level, the geometry (blue) may have inclination angles of 71.6${}^{\circ }$ and 76.0${}^{\circ }$. A medium-resolution grid storing the maximum heights only simplifies the geometry to a staircase function (light red). The top center points of all grid cells with their corresponding neighbor cell points approximate the roof gradient in a numerically stable way (red). Using this method, the shown example in Figure 5 reveals a roof inclination of 26.6${}^{\circ }$.

This principle can be generalized from 2D to 3D. In 3D (see Figure 6, left), the more extensive neighborhood relationships give rise to several possibilities for determining the gradient in a cell. The implemented algorithm uses all eight neighboring cells and calculates eight gradients accordingly (see Figure 6, right).

4.4. Maximum Number of Floors Check

Buildings are subject not only to a restriction on the maximum height in absolute terms but also on the maximum number of floors. This test checks compliance with these limits in two ways: (a) the storeys mapped in the IFC structure and their number must be below the limit, and (b) the product of the number of storeys and a specified average storey height must also be below the limit. In simple cases (see Figure 7, left), the product of the storey and the average height coincides with the total height, which is checked with the containment check. In complicated cases with mezzanines (e.g., on slopes), the product results in further, additional restrictions (see Figure 7, right).

4.5. Exposure Quotient Check

Living areas of a building should or must (depending on the regulation) have natural lighting. The degree of natural lighting is mainly determined by the geographical conditions, by the geometry and topology of the surroundings, and by the quotient of the window area to the room size. Geographical conditions are taken into account by the national and regional laws and regulations. The geometry and topology of the surroundings are reflected in the buildable areas and in clearance areas (see Containment check). The ratio of window area to room size is checked in this exposure quotient check: all spaces marked to be “living area” are checked whether the ratio of the window area in relation to the room area passes a minimum threshold. This test requires living spaces to be labeled as “living area” and windows to be modeled as semantic entities in IFC.

4.6. Designation Check

The permitted uses of a building/property and the specified designation (residential or commercial) form an essential specification, which are regulated by ordinances and laws in almost all countries. This check verifies that all instances of IFC spaces and IFC buildings have set the properties’ “OccupancyType” and “BuildingDesignation”. The permitted property values are stored in the requirements model in the corresponding containment spaces as a complete list. The absence of these property entries, or property entries that are not defined in the requirement model, are interpreted as errors.

4.7. Escape Route Check

Another property that must be stored in the IFC model is the identification of the entrances and exits as possible fire exits. The escape route algorithm uses the “fireexit” label to virtually walk through the building in reverse order; i.e., the exit/door with the property “fireexit” has the level $l=0$ and distance $d=0$ to the nearest emergency exit (see Figure 8). Subsequently, all reachable spaces and connections to other spaces are analyzed and traversed. For this purpose a connection graph is created starting with the exit. All connections and connected spaces are interpreted as level 1, measured with respect to the distances of the entries and exits ($d_{1,i}$), and saved as visited. This step is repeated with the spaces reachable from level 1 for levels 2, 3, 4, etc., until all spaces have been visited or no further space is reachable. The distances $d_{level,index}$ are combined to a graph structure whose leaf nodes contain the length of the space diagonal, so that for each reachable space the shortest way to the exit is provided by the path from the leaf to the root of the graph. For the case of a ring closure (see room “D” with connection D-IV-B-V-E-VI-F-VII-D), the graph must be simplified according to the minimum-spanning-tree algorithm. Finally, it is checked whether all spaces have been reached/visited and whether the fire exit path lengths are smaller than a predefined, fixed limit value.

This inverse approach (not starting from any point in the building and walking the path to the exit but exploring the building from the exit) is also used in the following, final test.

4.8. Noise Emission Check

The noise emission check calculates the maximum noise level so that the emission limits are not exceeded at the boundary of the property. Sound and noise propagation follows the inverse-square law; i.e., the noise level is inversely proportional to the square of the distance from the source. Starting from the permissible limit value at the boundary of the property, the correspondingly higher values are calculated towards the inward part of the property [53]. Considering the property as a geometric polygon P, the distance $\delta$ to the boundary corresponds to the inner constrained $\delta$-annulus of the polygon, i.e., the closed region containing all points inside P at distance at most $\delta$ from the boundary of the polygon [54].

Since the computation of the inner constrained $\delta$-annulus—especially the consideration of all special cases—is complicated and numerically unstable, and since no high accuracy is required, a grid-based approach is implemented in this check: for each cell, the distance to the boundary is calculated; in this way, the computation of the inner constrained $\delta$-annulus is reduced to simple distance calculations between points and straight lines (see Figure 9).

5. Results

The selection of the individual tests serves to illustrate a basically broad spectrum of applications. In this context, the (manual) test procedures that are relevant in Austria were analyzed and discussed. Subsequently, these tests were grouped into equivalent classes, and corresponding representatives were selected and implemented. The equivalent classes and their representatives are:

Semantic annotation: 

This class includes tests that verify the presence of necessary semantic markup in the IFC data. The “designation check” is a representative of this class.

Threshold inspection: 

Many tests only check a single value or the fulfillment of a simple scalar inequality. This class is represented by the tests’ “maximum number of floors check” and “exposure quotient check”.

Geometric checks: 

The geometric tests are divided into three classes. The first class performs direct geometric tests; two other geometric classes perform indirect tests on simplified or derived geometries. A representative of a direct geometric test is the “containment check”.

Geometric simplification: 

Two representatives of an indirect geometric test are the “projected limit check” and the “roof gradient check”. In both cases, the geometry in the IFC is first simplified (transformed to a block structure using cell grid algorithms) before a geometric test is performed. The errors introduced by the simplification are limited (by the choice of the cell size), and the advantages of the simple, numerically stable implementation outweigh minor inaccuracies (whose size is known).

Geometric derivation: 

The last class includes derived (and additionally simplified, if necessary) geometries. Two representatives of this class are the “escape route check” and the “noise emission check” test. In both cases, new structures are derived from the initial geometry: the “escape route check” derives a discrete graph structure representing the layout from the continuous room geometry; the “noise emission check” deduces the (simplified) annulus structure of the building.

The final application was implemented in Java using the data structures provided by BIMserver https://bimserver.org/ (accessed on 1 December 2022), the open-source building information model server to import and process IFC data.

The application consists of a form mask, which in the first part requires general information about the BIM server and the requirement and candidate models and which in the second part allows the configuration of the individual tests to be performed (see Figure 10). Having entered all parameters, the application performs the approval tests and returns the test results in form of an HTML file that can be viewed in any browser. Figure 11 shows the application’s output using one of the test cases. Although the software is still in a very early stage of development, it already shows a high potential for future developments and applications.

6. Discussion

The results of the proof-of-concept implementation show the feasibility in principle, even if there is still a clear need for improvement in individual parts:

• The containment check works perfectly. Only if the test fails and finds geometry that is outside the intended containment, troubleshooting may be difficult. Large models, where not all assemblies and parts are named in a meaningful way, pose a problem for a meaningful error message, which makes troubleshooting more difficult.
• The projected limit check works and the used grid approach is numerically stable and robust. Only the choice of the grid cell size results in inaccuracies, which may lead to wrong test results in borderline cases.
• The roof gradient check suffers from the same problem. The grid approach can be interpreted signal-wise as a low-pass filter, so that “high-frequency geometry” may not be considered comprehensively or completely. From the application user’s point of view, especially the nontrivial consequences of cell size selection are not always obvious and pose a problem.
• The maximum numbers of floors check works flawlessly.
• The exposure quotient check is an implementation of the simple procedure currently in use. For historical reasons, this does not use the possibilities of modern data processing. Shadowing effects in cities due to neighboring buildings or in the countryside due to mountains are not taken into account in this test, although corresponding data exist.
• The designation check works without problems or limitations.
• The escape route check uses simple geometric estimates (the path length through a room is approximated by the room diagonal, etc.), which, as with the cell grid algorithms, can lead to numerical inaccuracies and thus incorrect results in borderline cases.
• The noise emission check needs further evaluation with real-world data, as the indication of noise sources in the IFC data is often not marked.

In spite of all the minor limitations, the implementation does not show any problem that questions the basic feasibility.

This proof of concept is adapted to the Austrian legal basis. The main concept is similar to other existing approaches [55]; especially, it is similar to the work presented by Sagar Malsane [39], Plazza et al. [25], and Kim et al. [40], who presented solutions for the United Kingdom, Italy, and South Korea, respectively. All solutions show that many regulations can be mapped to algorithms in order to perform automatic checks.

Furthermore, these solutions illustrate another problem: the inconsistent legal situation is a barrier to digitization. It enforces multiple adjustments for small regional markets, making a solution economically nonviable. In personal conversations with Austrian stakeholders, we received confirmations that the technical challenge is not the biggest problem but rather the mixed situation of different involved institutions, with different legal frameworks and political interests at the municipal, state or national level. For this reason, both top-down (nationally prescribed solutions) and bottom-up (local initiatives) approaches are difficult to implement.

This underlying situation of mixed responsibilities also delays the necessary transformation of regulations into machine-readable and objectively interpretable rules. As soon as the rules and regulations are machine-readable, there are no obstacles to an automatic solution from a technical point of view. While the simplification of responsibilities would be desirable from a citizen’s perspective, it is not a technical limitation. Distributed databases [56], cryptosystems [57], digital signature mechanisms [58], and smart contracts [59] also provide the technical basis for distributed responsibilities.

Non-machine-readable specifications, such as “the building must blend into the landscape”, cannot be clearly decided objectively. This class includes many rules and regulations from a wide variety of thematic areas and legislative responsibilities.

7. Conclusions

Building Information Modeling is an essential element for the digitization of the construction industry and forms the basis for the exchange of model-based data.

One example of data exchange that illustrates the potential of digitization is the automatic approval of buildings by the building authorities. In the long term, this process should be digital and largely automatic in order to accelerate and standardize processes. In a first step, we analyzed the current processes in different Austrian building authorities. As a result, we identified eight algorithmic tasks that can be automated and that are a part of every approval process, and we implemented these algorithms to prove the automation concept.

This proof-of-concept is the main contribution of this article. During development, it became more and more clear that the implementation requires not only changes in the technical but also in the social, societal, and political environments. As a practical implication, our future activities will comprehend not only research on technical questions but also address societal issues of cooperation at various levels and political issues to unify the legal framework.

The current limitations of the prototypical solution presented originate in fragmented responsibility and inhomogeneous (software) environments. This circumstance should be addressed in the future at an organizational level in a top-down manner, whereas the technical obstacles should be clarified in future versions of standardization in order to include markup needed for environmental protection checks, fire protection checks, noise protection checks, etc.