### Extended IFC-Based Information Model Creation Method  
The railway track information models created using the methodology presented in Section 3 include shape and attribute information. However, because BAT software does not support semantic information for railway track elements, we represented railway track elements with semantic information of other existing supported elements using the software. For example, Autodesk Revit does not support modeling of track elements such as sleepers; thus, such elements must be represented through other elements such as structural foundations. We developed codes to identify the semantic information of different track elements. A classification system predominantly describing the physical entities of tracks was created by referring to the classification systems proposed by Korea Rail Network Authority [34], Uniclass [35], and Omniclass [36]; classification codes for each category were specified. As the scope of this study included railway tracks, classification codes were specified predominantly for the essential track elements. Table 2 presents the categories and classification codes of the classified objects as well as the extended IFC entities for each category. Classification codes that correspond to the attribute information of element models were added as identifiers so that the semantic information of track elements could be identified during the conversion between information models. For example, BA201 was added to the attribute information of concrete sleepers so that they could be identified as \"IfcTrackSleeper\" during the conversion to IFC. One important consideration during the creation of \".ifc\" files in the form of IFC physical files (IPF), based on the extended IFC, is model integration derived by reflecting the spatial concepts of the model objects created by AMTs and BATs. Accordingly, a module for creating extended IFC-based information models in the BAT environment, which manages the integrated models, was developed in this study. Figure 5 illustrates the process of creating hierarchical information. For the selection of appropriate IFC entities, the automatic mapping method based on the classification codes, along with a method in which the end-user directly selects the appropriate IFC entities in the user interface (UI)--as depicted in Figure 6a,b--was used. The external reference file created elements for each object of the models; these elements included the attributes of objects and information on the extended IFC entities, which were mapped to be employed during the creation of IPF files alongside the hierarchical information, as depicted in Figure 6c. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Category** & **Code** & **Object** & **Extended IfcEntity** \\ \hline Common & BA000 & Common & IfcCivilElementProxy \\ Rail & BA101 & Rail & IfcTrackRail \\  & BA201 & Concrete Sleeper & IfcTrackSleeper \\  & BA202 & Wood Sleeper & IfcTrackSleeper \\ Ballast & BA301 & Gravel ballast & IfcTrackBallast \\  & BA302 & Concrete ballast & IfcTrackBallast \\  & BA400 & Common & IfcCivilElementProxy \\  & BA401 & Fish plate & IfcTrackFastening \\ Facilities & BA402 & Expansion joint & IfcTrackFastening \\  & BA403 & Insulated rail & IfcTrackRail \\  & BA404 & Compromised rail & IfcTrackRail \\ Turnout & BC101 & Turnout & IfcTrackTurnout \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Classification system for railway tracks. The \"Export\" module largely consisted of the following three processes depicted in Figure 7: (a) extraction of shape, attribute, and alignment information from AMTs and BATs by obtaining coordinate conversion information for object placement as well as management of such information;  
Figure 5: Process for creating hierarchical information using Autodesk Revit API. Figure 6: User interfaces for management: (**a**) UI for managing spatial information of each object; (**b**) UI for managing physical information of each object; (**c**) Tree view for managing hierarchical information.