As introduced by buildingSMART, the IFC 4 release contains major changes in scope of coverage. IFC 4 incorporates more features such as modeling of structural steel and timber, site planning and 5D modeling than IFC 2x3. IFC 4 also highlights the newly added entities that are related to green building design (energy analysis, environmental impact) and GIS (coordinate system transformation). As IFC keeps expanding, it is anticipated that it will add more entities to represent data from different domains in order to truly serve as a common data schema in the AEC industry (Amor and Ge 2002). However, the expansion of IFC also brings a critical research question about the evaluation of domain-specific changes in IFC. The following challenges must be tackled to answer this question: first, to identify GIS domain related classes in IFC, such as IfcMapConversion; second, to evaluate these domain-specific entities in order to know whether IFC covers all the required information for the GIS domain; and finally, based on these findings, to develop an extension to IFC for the GIS domain.

We try to evaluate the changes in IFC 4 as compared to IFC 2x3 for the GIS domain. The domain-specific terminologies were first constructed from domain schemas using text-mining techniques. The GIS domain related classes in IFC 4 and IFC 2x3 were located using these domain-specific terminologies. Then a program we developed to detect the version differences between IFC schemas scanned through these filtered entities and detected version changes for them (i.e. added, deleted, merged). The extension to IFC4 for the GIS domain was then developed.

In the generation process of domain terminologies, we used TF IDF as the automatic filtering measure. We neglected the first 100 words with higher frequency reported in IFC documentations and also neglected the words with IDF<1 (i.e. appear in more than 10% of IFC documentation). Before the manual filtering, the corpus from the GIS domain automatically generated 271 words. After manual filtering, the numbers of valid domain terminologies was 128, which means an accuracy of 47.4%. This result also complies with the observations made in Velardi et al. (2001). The low accuracy of the terminology generation for corpus in the GIS domain is due to the schema definitions of CityGML. In CityGML, many entities are used for representing the basic geometry features.

The total precision for filtering entities for the GIS domain is 78.20%. The filtered entities were validated manually based on the following principles: first, keep entities that are representing real world concepts and are domain related, such as IfcMapConversion; second, keep enumeration and selected types that are related to specific domains; and third, neglect entities that are representing values of objects, which are common for every domain. The high precision of the result shows the effect of the filter design.

As shown in the figure, we developed a new ontology. Since a domain terminology list was generated for the GIS domain, it is possible to identify not only what are contained in IFC 4, but also the missing items to represent the domain concepts in the schema. With reference to the domain terminology list, we identified a number of concepts that were not hit by any entity definitions in IFC 4 for the GIS domains. For example, for all the 128 domain terms in GIS, there are 69 terms that were not hit by any definitions of IFC classes. It shows that the newer version of IFC cannot fulfill the data modeling requirement for GIS as compared to the domain schemas. Analyzing these zero-hit terms could provide a clue for further development of IFC towards complete modeling of the GIS domain. The results of the zero-hits mainly refer to road, railway and tunnels for the GIS domain. Based on the zero-hit domain terminologies and the schema of CityGML, we proposed an extension to the IFC 4 schema. The extension to the IFC schema for GIS is added mainly in the domain layer and the interoperability layer.

In the mapping between IFC and CityGML, the number of entities to be compared and inspected is large, and therefore computer-aided semi-automatic ways would be needed. There are 1008 IFC entities and 608 CityGML entities defined in the schemas. If we simply inspect existing instances, the mapping between IFC and CityGML might not be fully discovered. The complexity of the data standards requires the development of ways to perform semi-automatic mapping considering the context of the entities. A  linguistic-based methodology framework was proposed first for semi-automatically mapping BIM and 3D GIS schemas. The linguistic-based method uses text-mining techniques to discover the relatedness of entities through their names and definitions. Component-based manual inspection generates the results for validation of the linguistic-based method.

The linguistic-based method uses results of text mining techniques to perform relatedness analysis and facilitate the mapping discovery process. The entity definitions in schema documents were extracted and compared to entity definitions in the other schema. Pairs with higher similarity results are likely to be the identical or related. To evaluate the similarity of the entity definitions, Cosine Similarity, Jaccard Similarity Coefficient, and Market Basket Model were used.

The first step for the calculation is entity definitions extraction. There are 1008 entities in the IFC schema, and all of them have descriptions and definitions. For the entities in the CityGML schema, considering their referencing to the GML schemas, 607 entities with definitions were found in the documentation of the CityGML and GML schemas. All the 607 entities have descriptions and definitions, which could be extracted directly from these schemas because the CityGML schema is represented in XSD (XML Schema Definition) format.

