## 4 Discussion and Conclusions  
In this work, we have proposed a concept that translates a building topology from IFC to Transmodel and aims to reuse and leverage existing building models to support the development of transportation infrastructure models. The concept proposes a method for  
Figure 6: The train station site with two stop places: IFC elements identification. interoperability between the two models. Thus, the benefits are twofold. Such a concept targets one of the problems in implementing BIM in the construction sector, namely the lack of demand from clients ([PERSON] et al., 2013). On the other hand, interoperability between the two models contributes to better trip planning. Automating this process provides a more accurate and dynamically updated source of travel infrastructure data for intermodal trip planning. Improvements in travel infrastructure models help travellers, who can obtain more accurate information not only about the main routes of their trip, but also about the details at the points of mode change. As a result, trip planning becomes more efficient and has fewer surprises. Therefore, we present a concept for a transcoding process that extracts the topological information stored in IFC models. Following an existing algorithm proposed by [PERSON] and [PERSON] (2012) for navigation-network extraction, information about spaces and passages between spaces can be obtained. The semantic information contained in the IFC models is used to transform the found topology into Transmodel objects. Although Transmodel provides the ability to encode indoor and outdoor navigation paths at the location of a given transportation infrastructure facility, our approach does not include the encoding of this information. The navigation-network topology extracted from the IFC model could be encoded in the form of predefined navigation routes using the PATH and NODE objects in Transmodel. However, the standard discourages this approach. In complex buildings, a significant number of possible routes could be identified, and Transmodel suggests that appropriate routes should be generated \"on the fly\" based on the building's network topology during the trip-planning process. Therefore, the proposed approach only involves encoding the building topology in terms of a fixed infrastructure. The NeTEx technical specification models each Transmodel concept in XML. The core of the conceptualisation is the transportation network, schedules, and fares (the first three parts of NeTEx). In our use case, our goal was to feed the part of the transport network describing the infrastructure objects (roads, rails, stop places, and related equipment) with the infrastructure-object data modelled in IFC (version 4.0.2.1). As a first step, the mapping from IFC to NeTEx was investigated using the technical documentation and experimental modelling of the train station. Lessons learned show that NeTEx is mainly concerned with providing travel information by providing passengers with sufficient physical infrastructure data for informed access to transportation services. IFC allows for modelling of the built environment (buildings, roads, bridges, ports) with technical detail and precision beyond the needs of NeTEx (e.g., building structure and materials). Therefore, only a subset of the IFC infrastructure data can be represented in NeTEx. Besides the infrastructure data, other nongeometrical data can be derived from IFC models and mapped to NeTEx models for transportation infrastructure services users. In our use case, the stairs (_IfcStair_) and the entry and exit ramp (_IfcRamp_) with information about required slope is modelled. Our research also highlighted mapping of data for passenger accessibility needs. IFC schema does not support accessibility information as needed by NeTEx; therefore, the mapping of the information can only be utilised through data extraction and deduction rules, whether manually or algorithmically.