IFC models for (semi)automating common planning checks for building permits

To support building permit issuing with automatic digital tools, the reuse of models produced by designers would make the process quicker and more objective. However, current studies and pilots often leave a gap with respect to the models as actually provided by architects, having varying quality and content. In this study, rather than taking a top down approach, we started from the available data and made the necessary inferences, which gave the opportunity to tackle basic and common issues often preventing smooth automatic processing. Specific characteristics of the IFC models were outlined and a tool was developed to extract the necessary information from them to check representative regulations. While the case study is specific in location, regulations and input models, the type of issues encountered are a generally applicable example for automated code compliance checking. This represents a solid base for future works towards the automation of building permits issuing.


Introduction
Digitalization of administration data and procedures is of current interest all over the world [1], in order to increase efficiency in bureaucratic procedures and reduce inaccuracies, irregularities and ambiguities, besides reducing the use of resources for more sustainable practices [2]. Several pilots are implemented In order to address these challenges, we chose to adopt a bottom-up approach (Section 2), investigating the readiness of practice to support such a procedure, which is the most basic premise for enabling building permits digitalization, although being little investigated so far. Many of the current efforts (Section 1.1) focus on the technological developments, considering the IFC data model as defined by the standard. The models used for testing are often modeled on purpose, within academic environment and caring their validity for the scope of the test. However, this is quite far from how IFC models are produced in practice [40] and, as a consequence, the application of the output of many studies is hindered in practice. Practitioners have often little control on the quality and content of IFC models. Because they sometimes lack specific knowledge and because they work with commercial systems that do the conversions for them, allowing little customization.
The main focus of this study was, therefore, the use of models produced by practitioners to design real buildings recently approved or waiting for approval. Within a project carried out with the city of Rotterdam 8 we had the opportunity of investigating the overall use case and the several related issues in practice, i.e. valid regulations, a real-world building permit checking case, existing municipal data, designs as submitted by architects, practice of permit-checkers, and so on.
We could inspect and analyze two delivered models by architects as a significant sample in order to check their compliance with the general IFC prescriptions (Section 3). The consequences of the possible misalignment on the development of an automatic tool to assist in urban planning checks were pointed out. In order to ensure the validity of our results beyond the scope of the local project, we had made, in parallel, a wider inspection of IFC models provided by practitioners, from different countries and professionals, to ensure that similar characteristics are found in most of such models and those reported here are not exceptional [40].
In addition, a demonstrator tool able to assist in checking some regulations was implemented, that could use the provided models (and therefore most of the current IFC models as they are usually exported by authoring software) notwithstanding their issues (Section 4). In particular, according to the findings about the state of the models, the tool used a mostly geometry-based approach, associated with the minimum semantics useful to select the interested parts of the model (e.g. division in storeys, Elevation attribute of IfcBuildingStorey etc.). According to our experience, guidelines to modelers are proposed in Section 5.
Although the findings explained in the paper are very practical, they represent a concrete starting point, investigated with a systematic and scientific method (described in Section 2), that deserves to be explained and clarified. It supports further research and application development about using IFC and automating and digitalizing the building permits checks. Several research topics can be developed from the outcomes of this study, among which: the need of defining clear data requirements, as most useful for the use and analysis of the models; their formal representation within the IFC model, most likely by means of a specific Model View Definition; IFC validation; the selection and extraction of the needed information from the overall model, as well as the kind of encoding, in order to work with smaller data sets; the connection of BIM with geoinformation to improve automation and enhance analysis performance; methods to fix the not suitable models by inferring the needed information; methods to generate and extract the needed geometry by selecting and possibly generalizing the geometries of elements composing the BIM.
The issues investigated and addressed in the paper are sometimes part of the experience of professionals and researchers dealing with BIM from practice, but there was very little evidence of this in the scientific literature, bringing to the wrong belief that any IFC-compliant model, exported by any IFC-Certified software could be directly used within any other IFC-based tool. Such aim is instead still far, although some work is in progress with respect to it. For example, many of the institutions experimenting with digital building permits (see Section 1) are developing data requirements specifications for the IFC models to be delivered.
The overall topic of digitalization of building permits is vast and several sub-issues must be tackled before getting to a comprehensive solution. The EUnet4DBP 9 defined the implied ambitions to aim for in order to enable digital building permit. Related requirements are also proposed to reach such ambitions. They, together, represent a good overview on the thorough topic and summary of the related issues. The work presented in this paper contributes to the ambitions defined as T3 -Technologies for data visualization, data analysis and data manipulation -and R2 -Explicit specification of data requirements. Moreover, the requirement r11, related to the interoperability is addressed. Those are currently among the most investigated issues in the overall topic, since automatic checking of regulation is seen as the core premise for digitalization of the whole process [41]. However, the approach proposed in this paper brings a different perspective and points out new evidences, essential to develop new critical progress on the topic.

