Building data models form the foundation for most applications of 3D cities. Among the many building data models available, CityGML [1
] is used widely. CityGML was originally designed as an open framework that is not targeted at any specific application. However, it could be extended by users depending on the application. In the development of a 3D city, many application requirements are needed to analyze the core elements of buildings. Therefore, extending CityGML based on specific requirements has become a significant issue. Current extensions related to CityGML can be divided broadly into two categories, namely static and dynamic.
Static extensions expand the object structure in CityGML to represent the static phenomena in a 3D city. This type of extension can be further divided into two categories. The first category comprises extensions that are not aimed at any specific domain. Examples include the extension of 3D city development standards for specific countries [2
], topology-based extension [5
], and levels of detail (LOD)-based extension [7
]. The second category comprises extensions for specific domains, with a new object structure developed to represent a specific area. Examples of such extensions include immovable property taxation [8
], land administration domain model [9
], facility networks [10
], indoor objects [14
], building information modeling (BIM) [17
], historical buildings [19
], and computer-aided facility management [20
]. In this way, CityGML has been extended and several classic application domain extensions (ADEs) have been formed. However, these ADEs focus only on representing static spatial objects and do not consider the dynamics of the real world.
Dynamic extensions combine CityGML with a related mechanism or sensors to represent the dynamic processes in 3D cities. This type of extension can also be divided into two categories. The first is a combination with a specific mechanism, such as a noise model [21
], energy model [23
], flood model [28
], and others. With the second, CityGML is extended into a basic platform that facilitates dynamic changes to support multiple mechanism models [29
]. For example, Chaturvedi and Kolbe [30
] proposed a module named “Dynamizer” that uses time series data to represent the amount of change in related properties in CityObjects
. The data source of the time series data can be sensor observations, pre-recorded load profiles, or the results of simulation runs. With this extension method, CityGML becomes dynamic and can be used therefore to represent various dynamic phenomena related to buildings. However, even with this method, CityGML itself remains a representation of static information. The dynamic information essentially originates from the alteration of properties generated by the mechanism model or sensors, with CityObjects
acting only as the initial or background data.
Accordingly, the current extensions of CityGML still focus only on representing static scenes. Even when dynamic information is represented by a combination with a mechanism model, only the mechanism model represents the dynamics, with the building model remaining static. The development of BIM requires support for the evolution of buildings, as the state of the building object itself changes with time. Obviously, using the building data as background data for the dynamic mechanism model is not sufficient in such instance. Consequently, it is necessary to expand the dynamics of CityGML to enhance its interoperability with BIM.
In view of the above, Chaturvedi et al. [31
] proposed a version management approach to be added to the city models in the upcoming CityGML 3.0, with which to manage the history or evolution of the city models over time. This approach makes CityObjects
dynamic. However, this version-based approach still has certain inadequacies in representing the evolution process of buildings. An analysis of these deficiencies are as follows.
The main part of building evolution is the construction process. In contrast with evolution in nature, the evolution of the construction process is human-oriented and is based on a construction plan, i.e., the characteristics of the two processes differ.
First, construction is an evolutionary process that moves forward in stages. Each stage has a start and end time, and a number of regular cycles are repeated in a certain area. For example, from the perspective of building project management, the entire construction process can be divided into different stages, such as foundation, framing, roofing, and decoration (Figure 1
a). Second, at different time scales, a certain construction stage can be divided into a series of related sub-stages to reflect the hierarchy level. For example, at smaller scales, the construction stage for framing can be subdivided into multiple sub-stages, such as the construction of the first, second, and third story. These sub-stages cycle through similar work at a smaller time scale (Figure 1
a). Third, the professional division of labor in these different stages is clear. Each work type cooperates with others and alternates depending on the relationship between different types of work. The execution of one or more individual construction activities simultaneously causes or requires other activities to happen. For example, as regards the construction of the frame, the construction of the third story cannot start before the second story is completed. Similarly, the third story provides support for the construction of other building elements on the fourth story and above.
The version-based approach proposed by Chaturvedi et al. [31
] essentially uses the timestamp to manage the snapshot of CityObjects
at various time points. However, this approach has difficulty in comprehensively representing characteristics such as the stage, hierarchy, and correlative of the construction process. Furthermore, although several spatiotemporal data models are available in geographic information systems (GIS), it remains fundamentally difficult to comprehensively represent the above features in the construction process.
Regarding BIM, IFC (industry foundation classes) defines the objects involved in the life cycle management of buildings, with the schema being rich and extensive. Based on the IFC model, researchers have constructed 4D models to realize engineering simulations [32
However, simply copying the relevant objects of the 4D model in the field of architecture, engineering and construction (AEC) into CityGML is not a viable solution owing to the related fields of AEC and the 3D city having different focuses. The 4D model in the field of AEC focuses mainly on engineering design, mechanical design, construction planning, scheduling, and cost estimating [32
]. However, at the city level, these are not the concerns, as the focus is on efficient and accurate simulation of the building evolution process at multiple spatiotemporal scales. The concrete manifestations are as follows: (1) At the city level, the amount of data is larger. If the finest granularity is used to simulate the construction process at all scales, it will significantly affect the efficiency of the model (this is why CityGML needs to define LOD of the city objects in the model). (2) At the city level, the objects concerned in the construction process differ from those of the 4D model in the AEC field. Information, such as labor or cost in the 4D model is no longer the focus of the building evolution process at the city level. If this redundant information were added to the CityGML model, it would detrimentally affect the efficiency of the model. (3) A specific problem occurs in the 4D model in the association between the process and building objects. Using the core standard IFC in the 4D model as an example, in IFC, it simply associates the process with the building objects by employing the relationship IfcRelAssaignsToProcess.
However, it does not express the evolutionary behavior (such as adding, removal, merging, and change) of the objects in the process. As an example, after completing the decoration of the building, the scaffolding must be removed gradually, i.e., typical object removal behavior. However, the association mode of process and objects in IFC cannot express this behavior, making it impossible to accurately simulate the details of the building evolution process.
In summary, how to simulate the building evolution process efficiently and accurately at the city level is the core problem that this study aimed to and, indeed, managed to solve. It is necessary to consider this problem from a different perspective and create a corresponding logical model of the building construction process for CityGML. We accordingly developed such a logical model to support the dynamic representation of the construction process of building objects. The remainder of this paper is arranged as follows. The research framework is introduced in Section 2
. In Section 3
, we explain the basic logical structure of the building construction process, based on different characteristics. The building construction process is subsequently extended as a CityGML application domain extension (ADE). In Section 4
, we present the implementation of the model through a case study and the discussion of the results. The concluding remarks are presented in Section 5
2. Research Framework and Scope
The construction process of a building obviously differs from the evolution process in nature in that it is a process that transforms nature under the leadership of human beings, with this transformation taking place in stages, and being hierarchical and correlative. Furthermore, differing from the construction process in the AEC field, the construction process at the city level involves a broad spatiotemporal scale and a larger amount of data. As the 4D model in AEC cannot accurately and efficiently express the building evolution process at the city level, the difficulty is finding a way to do this. Solving the problem, i.e., constructing a suitable model, requires solving the following problems, namely, the model must express the basic characteristics of the construction process, which are stage, hierarchy, and correlation. It must accurately express the building evolution processes at multiple spatiotemporal scales, and it must accurately express the behavior of the building objects, which are adding, removal, merging and change, during the evolution of the building.
In project management, the critical path method (CPM) [34
] is used typically to represent a construction project. Among these methods are the arrow diagramming method (ADM) and the precedence diagram method (PDM), which can effectively represent each process and its corresponding relationships. The difference between these two methods is that ADM uses arrows to represent activities, whereas PDM uses nodes. In fact, they are similar in representing a construction project and one can be converted to the other. The construction activities are the driving forces of the building construction process. Considering that people are more accustomed to using arrows to represent the driving force of a certain process, this study chose ADM as the basic logic model to represent the building construction process.
Based on this, we organized the research framework in the following way. First, the characteristics of ADM that are commonly used in construction were analyzed to identify issues that needed further attention to represent the building construction process. Second, the identified issues were addressed, and an extended logical model was constructed to represent the construction process. Then, an extension for CityGML was developed based on the logical model. Finally, a BIM model was used as a data source to implement this ADE. Figure 2
illustrates the research framework.
The construction process of building projects is complicated and systematic. The process can be divided into different time periods based on the division of labor and materials, including foundation, framing, roofing, decoration, water supply and drainage, building electrical, intelligent building, and ventilation and air conditioning. The first four steps of the building construction process are related to the civil engineering stage that forms the core of the building project. It outlines the overall appearance of the building, and its construction process exhibits strong regularity. In addition, the overall appearance, which is an important aspect of the building, is very closely associated with the geographical environment. Therefore, in this study, the civil engineering stage of the building is selected to be the subject of research. However, information on resources required in the civil engineering stage, such as labor and funding, are not considered in this research.
3. Design of Building Construction Process ADE
3.1. Characteristics Analysis of Basic ADM
The basic ADM (Figure 3
) is used generally to represent the construction project with arrows and nodes. An arrow represents a construction activity that requires manpower and material resources. The left end of the arrow indicates the start of the construction activity and the right end indicates the end. A series of attributes, such as the job title and working time, can be attached to an arrow. The dashed arrow is a special type that does not represent an activity that requires time and resources but rather a logically restrictive relationship. For example, activity E in Figure 3
indicates that activity D can be performed only after activities B and C have been completed. A node is the connection point between arrows in an ADM. It indicates the time that work can be carried out after the pre-order work associated with a certain node had been completed. Nodes can be classified as starting, terminal, and intermediate. Starting and terminal nodes are unique within the model. The starting node represents the start of the entire process and the terminal node represents the end.
The ADM is suitable for representing the stage characteristics of a construction process (Figure 4
). Each activity (arrow) has a corresponding relationship with each construction stage by associating two nodes of the model. The front node can represent the state of building objects when construction activity has not started, and the end node can represent the state after the activity has ended. The start and end of each activity precisely correspond to the continuous development of a construction process.
In addition, the ADM is suitable to represent the correlative characteristics of a construction process. For example, Figure 5
shows the pre- and post-constraints for the classic staged construction workflow. Activities a2 and b1 can be performed after a1 had been completed, whereas a3 can be performed after a2 had been completed. After a2 and b1 had been completed, b2 can be performed. Finally, b3 can be performed after a3 and b2 had been completed.
Although the ADM supports the stage and correlative characteristics of a construction process, some problems remain that must be eliminated. First, the ADM does not have hierarchical characteristics and cannot represent the construction process at multiple spatiotemporal scales. Second, the relation mode of the ADM to building objects must be defined that can express the behaviors of adding, removal, merging, and change of the building objects in the construction process. Third, the ADM only represents the construction plan; therefore, to represent the evolution process of construction, an extension is required for the flow mechanism so that the construction process can evolve automatically. Therefore, the ADM is extended as follows. First, the hierarchical characteristics are extended. On this basis, the association mode of the process and building objects is studied. Third, the driving mechanism is designed to automate the process. Finally, CityGML is extended to realize a building construction process ADE (BCPADE).
3.2. Extension of ADM
3.2.1. Hierarchical Extension of ADM
Objects at a distance from the user’s viewpoint are shown coarsely, whereas close objects are shown in a detailed representation [35
]. Therefore, multi-resolution data can efficiently support the city-level process simulation. The LOD of the spatial data model play a significant role in numerous fields, e.g., CityGML uses the LOD model to express 3D city objects at different scales. With the support of the LOD model, a high-resolution visualization model for close-up observation can be provided. Similarly, at a considerable observation distance, the low-resolution model is used to optimize the amount of data in large scenes, thereby improving the efficiency of the data display in such large scenes.
Time and space have similar multi-resolution features. When an object must be observed continuously, the number of observations of the object will increase as the degree of attention increases, thereby shortening the observation interval and increasing the observation frequency. Observers with different degrees of interest will have different observation frequencies for the same object, resulting in different time scales.
Furthermore, there are different scales in the building evolution process at the city level. In the far perspective, the concern is with the evolution of multiple buildings in a large scene. The observation frequency of the single building evolution process is relatively low and results in a low time resolution. In a relatively close perspective, the evolution of the local part of the building can be seen. In this instance, the observation frequency of the single building evolution process is relatively high and results in a higher time resolution. If the same resolution is used to simulate the process model at different time scales, the efficiency of the model will be affected considerably. Therefore, the concept of LOD needs to be introduced to the spatiotemporal process at the city level, and a process levels of detail (PLOD) needs to be created for the building construction process.
The analysis presented in Section 1
shows the hierarchal characteristics in the construction process, and the PLOD can be defined based on these hierarchical characteristics. Different levels of focus produce different time resolutions for the construction process. Regarding urban planning managers, their focus is on the start, construction, and completion of the building, which can be seen as the most coarse-grained level of detail in the construction process. Regarding the leadership of the construction company, their task is to coordinate the various divisional projects, including foundation, framing, roofing, decoration, and other details. To execute the construction tasks of each of the above divisional projects, the principals of the various departments of the construction company need to formulate their own construction procedures for each divisional project. For example, the construction of the framing can be refined into the successive construction procedures of the structure of each story. The construction of the structure of each story can be refined further into detailed construction activities, such as the installation of scaffolding, binding of steel bars, installation of formwork, pouring of concrete, and the like.
Based on the above analysis, we proposed a PLOD hierarchy for the building construction process, including four levels of details. These are:
PLOD1: Pay attention to the beginning and end of the project, and not to the intermediate process, i.e., it can only express the start and the end of the project. At this level, the overall outline of the building can be seen, but not the details such as doors and windows.
PLOD2: Pay attention to the divisional projects, i.e., it can express the divisional projects of the building construction, including foundation, framing, roofing, decoration stage, etc. At this level, the facade can be seen, as well as the detail of the building elements on the façade such as doors and windows.
PLOD3: Pay attention to each procedure in the divisional project, e.g., the construction of framing can be refined to the construction of each story. At this level, the construction process of each story can be expressed and the building elements inside the stories can be seen.
PLOD4: Pay attention to the construction process in each procedure. At this level, the construction details of the relevant building elements can be seen, such as the installation of formwork for beams.
An example of the hierarchical structure for PLOD1, LODP2, PLOD3, and PLOD4 is shown in Figure 6
The PLOD model characterizes the characteristics of the different levels of the construction process and forms a hierarchy that combines local construction changes with overall construction changes. It forms the basic time scale of four different levels of detail in the construction process.
Based on the above analysis, the ADM model was extended hierarchically, as follows.
The process model was divided according to different time scales and has a hierarchical structure.
Objects such as activities and nodes were based on a specific time scale. Objects at a lower level can be aggregated into a higher level.
Objects at a higher level have coarser granularity and are more macroscopic, whereas objects at lower levels have finer granularity and are more microscopic. The higher and lower levels of the model are related by activities, i.e., activities at a higher level can correspond to a lower-level process. With further division, more microscopic activities and nodes can be added to a process. For example, Figure 7
shows that ActivityA in the higher-level process P1 can be related to sub-process P1-A, and activity ActivityA1 in sub-process P1-A can be related to sub-process P1-A-A. The activities in the sub-sub-processes can be iterated further.
3.2.2. Association of the Construction Process and Building Objects
Building objects play an important role in the construction process. They comprise building elements such as walls, columns, beams, and floors, and building spaces such as buildings, stories, and rooms. The building objects need to be related to the construction process itself to simulate the evolution process of construction. The associating of building objects with the construction process is done in the following way. The model is divided into two layers, namely evolution and object. The evolution layer mainly describes the corresponding stages of the construction process and their relationships. The object layer mainly describes the building objects associated with the construction process (Figure 8
A problem that needs solving is how to relate the building objects to the construction process. Two principal issues must be solved, namely (1) whether to use a node or activity to associate building objects, and (2) how to express the evolutionary behavior of the building objects during the evolution process.
Regarding the first issue, it must be considered that in an ADM, each construction activity corresponds to a change in the building objects in a one-to-one relationship. However, each node may have more than one pre-order activity, which means that a node and the alteration of building objects may not have a one-to-one relationship. For example, node 5 in Figure 5
corresponds to two pre-order activities, a3 and b2, and the alteration of building objects may, therefore, be related to a3 and b2. Therefore, we should use activities to associate building objects.
Regarding the second issue, analysis of the behaviors of building objects in the process of building evolution indicates that the following four behaviors generally exist in the process of building construction [36
Newly constructed, which are objects newly constructed in an activity (e.g., newly constructed building elements such as walls, doors, and windows).
Removed, which are objects removed from the building in an activity (e.g., removal of the formwork after the concrete is poured).
Merged, which are objects merged into other new objects in an activity (e.g., in the construction of stairs, side beams, steps, handrails, and railings are merged into flights of stairs).
Changed, which refers to the alteration of the geometry, position, or attribute information of the objects in an activity (e.g., the color of the wall changed after being painted, or the position of the building elements changed after being moved).
Therefore, when information on the amount of change in a building object is being saved, the above four behaviors must be considered and the corresponding dataset must be maintained (Figure 9
The PLOD model we proposed defines different time scales for the construction process. At the same time, CityGML developed five LODs for city objects at different scales. Therefore, under the basic process/object association framework described above, it is necessary to consider the association between different PLODs and the original LODs in CityGML.
According to the definition of PLOD, PLOD1 is the coarsest level of detail in the construction process, focusing on the overall changes of the building, the detail building elements (such as windows and doors) cannot be identified at this level. Therefore, the building objects associated with this level best match the LOD2 in CityGML. PLOD2 is finer than PLOD1 and can be refined to the outer facade of each building story. The building elements such as doors and windows on the façade can be seen in this level. Therefore, the building objects associated with this level are most consistent with LOD3 in CityGML. PLOD3 is refined into the construction process inside each story, and all the building elements inside the building can be recognized at this level. Therefore, the building objects of PLOD3 correspond to LOD4 in CityGML. PLOD4 is the finest detail level in the construction process, involving the manufacturing process of building elements. For example, when a reinforced concrete structure is constructed, a joint cast-in process of columns, beams, slabs, and the like is performed. This level is finer than LOD4 of CityGML and requires further extension. A summary of the correspondence between the building objects involved in the PLOD model and the LOD model in CityGML is displayed in Table 1
3.2.3. Driving Mechanism of the Model
A driving mechanism needs to be introduced to the model to simulate the construction process, which requires a further extension of the model and a definition of the flow rules.
a) Further Extension for the Driving Mechanism
The current model has four major parts, namely process, node, activity, and associated building object. To simulate dynamic changes in the construction process, objects that trigger the process flow of the model need to be introduced. Considering that, during the construction process, each activity is triggered by a certain event, an event object can be added to the model to trigger the automatic flow of the model. Consequently, the model eventually consists of five elements, which are process, activity, node, event, and building object. The relationships between the process, activity, node, and event are defined as follows (Figure 10
A process consists of activities, nodes, and events.
An activity can be triggered by an event.
The state of a node can be changed by an activity.
An activity can be associated with the sub-processes of the next level.
b) Evolution Rule of the Construction Process Model
During the construction process, often subsequent activities cannot be started because the pre-order activities have not been completed yet. To represent this situation, the following restrictions were added to the model. First, a node can have one of two states, namely ready and sleep (Figure 11
). When all pre-order activities of a single node have been completed or the node has no pre-order activities and the subsequent activities have not all started yet, the node is in the ready state. When some or all of the pre-order activities of the node have not been completed, the node is in the sleep state. When all subsequent activities of the node have started, the node returns to the sleep state.
Second, the subsequent activities of a certain node can be triggered only when the related node is in the ready state. This ensures that if the pre-order activities have not been completed, the subsequent activities do not meet the starting conditions and can only be triggered when the pre-order activities have been completed. For example, in Figure 12
, as node 2 is in the ready state, the subsequent activity B can be triggered by an event. As node 3 is in the sleep state, the subsequent activities 4 and 5 cannot be triggered by an event. As the subsequent activity A has been completed, node 1 has returned to sleep and activity A will not start again later.
c) Driving Algorithm of the Process Model
The driving algorithm of the process model is as follows.
Wait for an event to trigger before going to the next step.
Look for an associated activity A and the associated pre-node N of this event. If node N is not in the ready state, end the process and return to Step 2. Otherwise, go to the next step.
For node N, find the subsequent activities and ascertain whether they are all running or finished. If they are finished, set N to the sleep state.
Start the activity. When the activity ends, proceed with the next step.
Find the subsequent node of the activity. For the found node M, find all pre-order activities to ascertain whether they have all finished. If so, set M to the ready state and go to the next step. Otherwise, return to Step 2.
Determine whether subsequent virtual activities are associated with M. If so, launch the virtual activity directly. If no subsequent non-virtual activities are associated with M, set it to the sleep state. For each virtual activity, proceed with Step 6.
Return to Step 2.
As an example, Figure 13
shows a fragment of a construction process. At the start, the pre-order activities of nodes 1 and 3 are assumed to have been completed, and they are in the ready state (Figure 13
a). Once an event triggers activity A to start, node 1 goes to sleep. Next, when activity A is complete, the subsequent node 2 is in the ready state, and the subsequent virtual activity is automatically triggered. When the virtual activity after node 2 is triggered, node 2 returns to the sleep state (Figure 13
b). An event then triggers activity B to start, and node 3 changes from the ready state to the sleep state (Figure 13
c). Next, when activity B is complete and the pre-order activities of node 4 are all complete, node 4 transits to the ready state (Figure 13
d). After the start of activity C, node 4 is still in the ready state because the subsequent activity D of node 4 has not yet started (Figure 13
e). Finally, activity C is complete and node 5 transits to the ready state. Then, node 4 changes to the sleep state after activity D starts (Figure 13
3.3. Building Construction Process ADE
shows a Unified Modeling Language (UML) diagram that represents the BCPADE in CityGML. The diagram is divided into two parts, namely the construction process model and the building model. This is an extension of the original building data model of CityGML. The original model does not include structural elements in the construction process, thus, the extension includes structural elements such as columns and beams. When the building is under construction, objects such as rebar, bracket, formwork, and scaffolding are closely related to the building construction process, they are also added to the original model as the auxiliary objects. The classes BCPBuildingElement
have been newly created to correlate all _BoundarySurface
(newly created as the subclass of _BoundarySurface
for auxiliary objects) objects in CityGML for association with the building construction process.
We created a new class _BCPBuildingSpace to correlate the building objects that contain a space, which are the super classes BCPBuilding and BCPRoom. Considering that buildings are organized predominantly by stories, the class BCPStory was added to the building data model, which is also the subclass of _BCPBuildingSpace.
In addition, we created class _BCPBuildingObject as the super class of _BCPBuildingSpace and BCPBuildingElement, used to correlate directly with the construction process in a uniform manner. To maintain the hierarchical relationship of the original classes in CityGML, the newly created classes BCPRoom, BCPStory, and BCPBuilding were used to derive the class _BCPBuildingSpace, and the original classes Room and _AbstractBuilding in CityGML are aggregated by them.
A process consists of three elements, namely nodes, events, and activities and they have common attributes such as the id (unique number of an object), name (base name of the object), and level (basic spatiotemporal hierarchy to which the object belongs). Activities at a higher level can be associated further with lower-level processes, which also comprise objects such as events, nodes, and activities.
In addition to the above common attributes, each object has its own specific attributes. For nodes, typeNum indicates whether a node is the starting node (value 1), the intermediate node (value 2), or the terminal node (value 3) of the construction process. The description presents the basic information of a node. The readyState of a node can be 0 (ready) or 1 (sleep), which is a key attribute that constrains the relationship between nodes and activities. The alteration of the state of a node is determined by the pre-order and subsequent activities. At the same time, it also determines whether the subsequent activities of the node can be triggered by corresponding events. Finally, preActivities associates the node with pre-order activities, whereas subActivities associates the node with subsequent activities.
Activities are transition objects. First, they link the process model and building objects. They relate to four object-change types, namely added, removed, merged, and changed. Second, the subProc attribute allows an activity to be associated with a lower-level construction spatiotemporal process. The virtual attribute indicates whether an activity is real or simply represents a constraint between nodes and activities. Because each activity of a construction process is related closely to time, time is an important attribute and can be divided into planned and actual types. Finally, the attribute desNode associates the activity with a subsequent node, and the attribute finishState has three values for a started activity, which are 0 (sleep), 1 (running), and 2 (finished).
Events are the driving force for the entire construction process and are associated with the previous node by the preNode attribute. After an event occurs, if the relevant node is in the ready state, a relevant activity denoted by the relActivity attribute is started to facilitate the flow of the construction process. In addition, an event contains an occrTime attribute that identifies when it occurs.