## 4 Discussion
Concerning the _execution complexity_ parameters, ratings 3 and 4 refer to the difficulty in defining a reproducible method/process for adding images, which required a good understanding of the entire website setup and the PhotoSphereViewer library. Also, there was a need to write additional scripts to process the 360 images into small tiles, including the blurring effect, to avoid latency. However, once established and set up, the process was automated. Thus, the 1 or 2/5 rating for _update complexity_. The entire setup took about 120 h of work by skilled programmers. Concerning _scalability, Versioning_ rates 3 because the accumulation of images can be a relatively time-consuming task, especially when dealing with new versions that may weigh over 2 GB. This raises questions about the available server storage space. In relation to Object-IoT DB connection, the rating 3 derives from the specific database used (BBData) [74], in which queries between the site and the database are not well optimised. In the event that many objects are consulted, the database can be overloaded. This is because the database used lacks a single query that directly provides a value table for a desired sensor collection. In contrast, on the Tour360 side, the process is just as scalable as _Space to Room in BIMs_ and _Object to BIM object_. The database is being improved to solve the issue. The task of creating the initial polygons is relatively time-consuming. However, since the polygons are associated with geolocation information, there is no need to recreate them for subsequent versions. The fundamental limitation of the technical solution is related to its implementation in a real-functional building (Step 7: Scalability, in Section 3). Three major challenges in this respect can be identified: the scale of implementation, the user evaluation, and the issues related to cyber-security and remote control. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Feature** & **Feasibility** & \
\begin{tabular}{c} **Execution** \\ **Complexity** \\ \end{tabular} & **Scalability** &
\begin{tabular}{c} **Update** \\ **Complexity** \\ \end{tabular} \\ \hline (Geo) location & Y & 3 & 1 & 1 \\ \hline Versioning & Y & 4 & 3 & 1 \\ \hline Object to IoT database & Y & 1 & 3 & 2 \\ \hline Space to room in BIMs & Y & 2 & 2 & 1 \\ \hline Object to BIM object & Y & 2 & 2 & 2 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Implementation evaluation by task according to the following criteria: Feasibility (Y = Feasibility, N = Non-feasible); Execution complexity: the difficulty of initially setting up the feature (1 = very easy, 2 = easy, 3 = moderate, 4 = complex, 5 = very complex); Scalability: how far can the functionality be escalated in terms of technical resources and feasibility? (1 = scalable, 2 = limited scalability, 3 = moderate scalability, 4 = barely scalable, 5 = not at all scalable); Update complexity: the difficulty of maintaining or updating the feature (1 = very easy, 2 = easy, 3 = moderate, 4 = complex 5 = very complex). As discussed in the previous section, the solution is under implementation in 26 spaces of an office building [68]. The project shows satisfactory results, as predicted in Table 2. Nevertheless, certain obstacles related to the escalation of the solution cannot be fully identified before the end of the implementation (November 2024). The solution also lacks an evaluation mechanism by a real FM user. A methodology to evaluate the different aspects an FM user may require is under design. The proposed methodology will undergo testing with team members who will operate the 26-office system under real-world conditions. However, significant limitations can be anticipated, particularly in relation to the skills required for tasks such as setting up and maintaining the VT. This limitation is especially relevant in the context of image processing and the addition of new elements linked to the database.