The second step is the tokenization of the entity definitions. All the stop words in the entity definitions were removed and the remaining text was stemmed for further calculation. Stop words are those that occur so frequently that they may not be as relevant to the query as the query to the whole document (Strzalka et al. 2011). Some commonly seen stop words are “is”, “for” and “to”. The remaining text in the definitions was then stemmed. Stemming is the process to change words to their stem or base form (Willett 2006). The stem of a word is not similar to the morphological form of the word, but it ensures all related words have the same stem. The Porter Stemming algorithm was adopted in this study to find the stems (Willett 2006).

The third step is to formalize these stemmed definitions into feature vectors for further analysis. The feature vectors were generated as: if concept n (e.g. window) appears m times in the definition, the n-th value of the feature vector of definition would be m. Besides the consideration of Term Frequency and Inverse Document Frequency, the entity names were also considered for the comparison. According to (Lipman 2009), some mappings can be discovered directly by comparing their entity names. Certain entity definitions do not repeat the entity names, so name comparison should also be considered. All the entity names were split into phrases and the “ifc” and “gml” prefixes in entity names were removed. For example, the entity name “IfcWallStandardCase” was split into “wall standard case” and then tokenized and stemmed . The entity names were compared to other entity names as well as entity definitions and different weights were assigned to different comparisons.

The proposed linguistic-based semi-automatic mapping framework was implemented on a platform we developed using Java. The platform mainly consists of three parts: (1) parsers for XSD (XML Schema Definition) files of the CityGML schema and HTML files of the IFC schema, (2) a similarity comparison engine that calculates different similarity scores, and (3) a program that reports the comparison results to a spreadsheet and generates mapping candidates. XSD files are represented in the XML format and therefore could be parsed by standard XML parsers. In this part of research, the open-sourced JDOM 1.1.2 (Hunter and Lear 2012) was used for developing the parser for XSD files of the CityGML schema. For the IFC schema, definitions of IFC entities were extracted from the IFC documentation HTML files (buildingSMART International 2007) using a HTML parser that was also developed based on JDOM. Tokenization of entity names and definitions is needed before similarity comparison can be conducted. In this study, the Porter Stemmer in Apache Lucene (Apache 2012) was used for the tokenization process. After tokenization, a table of all the distinct tokens in entity names and definitions was generated, which was used for generating feature vectors for similarity comparison.

As shown in the figure, the linguistic-based method can generate reliable mapping candidates. The linguistic-based method compares the definitions and names of entities to generate mapping candidates, and entities referring to the similar content will have similar descriptions. The recall at the ranking threshold can reach 0.375, which means that by inspecting the first 100 candidates from the result, we could find 37.5% of the true matches. Considering the large number of entities in IFC (1008) and CityGML (607), the results from the linguistic-based method narrow the search space and reduce the human effort for mapping discovery. The linguistic-based method does not require the domain knowledge. As the methodology suggests, the linguistic-based method is performed on the basis of syntax comparison, in which people need not to know all the terminology from both domains. This feature of linguistic-based method indicates that it could be further applied to other schema mapping problems. Moreover, the Term Frequency and Inverse Document Frequency are also applied in the process, which generate a dictionary of words used in one domain and there frequency. This terminology pool could be further analyzed and used for other schema mapping problems. The linguistic-based method could also suggest candidates for 1-to-M mapping. The traditional mapping methods on the entity level only considers the entity names and may not be able to find mapping between one entity and many entities. For instance, the entity “AbstractOpening” in CityGML could be mapped to “IfcWiindow” or “IfcDoor”, but the mapping could not be discovered by name to name comparison. The linguistic-based mapping, which utilizes the definitions of entities, could broaden the scope of comparison and generate more 1-to-M mapping results. Another example from the linguistic-based mapping is the mapping between “AbstractBoundarySurfaceType” entity in CityGML with IFC BRep entities such as “IfcBoundedSurface”, “IfcFaceOuterBound”, “IfcFaceBound”, “IfcBoundingBox”, and “IfcClosedShell”. The 1-to-M mapping could be discovered in a threshold of 25.