Methodology
A bottom-up approach was chosen to investigate the readiness of practice and to identify remaining issues. The definition of a methodology itself was formulated following iterative processes including consultations and feedback collection in a strong collaboration with municipality officers [42]. The steps of the overall methodology for the whole project are as follows: 1. Selection of a case study (Section 2.4) and two regulations to point out the necessary detailed steps and issues to be investigated; 2. Interpretation and formalization of two regulations 10 [42]; 3. Analysis of the available data produced by practice, to assess their suitability for checking the compliance to regulations by an automatic tool, and description of the most problematic aspects; 4. Implementation and test of a demonstrator tool relying on the IFC models as they are (i.e. coping with the weaknesses pointed out in the previous step) to check the regulations; 5. Scaling up the experience: guidelines and recommendations from the lessons learnt.
In this paper, the last three steps are addressed (Sections 2.1, 2.2 and 2.3 respectively) with main reference to the case study described in Section 2.4. We addressed the Step 2 in a separate publication [42].

Using IFC models from practice
We started by inspecting and analyzing how the necessary information is stored in the models that were submitted to the municipality from two different architecture firms.
The practice of building design and BIM follows criteria and best practices defined both within the design discipline itself and sometimes also by national guidelines. Meanwhile, the buildingSMART IFC 11 data model is defined as the reference standard for OpenBIM, which is therefore the desirable interoperable format to be used by all tools. However, designers can follow their own specific unofficial rules when modeling, and on the other hand, software can implement IFC in different ways (outside the influence of designers), so that we cannot straightforwardly expect the same exported product (i.e. complying with exactly the same part of the IFC structure, used in the same way) every time and in every case.
Only considering the IFC schema, assumptions can be made on which to base the computation of the needed geometry. For example, one can consider the modeling of storeys and their reference bounding boxes useful to calculate the building maximum extension, as well as to segment the building envelope. Moreover, a BIM is usually composed of several discipline-separated IFC models (i.e. the one storing architectural elements, the structural one, the installations and so on). It is necessary to know what information is found in each of them in order to calculate the correct geometry and envelope of the building: for example, all the facade articulations or the internal building elements, to compute paths and volumes and internal subdivisions. The measurement of some of such elements could be a reference when trying to infer the geometric features by tools using a simplified process. Another case is the assumption that the building elements are consistently modeled, with semantics correctly associated, as prescribed by IFC. However, those assumptions could be misleading and far from what is the design and modeling practice of architects (Section 3).
The models were manually inspected, with several aims: to outline the actual characteristics of the BIMs, both as consequence of the modeling practice and of the implementation and use of the IFC standard; to point out the related possible issues for their use within automatic tools; and to potentially guide the implementation. Commonly adopted BIM software and viewers were used for the inspection, namely Autodesk Revit 12 , the Solibri Model Viewer 13 , RDF IFC viewer 14 .

The checking tool
Based on the results of the inspection, a semi-automatic tool to check regulations was implemented. It was developed iteratively, based on the data typically present in IFC files, attempting to derive the required information based on a mixture of the geometry and semantics in the models. The tool is open source and available at https://github.com/tudelft3d/GEOBIM Tool.
While the tool is currently suited to the specific regulations implemented and their particularities, it shows general methods that can be reused for the implementation of other regulations. Currently, it supports checking of the dimension regulation, by means of the measurement of maximum height (Section 4.1); extraction of storeys profiles and calculation of reciprocal overlap (Section 4.2) and measurement of overhangs of the top part of the building with respect to the base (Section 4.3). The results of the processing tool were checked against the ground truth, as measured from the IFC models manually, by means of BIM and IFC viewers.
The implementation of an automated tool assisting with the parking regulation was currently deemed very difficult, for the reasons later explained.

Guidelines
Several guidelines must be provided in order for modelers to provide suitable data for automatic tools. The plain export of data to the IFC format is not sufficient: first, it is necessary to take care that information is not lost or damaged in the conversion from proprietary software formats [43]. Moreover, the choice of consistent semantics and a comprehensive filling of the information necessary for the use case is important, as well as the correct grouping of storeys and representation of spaces and apartments [40]. The critical aspects highlighted during the inspection of the models and revealed to be relevant for the implementation are listed as guidelines, addressed mainly to building information modelers, with a few suggestions also for city planners and geoinformation providers.

