## 3 Results  
Below is a succinct overview of the key steps involved in implementing the methodology and ensuring its replicability. Step 1: Use-case definition. This step consists of answering the following questions: who will utilise this development, and how will it enhance their task performance? The use case implies researchers who will employ the new building as a scientific tool [64]. Each user group--professors, scientific collaborators, doctoral students, and the facility maintenance team--must have effective access to information in a format that best suits their task-needs. For CELLS, which serves both teaching and research purposes and caters to individuals who may not always be on-site, an essential requirement is an online solution that is accessible remotely. Step 2: Development strategy. This involves assessing whether existing open-source solutions can adequately address a specific use case or whether an in-house solution is necessary. Various VT software options were tested, standing out 3 DVista VT Pro [32]. While the tested software provided features useful to the research, certain requirements were not attended to: (a) Authentication Component: the use case necessitates an authentication component that aligns with the IT security standards of the involved institutions (EPFL, HEIAFR, and UNIFR) [69]; (b) Flexibility for Marker Integration: the ability to seamlessly integrate markers (such as polygons or geometric elements) into 360\({}^{\circ}\) images, allowing connections to IoT elements; (c) Scalability: the need to accommodate both detailed construction aspects (at a small scale) and broader neighbourhood dimensions (at a larger scale); (d) Versioning: the VT needs to be evolutionary over time in relation to building life-cycle analysis and renovation updates--chronological navigation through different versions of the same location is essential; and e) JavaScript Integration: need for flexibility to integrate JavaScript scripts, whereas 3D Vista was very limited, including limited or incomplete documentation. Step 3: Capturing devices. This step complements the development strategy by integrating the capturing devices to be used. According to the use case, the building assets at the district level (outdoor) needed to be reconstructed, including detailed information at the room level (indoor). A specific device was dedicated for each function. For the district level, a DJI Mini 3 Pro drone [66] was used, which allows 360\({}^{\circ}\) photo captures at various altitudes (i.e., 2, 30, and 70 m), as well as zenith views (orthophotographs). For room capturing, the Rich Theta Z1 [65], a 360\({}^{\circ}\) camera, was chosen for its simple use and linkability to standard smartphones (see Figure 3--image acquisition). Step 4: VT technical development (see Figure 3--image acquisition and image file processing). Having defined the use case and the development strategy, development was divided into six technical modules: (1) Capturing protocol: the referential definition of capturing points, including nodes of reference and capturing frequency. (2) Storage sizing: According to image resolution and capturing frequency, the size and type of storage device was defined. The images are stored on the same server used by the VT web page. (3) Image chronological sorting: The configuration file indicates to the tour360 server that a new date has been added, including the name of the associated locations. Without this information, the server will not be able to identify new available image-paths. Consequently, the date picker would not offer the new date for a given location. The configuration file plays a crucial role in ensuring that the tour360 server can effectively manage and display new dates associated with specific locations. (4) Image polar orientation: A script defining a reference point to establish a singular orientation for each capture point.