Among all the common 3D GIS standards available nowadays, the City Geography Markup Language (CityGML) has the most sophisticated definition about LoDs. CityGML is a common modeling language for 3D city objects launched by the Open Geospatial Consortium (OGC) in 2008. CityGML defines city objects such as buildings and infrastructure in terms of topographic object information, semantic information and appearance properties (Gröger and Plümer 2012).  CityGML also supports five distinct LoDs for buildings in city models ranging from 2.5 dimensional regional models (LoD0) to detailed building models with interior information (LoD4). The LoDs in CityGML contain many features such as building interiors and furniture that LoDs defined in other GIS schemas do not. CityGML defines five distinct LoDs for efficient visualization and data analysis (Gröger et al. 2012). Different LoDs can be stored for the same object simultaneously, which provides different resolution for viewing and analysis. Although the official CityGML Encoding Standard gives descriptions about each LoD, no clear definitions were offered, so users often create models in different LoDs according to their own understanding. In addition, the CityGML Encoding Standard did not provide methods to transform between LoDs.

To achieve a complete and accurate transformation between LoDs in CityGML, this study first gives precise definitions to each LoD in CityGML, which are not provided in the CityGML Encoding Standard. A new exterior shell extraction algorithm is proposed to simplify buildings with interior features. The transformation between LoDs is thus completed based on the new exterior shell extraction algorithm. The framework utilizes the open source citygml4j Java library developed by Claus Nagel (Nagel 2013), converting CityGML into Java classes and handling data access, storage and generation processes. To perform an efficient transformation process between LoDs in CityGML, geometric and semantic data parsed by citygml4j are stored in a newly designed data structure to implement the new exterior shell extraction algorithm

Extraction of the exterior shell of a building is a common step when trying to simplify digital building models. Although the exterior features and interior features should be clearly defined in CityGML, some of the input models may not necessarily distinguish the features as interior or exterior. Models transformed from other data formats such as IFC or KML may not contain information of whether the surface is interior or exterior. There is a need for finding the exterior shell for some of the input models. It is also an essential step in LoD4 to LoD3 transformation. As discussed in Section 5.2, the common way of extracting the building envelope is to track the footprint. However, this footprint tracking method is not applicable to buildings with roof overhanging parts as the roof overlays the projection of walls. In Fan et al. (2009), the authors tried to solve this problem by calculating the centroid of building and comparing the distances of each surface to it. However, this proposed method is not applicable for buildings with a non-convex shape as the centroid does not necessarily reflect the “center” of the building.  The new exterior shell extraction algorithm uses the same idea as Ray Tracing algorithm, yet to determine the exterior surfaces out of a detailed input model, the view points to shoot the rays will be changed according to model input. After data processing, the CityGML models are broken into many planar surfaces with corresponding semantic information. Our goal is to find the exterior shell of these surfaces by checking their visibility from the exterior. Our algorithm works as follows: first, find the exterior, which in our case is a bounding sphere of the building. This is calculated in O(1) time for each building. Next, the visibility of each surface against points on the bounding sphere is checked. The visibility of the surfaces is determined using the Ray Tracing algorithm, assuming that the observing rays shoot from points on the sphere. If three randomly generated points from the surface are all visible from the bounding sphere, the surfaces are considered visible and thus on the exterior shell of the building. To avoid fault judgments where some of the exterior surfaces are not visible form the bounding sphere, the program would also check the contiguity of the generated exterior shell. If holes exists in the surfaces, the program will double check the surfaces inside the holes to see if they are exterior. The process is illustrated in the figure above.

LoD4 models are the most detailed model in CityGML, including almost all the geometric information about the building parts. LoD4 models differentiate from LoD3 models in CityGML in terms of interior building features, such as rooms, stairs and furniture. The transformation of LoD4 to LoD3 models basically removes these features and changes the LoD4 geometry (i.e. surface, solid, curve) to LoD3 geometry. When preserving the LoD3 features, the program would also check if the feature complies with the geometry accuracy requirement. The methodology introduced in (Fan and Meng 2009) would be used to judge whether the features comply with geometric accuracy requirements and decide whether or not to keep the feature. A considerable amount of information is lost when transforming a model from LoD3 to LoD2 due to the gap of data requirements between the two LoDs. Openings such as windows and doors are removed in the transformation process. Other features such as outer building installations will also be removed. Buildings in LoD1 are boxes without any roof structure. So the LoD2 to LoD1 transformation is simply removing all the roof structures and building the envelope for the remaining walls. Although LoD1 is the typical block model, the shape of walls is still kept in the model. All the remaining surfaces are written into a solid CityGML LoD1 model.