The case study and the chosen regulations
In consultation with the Rotterdam team, the planning zone "Centrum 3" of the Waterstad bestemmingsplan (destination plan) in the centre of Rotterdam was selected. The dimension regulation 15 and the parking regulation 16 were considered for the project. They were selected with the city-planners as most representative examples needing geometry processing and measurements very common in many city regulations (making the work worth to be replicated) and having advantage of the integration of BIM with geoinformation.
Solving the ambiguity points left by the dimension regulation text (here translated from Dutch) was the initial step of the project [42]: "The maximum building height is 100 meters, on the understanding that it can be realized with a lower building body of a maximum of 17 meters high and a construction, of a maximum of 50% of the surface of such building body, on the top of it. At the location of Boompjes 60-68 and Boompjes 55-58, an overhang of 5 meters on the Boompjes side and 10 meters on the Hertekade side is permitted".
The interpretation of regulation regarding the provision of parking places depending on the area of living units, was easier, since the logic was already formalized by the municipality officer in a spreadsheet application. Nevertheless, in real municipality practice, expert officers know that other factors (documented by further rules and laws or customs) have an influence on the count of parking places to be provided, adding further complexity. To check the regulation it is necessary to: Within the area, two buildings were recently designed, that were used as specific case studies for this project. The two respective BIMs were kindly provided in IFC (v.2x3) for the tests. The two models were delivered by the architects without following any requirements or Level of Information and geometry specification. Although providing previously such recommendations could solve some of the issues detected in this study, those models were chosen because, at present, the models are usually not following any requirements specifications but are being delivered as automatically exported by the authoring software. It could therefore help in formulating such Level of Information Need more effectively and aligned with practice. The first is the Peak Tower 17 , composed of a structural, an architectural and a facades model (Figure 1(a)). They are correctly registered together, by means of the same reference point and orientation. They are not georeferenced, though: the IfcCartesianPoint referenced by IfcSite, reports coordinates (0, 0, 0), whilst the RefLatitude and RefLongitude attributes in the IfcSite would locate the model in a general location in Amsterdam. The other BIM, representing the Terraced tower 18 (Figure 1(b)), is composed of a structural and an architectural model, plus one representing the context and elements probably belonging to the work site. They are correctly registered together too and the direction of the local Cartesian system of the model is correctly stored as TrueNorth attribute of the IfcGeometricRepresentationContext.

Results 1: Inspecting case study IFC models from practice
In the next subsections, the features of the BIM manually inspected are described as useful to check the considered regulations.

Maximum height measurement
Maximum buildings height was measured on the delivered BIMs. The results, i.e. 103.47 m for Peak tower and 100.46 m for the Terrace tower, were consistent with the values reported by the municipality building permit documents, already issued following a traditional procedure. Although such numbers are exceeding the prescribed limit of 100 m, they could be admitted anyway, since exemptions and derogation are foreseen in specific cases 19 . However, the non-compliance, as well as the possibility of obtaining a derogation, should be notified by the tool, and it could be implemented in future releases. The condition to the exemption, in this case, consists in the fact that the part exceeding the 100 m limit is mainly occupied by installations. By inspecting the BIM (considering the several models composing it all together) it is possible to verify this condition. If the semantics of the elements, and/or of the related spaces, were attached consistently to the IFC model, the check could be completely automated.

The subdivision of the BIMs in building storeys
According to the IFC schema, each IfcBuildingElement is contained within an IfcBuildingStorey, through the IfcRelContainedInSpatialStructure property. The entity IfcBuildingStorey groups the elements belonging to the same floor, approximately from slab to slab.
First option to detect the building parts could be to assume that the blocks are composed by a consistent and continuous stuck of IfcBuildingStoreys, seamless in facade. However, this is not exactly what was found in the models, both because consecutive storeys can be slightly staggered, although belonging to the same building part, and because it is possible that variations in facade happen within the same storey, which would make the approach inaccurate.
For an initial simplified solution, the bounding box of each storey could be considered as reference. But, again, the actual models present issues to implement such solution. In particular, when checking the grouping consistency in the models, it is apparent how the assembling of entities in storeys often presents issues (as previously experienced also in other IFC models) [40] such as: 1. One storey also includes elements belonging to different storeys; 2. They contain solely a handful of isolated elements that should be included in another storey at similar elevation; 3. The storey can contain elements that extend for two floors (e.g. Figure 2). The IFC standard suggests to break up walls at storey boundaries, but for other elements it is allowed that they span multiple levels (the IfcRelReferencedInSpatialStructure is introduced to signify this relationship). It is not a modelling error, although the measurements coming from such grouping would not be accurate.
To fix the cases 1 and 3, elements could be excluded from the grouping whether they do not fit within a buffer with respect to a reference height. Reference could be, for example, the Elevation attribute of the IfcBuildingStorey or a statistical parameter calculated among the barycentres of the IfcBuildingElements grouped in the storey. For fixing the case n.2 (isolated elements grouped as one storey) other criteria could be used, such as a minimum threshold to the number of entities included in a valid storey. Otherwise, comparisons between the bounding boxes of adjacent storeys could help in detecting such errors and exclude them.
An additional note is that the software exporting the IFC file usually considers all the elements at the same level as belonging to the same storey, therefore, the same floor of two different towers are grouped within the same IfcBuildingStorey.