The proposed LoD transformation framework was implemented in a Java application and tested using a computer with a dual-core Intel i5-2400 CPU (3.1 GHz) and 4GB RAM. The test data sets came from the CityGML models generated from BIM models. All the input data sets were LoD4 models. The LoD transformation was performed in a down-grading fashion in which higher LoDs were converted into lower LoDs. The developed LoD transformation framework could successfully transform LoD4 models to different LoDs without information loss, even for buildings with complex geometry. The transformation among LoD4, LoD3, LoD2 and LoD1 involved few geometric transformations. Therefore, the running time of the LoD transformation shows a linear relationship with the model size. The transformation between LoD4 and LoD3 involved the exterior shell extraction, with the quadratic running time and memory consumption to the model size. Nonetheless, the running time for most ordinary dwelling 3D CityGML models was less than two seconds on our platform. For a two-story house model, the maximum running time was only about 4 seconds. The proposed exterior shell extraction algorithm is a critical step in the LoD4 to LoD3 transformation. The traditional footprint correction method or the method finding the building centroid is not applicable for complex 3D building models. Buildings with non-convex building envelope cannot be handled by such algorithms. The exterior shell extraction algorithm in our framework, on the other hand, uses all the surfaces of the models as input and tries to find surfaces that are visible from the outside of building. These surfaces are the exterior surfaces of the buildings and should be kept in LoD3 models. The exterior shell extraction algorithm considers all the possible cases of visibility of surfaces against the bounding sphere, so it is applicable for even non-convex shapes. The complex non-convex models indicate the effectiveness of the algorithm. The surfaces inside the corner of buildings can be discovered and kept in the generated LoD3 models.

While there is abundant literature on the design, application and evaluation of construction supply chains, the effective use of geographic data in CSCM has not been fully explored.  GIS is potentially applicable in construction supply chain management to manage spatial information, and provides an ideal solution to manage costs of transportation and market analysis in the overall E-commercial activities.  In this research, three problems are solved when considering geographic data in the CSCM system. The first problem is the selection of supplier, when the supplier with the lowest cost may not be the nearest supplier. The second problem is to determine the number of deliveries, as there is an adverse relationship between the number of deliveries and inventory cost. Increasing the number of material deliveries will decrease the need for onsite inventory, but it will increase the fees for delivery. The third problem is the location allocation problems for consolidation centers (CC) for construction material for multiple sites. The objective of the integrated framework is to minimize costs in construction supply chains by generating optimized solutions for selecting supplier sites, determining the number of deliveries and allocating consolidation centers. Information from 4D BIM is used to determine the construction activities and their material demands. A bidding and requisition module is developed based on GIS to allow suppliers to bid for material orders. Based on the actual travel distances from the supplier sites to the construction sites, the integrated framework calculates the delivery fees that are used to optimize three solutions, namely the supplier selection, the number of deliveries and the allocation of consolidation centers.

The construction supply chain management process requires massive data input as well as reliable analytical functions to provide management decision-making. Therefore, a CSCM framework should at least have three layers: the data retrieval and storage layer, the analysis layer, and management interface. The use of 4D BIM and GIS provides opportunities to minimize the manual efforts for data input, and all data can be stored in the geo-databases in GIS with customized analytical functions. A comprehensive 4D BIM model stores the full range of information about activities with associated material demand and duration. In the proposed BIM-GIS integration CSCM framework, a detailed quantity takeoff of the construction project is executed at the early stage of procurements from BIM, and GIS is used to support the wide range of analysis functions to provide decision-making in the CSCM process. The data from BIM are exported to databases linked to GIS, which will be used for analysis. The manually input data are mostly related to the quotations for material from multiple suppliers and changes in current project plans. It is possible that some of the construction activities, for example scaffolding, are not present in the 4D BIM. In this case, manual inputs of such activities along with their material demand and time duration are needed. In the proposed CSCM framework, the data storage, analysis and decision-making are performed in a GIS system. GIS has the capacity to store massive amounts of data and the ability to access fundamental analysis tools such as route finding for delivery cost analysis.

As shown in the figure on the left, we can find consolidartion centers with low cost. By using data from BIM and GIS, we formulate the three problems in mathematical form and provide solutions to these problems. Specifically, we make the following contributions to these three problems: firstly, we prove that selection of suppliers should not only consider factors such as delivery distance or unit price solely. Secondly, we should understand that the number of material deliveries has impacts on the total invoice cost of the supply chain, and we provide a Monte-Carlo Simulation solution to this problem. Thirdly, we prove the necessity of setting up of consolidation centers given the congested sites and long delivery distances using mathematical modelling. And finally, we provide a solution to the location-allocation problem of the setting up of consolidation centers. It is noticeable that all the contributions could not be made without the data inputs and analysis functions in BIM and GIS.

Dr. Jack CHENG'S Google Scholar Page

Dr. Chimay ANUMBA'S Google Scholar Page

Dr. Yichuan DENG'S Google Scholar Page