Discontinuity detection criteria
The BIMs can be segmented according to the perception of vertical discontinuities by the human eye as in Figure 3, where it is possible to notice that the facades are articulated by the several elements, windows, and slight differences between the floors. The dimension of protruding parts, which are not perceived as a discontinuity in the building shape by the human eye, were measured on the BIM, as well as the parts that do represent a discontinuity. The result shows that a minimum change in extension of 5% between consecutive floors determine the segmentation of the building in different parts, as it happens in the Peak Tower as well. This minimum change is supposed not to be distributed equally among the different sides of the building (e.g. 2.5% per side), but to be the overall jump between two main vertical surfaces. However, the generalized geometry of the building has to be taken into account: in the case of Terrace tower, consecutive floors are staggered of a 5% each other, but when considering larger series, they can be gathered in one block. Therefore, accurate tools should automatically compare not only the coordinates of two consecutive storeys but they could group the floors based on their sequence and the variance of their extension with respect to the whole stack of storeys constituting the building.
The measurements of the heights of the segmented parts can identify which are part of the base and which ones belong to the top part. Another criteria to detect the two parts of the Peak tower could also be the separation of the part of building composed by only one contiguous part by the part split in the two towers.

Measurement of the 'base' height and the ceiling-slab-floor ensemble thickness in the facade
To check the maximum height of the base (limit 17 m), the maximum height of the higher storey composing the base can be read, or the minimum height of the lower storey part of the top. However, both could be inaccurate. Alternatively, the height of the lower surface of protruding parts of the building, seen as a ceiling from outside the building can be inferred by considering the distance between this and the floor height as stored in the Elevation attribute of the IfcBuildingStorey [44].
However, the thickness of the ensemble ceiling-slab-floor, based on which such distance can be set, is not straightforwardly known. For example, in the Peak tower BIM, 26th floor, the elevation of the IfcSlab is 81.61 m and of the lower surface protruding from the building (in green in Figure 4) is 81.02 m: the total thickness is therefore 0.59 m, while the slab is only 8 cm. Many design choices can influence such dimension (e.g. kind of construction and structural system, kind and amount of isolating materials, false ceilings, installation ducts or halls, specific facade systems etc.).
Therefore, it would be safer and easier to measure such height from the ground reference, rather than rely on assumptions. However, a very rough approximation between 0.6 and 0.5 meters below the Elevation attribute value of the lowest IfcBuildingStorey being part of the 'top' part of the building could provisionally work.

Storing information in different IFC disciplinary models
One BIM is usually composed by different disciplinary models (architectural, structural, installations, etc.), stored in different IFC files. For consistency, the recommendation is to consider all such IFC models together for the calculations. It is not possible to rely on only one of them since often the elements that a building design layman would consider as represented together are instead distributed in different models. For example, structural walls could belong to the structural model, without the architectural model including them. Therefore this last one could not be used by itself to compute paths or spaces. Moreover, structural (or installations) elements could extend until the facade. Using only one of the models may imply excluding relevant information that is available in one of the other models.

Storing information in the IFC models: semantics (in)accuracy
The consistent labeling of objects and the filling of useful attributes is also critical. The semantics in the models are compliant with the IFC standard. However, semantics could be differently assigned, either by the user during the design or by the implementation or mapping tables between the IFC schema and the internal data model of the software. Such inconsistencies could be due to an actual flaw, but they could also represent different interpretations of the IFC schema, in the cases where clear constraints or definitions are not present.
According to the inspection of the two models in the case study, it is not wise to blindly trust the semantics as stored in the IFC model. An example is the representation of balconies in the Peak tower BIM: with the slabs being IfcWalls (of course inconsistent representation) and an IfcRailing in its correct place. In other cases, some structural elements are labeled as beams but probably have a different function, since their main extent is vertical. This is one case where the plain translation of the label can be misleading (e.g. in Figure 5): a tie-rod can be called tie-'beam', but the structural function with respect to a normal beam is different and can possibly give issues when using the model for structural computations.
In addition, it is possible to notice that the elements to be counted in the building dimensions measurement could be various (including installations, chimneys, or IfcBuildingElementProxy, the general IFC entity to At present, it is hard to rely on either the ifcType assigned to objects or any further feature that could better define the role and function of each element such as the attributes 'loadbearing', 'material', 'isExternal' or the geometry itself. In fact, tools could be programmed in order to use those elements to infer the correct IFC class of each object and fix the model, within an automatic or semi-automatic procedure still foreseeing some user interaction. However, those features are irregularly used as well, and therefore an extensive work would be necessary to regulate the use of IFC, including attributes, explicit relationships and geometries, and, on the other hand, to develop a tool able to solve the remaining inaccuracies. More advanced techniques, such as machine (supervised) learning could also be considered in future to tackle the same issue. However, it is not possible at the moment, due to the lack of a sufficient sample of reference models to be used to train the algorithms as well as the lack of explicit agreements about the suitable use of the IFC data model.

Intersecting elements in the BIM
A further issue is about elements that intersect each other (walls and beams, walls and slabs, walls and doors, as a few examples) (e.g. Figure 6). This can be due not only to inaccuracy in the modeling phase, but also to the implementation of export algorithms in software. The consequence is that one cannot always rely on the geometry present in the IFC model, besides limiting possible automatic processing. Space3 Include single apartments (e.g. Figure 8); (a) (b) Space4 Includes the single rooms and balconies.
Looking at the spaces in detail, further unclear issues can be noticed. For example in the modeling of apartments (Figure 8), some of the internal walls are included and some others are not. Usually they do not include the thickest walls and the facade. Maybe this is due to the generation of spaces starting from one of the models (e.g. the structural one, or the architectural one), which make the modeling software refer to the information present there. Moreover, the same spaces (especially Space 4) are represented with many overlapping volumes, all starting from the slab, sometimes with different heights (e.g. until the top of the ceiling or at the walls height, etc.) but sometimes just repeated, which is unexpected, and would deserve to be investigated further with the help of designers. In other cases, IfcSpaces with the same label (stored as name and/or as type) can represent different spaces. On the contrary, redundant IfcSpaces representing the same volume sometimes are labeled differently, but without explicit rules. Finally, there are different spaces intersecting, but it is not possible to understand the different meanings of them and consequently if and why are they allowed to overlap.
Such a representation of IfcSpaces could be indispensable to more easily process the BIM automatically, although such a modeling is not a standard prescription nor official best practice (IFC foresee the representation of apartments as described in Section 5.1). In the case study models, either the attribute Name or type usually store the main semantics and codes. 20 However, there is no clear documentation helping in their interpretation, nor a standard classification is followed.
Alternatively, apartments areas could be extracted starting from the complete model of interiors, according to the paths allowed by the building elements dispositions. However, challenges would be involved ( Figure 9): Issue1 Parts missing (e.g. structural elements not in the architectural model); Issue2 Semantics wrongly defined (e.g. walls instead of doors prevent a possible algorithm to understand path/non path).

Representation of parking places
In the Peak tower BIM, the parking places are represented by means of IfcBuildingElementProxy, with Pset ProductRequirements → Category= Parking ( Figure 10). It is therefore possible to count them: they are 57, distributed on the two underground floors.
The bike parking places are represented as IfcSpace with Name "fietsenstalling". In addition, text is added to the model, reporting the number of bike places hosted in an area, but it is not stored as any attribute to be automatically processed, besides being a very undefined representation even for a human check (and the designer should be trusted, since the area is not drawn specifically).
In the Terrace tower architectural IFC model, one space includes the whole storey, labeled as "parkeren" and another overlapping one labeled as "stallingruimte (garage)", inclusive of both the area of parking places and the path for cars movement. 21 However, neither the slab nor walls dividing the space are represented, as probably included in the structural model.In addition, many boxes, (as IfcBuildingElementProxy) intended to represent parking spaces for bikes are overlapping, and therefore not reliable. Thus, it is not possible to proceed with the counting of parking places and check the regulation neither automatically nor manually by starting from the information stored in the IFC models.

Results 2: the implemented checking tool demonstrator
The implemented tool was developed to extract as much information as possible from the BIM overall geometries, without relying on the IFC geometries of the single elements and only in a few cases on the stored semantics. The open source code and executable can be downloaded at https://github.com/tud elft3d/GEOBIM Tool. Once downloaded, the .exe file can be launched directly, stored in the folder where the references files and folders are hosted (the .py files, the .yaml files specifying the parameters to use, and the folders where the results will be stored). An interface will allow the user to open, load and visualize the IFC file and use the tools. Some documentation, including a video tutorial, can also be found in the GitHub repository.

Maximum height calculation by the implemented tool
The tool measures the maximum height as the distance between the top of the BIM (the highest z value of the uppermost IFC element) and the bottom of the ground floor, intended as the value of the Elevation attribute of the IfcBuildingStorey representing the ground floor.
In order to consider the possible differences between aspect models, it is recommended to run the same tool on all the models and consider the highest value, since the starting point (IfcBuildingStorey.Elevation of the ground floor) should be consistent through all the models.
One more check should be necessary, considering the road elevation adjacent to such entrance, instead of the entrance itself. This will be something to be addressed within future work, when working with actual Geo and BIM integration.

Storey overlap calculation algorithm
This algorithm extracts the storeys profiles and calculates their reciprocal overlapping. From the obtained result, the groups of storeys composing the base and the top part are identified and their overlap computed.
A reference storey, such as the ground floor, must be selected, to be reference for the comparison to the other floors. Second, each building storey is cut by a horizontal plane whose height is set starting from the IfcBuildingStorey.Elevation 22 (Figure 11). The cutting height has impact on the inclusion of some facade elements of each floor, such as balconies ( Figure 12). Users can define the cutting height with respect to IfcBuildingStorey.Elevation based on their own requirements. The intersection with the building element geometries of each storey is stored as 2D polygons, from which the footprints are reconstructed. First step is to sample points every 20 cm in each edge of the polygon. Second, clustering those points by using the Density-based spatial clustering of applications with noise (DBSCAN) algorithm [45]. Finally, the concave hull of each point cluster is generated through the concave hull algorithm based on the k-nearest neighbors by (author?) [46] (Figure 13 At this point, the overlap percentage between the polygon representing the footprints of each floor and the polygon of the footprint of the reference storey is calculated by using polygon intersection. Table 1 gives an example of the results of the overlap algorithm run on the Peak tower BIM, with the ground floor (manually) chosen as the reference storey.
By setting a threshold in the percentage difference, it is possible to detect, either manually or by implementing an algorithm, at which floors the building can be cut in different parts.
If the base appears to include more than just the ground floor, the computation can be run again, by setting the reference storey consequently. At that point, any overlapping percentage larger than 50% related to the storeys on the top of the highest storey still part of the base would detect a potential non-compliance to the regulation.

Overhang distance checking algorithm
The overhang distance calculation algorithm is implemented by using IfcOpenShell [47] and the pythonocc library [48]. It consists of four steps ( Figure 14): selection of the base; extraction of the vertex from all the IfcObjects in the target floors using pythonocc; manual selection of the two highlighted lines of the base box, as the overhang calculation origins towards the two streets; calculation of the distance between each vertex and the selected lines. Then maximum values are the overhang distances towards the two direction ( Table 2).
The selection of the facade lines in the two directions was manual. Future developments should take advantage of the integration with geoinformation to compute such directions automatically.

BIM to GIS
Although a complex and complete integration of BIM with geoinformation was not performed, the geometry delivered within the BIM is extracted and generalized properly by the algorithm described in Section 4.3 to be reused in the update of 2D maps. In fact, either the georeferenced footprint of the building or the maximum outline of it, depending on the needs, can be saved as a Well-known text 23 files and easily added    to the city map ( Figure 15).
This allows a fast update of 2D maps whenever the building permit is issued. In addition, the use of the footprint together with the heights would allow modeling LoD1 representations by means of quite simple processing.

Results 3: Guidelines
According to the lessons learned from the investigation of the data (Section 3) and the implementation of the demonstrator (Section 4) , we propose here some guidelines.
In order to support the integration with the geoinformation for automating the checks, some information (accurately georeferenced in the national projected CRS) should be preliminary provided to designers: 1. Zoning parcels, stored with explicit attributes and unique identifiers related to the regulation text. For example, the regulation should be written as" "in parcel with code. . . a rule is valid", instead of "in Boompjes 50-59" as it is written now, in the dimension regulation that we considered.
2. City elements useful to assess the building in its context, such as terrain model, streets (useful in this case to detect the direction "towards" them, on which the regulation depends) etc. Each element should have unique consistent identifiers, better if written as a meaningful code for human interpretation, besides being a random string, to which the regulations could refer.
3. Accurately measured network of reference points with 3D coordinates (with approximated reciprocal distance of 50 m), to be used as control points in the georeferencing (and as check points to assess its quality in the most difficult cases).
Guidelines to planners are: leave as little ambiguity as possible in the regulation text; quantify the involved parameters as much as possible; and make reference to other information by means of formal identifiers (e.g. the code of the parcel or the streets). Those are premises to any further work about systematic formalization of regulations.
In order to produce suitable IFC models for automatic processing, some guidelines to BIM modelers are listed in Table 3. More specific instructions and constraints should be developed in collaboration with the modeling practice field and evolve in clear and formal Information Delivery Manuals (IDM) to explain the detailed information required in the models.
Guidelines and tools to help controlling the IFC file are also essential for storing the georeferencing properly [49,50,51], without which it is impossible to proceed to the integration with the city context.

N.
Guideline Aim

1
Group the objects external to the building in the IfcSite, separating them clearly from the elements which are part of the building (in IfcBuilding).
Avoid disturbance in the computation of the geometry of the building such as exterior envelope or bounding boxes.

2
Ensure the correct and consistent grouping of IfcBuildingStoreys avoiding and fixing misassignments (i.e. inaccuracies pointed out in Section 3.2).
Avoid disturbance in the computation of envelope and bounding box of the building, as well as the measurements of dimensions such as maximum and minimum heights. 3 Use correct semantics and avoid using IfcBuildin-gElementProxy. Support any automatic processing.

4
Model the elements properly, in order to avoid intersections. Support any automatic processing.
Support integration with geoinformation. 6 Model IfcSpaces consistently and with explicit criteria Help conversions and procedures involving the measurement of volumes and surfaces.

7
Model building units or zones as prescribed by the standard or by alternative methods, such as by Ifc-Spaces or IfcZones 24 , on the condition that they are explicit. Functions at the suitable level of hierarchy should be assigned consistently, preferably according to known classifications.
Support the detection and interpretation of spaces and related calculations.

8
Model the car and bike parking places explicitly (geometry and attributes) according to the prescription by buildingSMART of using IfcSpaces in association to specific properties 25 . Their effectiveness could be possibly discussed with architects and developers of the tools supposed to process the resulting BIM. Support automation of parking checks.

9
Register all the IFC models composing a BIM in a same (at least local) system (quite often it is current practice already).
Support automatically processing all the models consistently.

The representation of hierarchical building composition units according to IFC
Following the current IFC schema, to model apartment (or any cadastral unit), designers should use IfcBuilding 26 -CompositionType:'partial' composed by IfcBuildingStorey -CompositionType: either 'partial', 'element' or 'complex' (Figure 16). The floor area and volumes are supposed to be extracted from there (by the BIM software itself or by different tools), either gross or net, and stored in the respective attributes 'GrossPlannedArea' and 'Net-PlannedArea' in the BuildingCommon property set associated to IfcBuilding. In addition, in the 'Buildin-gUse' property set, attributes are foreseen to store the intended functions of the building and of the apartment under the 'MarketCategory' label, for which, however, a strict enumeration is not foreseen. Such a function is useful to check many regulations, among which the parking regulation treated in this project, but also others, such as the dimension regulation in other zones. For example in the Rotterdam zone 'Centre 2' 27 the allowed dimensions are calculated differently based on the intended use of the building units.
In IFC4 the representation of a more complex articulation of spaces was introduced by means of IfcSpa-tialElement 28 , as a superclass of IfcSpatialStructureElement. The IfcSpatialElement subclasses IfcExter-nalSpatialStructureElement and IfcZone were added as well. In particular, IfcZone is interestingly defined to model for example energy zones or fire safety related ones: "A spatial zone is a non-hierarchical and potentially overlapping decomposition of the project under some functional consideration. A spatial zone might be used to represent a thermal zone, a construction zone, a lighting zone, a usable area zone. A spatial zone might have its independent placement and shape representation" 29  The modeling of spaces as found in the case study models (Section 3.8) could help calculations, since a unique geometry mapping the useful volumes, and corresponding areas can be directly queried instead of being extracted by a processing (e.g. to compute the non-explicitly-represented volume between the represented walls of an apartment). However, it would be semantically inaccurate with respect to the IFC data model.
In any case, a codelist, likely an extension to the IfcSpaceType enumeration, could help storing the function and/or level of articulation of each space, which condition the rule applications (parameters often depend on the spaces functions) and the consequent automatic processing. In Appendix A, some suggestions are reported as a useful reference for the development of such enumeration.

Discussion
The adopted bottom-up approach allowed the insight into readiness of digital models as available from practice to automate the building permit checks. The outlined issues are common to most of BIMs generated in practice and solving them is the necessary starting point for the development of powerful and scalable methodologies, guidelines and tools supporting digital building permit.
This study began slow, since it was necessary to start from small basic points and experiment with the available data in order to achieve the necessary knowledge for formulating a suitable methodology, later implemented in a tool. However, it was not possible to skip such part, where the main value of this work lays: several basic issues, common to many processes and many regulations, had to be tackled and the problems had to be well-defined. The adopted approach allowed the achievement of a feasible solution, working in practice.
The tool developed within the project, although still in a demonstrator phase, is built on solid theoretical, open standard-based and data-based bases. This makes it effective and able to support the checks of the considered regulation. The tool was tested with several IFC models, besides the ones belonging to the two provided BIMs within the project, to check replicability.
The addressed regulations were chosen for requiring common checks and information extraction from the models: the check of the maximum height of buildings is quite common to any city plan, as well as the maximum extension and dimensions of the buildings. The other extracted information, such as the storeys' profiles, can be a useful base to check several parts of common urban planning rules (such as overlaps, covered surface, building overhangs, distance from other buildings and boundaries and so on). The extracted geometries can also be suitably used to quickly update the city maps. Many other regulations in Rotterdam, in Europe and beyond can have advantage of the tool performances.
In the case we considered, an Information Delivery Manual (IDM) 30 , which is the method provided by buildingSMART to define the necessary data requirements for specific data exchanges, and proper data requirements were not provided to designers. However, this represents a common situation in most of cases in most of countries. Therefore, such an analysis and inspection was a necessary step to understand the level of data readiness, due both to the designers confidence with IFC and modeling in BIM and to the way IFC is implemented in software. In fact, a recent study has tested the software support for IFC, in importing and exporting, demonstrating that several irregularities and errors can be produced due to differences in implementing IFC within tools [43]. Many of the issues encountered were actually due to mistakes and inaccuracies in modeling and exporting IFC, that could be more controlled by means of an Information Delivery Manual, but which are often still at a more general level of using IFC. Part of the value of this paper therefore lies in the description of this misalignment as an initial essential step. The guidelines that we propose are a relevant starting point to draft an IDM in future, that, however, will require more time. In addition, the use of IDM itself is still being improved and defined by buildingSMART, leaving space for future work implementing the findings of this paper into specific buildingSMART standards and procedures (MVD, IDM, Information Delivery Specifications 31 and so on). In fact, a complex process is necessary, starting from stakeholders' needs and requirement definition, explication of regulations and necessary information, data features and modeling practice, until the implementation in a software solution [53,54]. Although being a process in progress within some municipalities, including Rotterdam, the results are still far from being reached, due to several concurring causes to be solved beforehand (e.g. difficulty in re-planning the processes within municipalities, need of getting municipality officers involved in the process, need of re-skilling of practitioners, define regulations unambiguously and likely in machine readable languages, improve interoperability of data, which requires both guidelines and agreed standard use and implementation of fully supporting tools). For this reason, the guidelines provided in this study represent a valid provisional replacement of a complete IDM, likely coming in the future.
Besides the IDM, suitable Model View Definitions should be developed, i.e. the (implemented) solution designed by buildingSMART for software to export part of the modelled BIM compliant to a specified part of IFC. However, a current limitation of MVD mechanism is the difficulty in implementing custom views, useful for specific use cases, besides the example provided by buildingSMART. Moreover, few authoring software tools are able to use custom MVDs, that makes it even more challenging. For this reason, tools able to fix and further process the IFC models after export to make them better suitable for automated regulations checks would also be a valuable option for the future developments.
Moreover, pointing out the use of IFC in practice can be considered in the development of the standard itself. For example, the mapping of the IFC schema to national languages translation, would foster a more aware adoption of IFC-based tools in current practice.
A secondary focus was the insertion of the building model within the city context, in order to address specifically the parts of the regulations which require such connection, by means of the integration with geoinformation. However, the use of the IFC models as produced by practice presented more issues than expected, delaying the second (integration) step, which will be treated in future work more extensively.

Conclusions
The paper presents the investigation developed to support the implementation of a tool and a methodology able to assist the municipalities in building permits regulation checks by means of digital solutions. Starting points were the specific needs of the municipality and the involved data, including the regulations and digital standardized datasets (mainly IFC BIM) used directly as produced by architectural firms in practice. The approach, developed within a project with the Rotterdam municipality (NL) was completely bottom-up, referring to the data and practice experience as explained by the municipality operators.
Using specific and concrete data from a case study data sets, which are though representative of many models, allowed pointing out their most frequent issues. A minimum useful list of proper guidelines about the aspects to care during the data production phase were formulated based on them. First of all, human care by the designer is necessary. Therefore, an improvement in training and education of the involved actors (practitioners and operators) is necessary. In addition, a tool to validate the models (semantics and geometries), following clearer constraints, definitions and criteria would be useful.
The explication of the models' actual features was useful to guide the choices made when implementing the tool proposed in this study. The demonstrator works with initial solutions and promises to be further improved and scaled for actually supporting the municipality in the building permit task on a wider scale.
Moreover, it would be very helpful to developers and inspectors whether the models' features were both compliant to a previously delivered IDM and also systematically stored within attached metadata.
The extension of the research supporting digital building permit likely includes many possibilities, with the important condition of inter-sectoral and multidisciplinary collaboration to guarantee the success and applicability of future developments. complexity, each of these parts could be defined for specific use cases, and they would have different configurations based on specific needs. Some examples are the different zones for energy analysis, the volumes enclosing the walls for gross floor area calculation, the spaces including the spaces above the compound ceiling or not, which is possible to find now in the inspected BIM, and so on.
An investigation crossing a top-down approach consisting in the review and mapping of available classifications and a bottom-up approach considering the used values in regulations and models will be necessary to propose a working reference list of values.