From crowd to cloud: simpli ﬁ ed automatic reconstruction of digital building assets for facility management

Purpose – The purpose of this paper is to investigate the feasibility of an end-to-end simpli ﬁ ed and automated reconstruction pipeline for digital building assets using the design science research approach. Current methods to create digital assets by capturing the state of existing buildings can provide high accuracybut are time-consuming,expensiveanddif ﬁ cult. Design/methodology/approach – Using design science research, this research identi ﬁ es the need for a crowdsourced and cloud-based approach to reconstruct digital building assets. The research then develops and tests a fully functional smartphone application prototype. The proposed end-to-end smartphone work ﬂ owbeginswith data capture andends withuser applications. Findings – The resulting implementation can achieve a realistic three-dimensional (3D) model characterized by different typologies, minimal trade-off in accuracy and low processing costs. By crowdsourcing the images, the proposed approach can reduce costs for asset reconstruction by an estimated 93% compared to manual modeling and 80% compared to locally processed reconstruction algorithms. Practical implications – The resulting implementation achieves “ good enough ” reconstruction of as-is 3D models with minimal tradeoffs in accuracy compared to automated approaches and 15 (cid:1) cost savings compared to a manual approach. Potential facility management use cases include the issue and information tracking, 3Dmark-up andmulti-model con ﬁ gurators. Originality/value – Through user engagement, development, testing and validation, this work demonstrates the feasibility and impact of a novel crowdsourced and cloud-based approach for the reconstructionof digital buildingassets.


Introduction
Inefficiencies and lack of interoperability in facility management (FM) are estimated to cost around US$15.8bn annually in the USA alone (Yalcinkaya and Singh, 2014). Much of this cost is associated with re-creation and re-entry of building data. At the completion of a project, handover of paper-based documentation and "as-built" drawing information can take several weeks. An inordinate amount of time is required by the FM team to verify facility and project information. Furthermore, older buildings lack any sort of digital representation that can be used during operations and maintenance. FM must source information from paper-based documentation and blueprints that can be inaccurate or difficult to find.
In search of digital representation for use during FM, researchers and technology providers have developed processes to automatically capture and extract FM-specific geometry and attributes from existing buildings. This is because the manual reconstruction of three-dimensional (3D) models can be unreasonably difficult, time-consuming and error prone. As an alternative, semi-automated workflows generate point cloud data using laser scans and convert them manually to as-built building information models (BIMs). While found to be accurate, the process is expensive and demands extremely skilled labor (Xiong et al., 2013). In comparison to the typical digital skillset of a facility manager and end-user, these automated approaches are far too technical and computationally intensive.
The objective of this paper is to develop a simplified and intuitive approach to generate as-is BIM models. To accomplish this, we follow a design science research (DSR) methodology. DSR is driven by deep engagement with the real-life problems or opportunities of potential users (van Aken et al., 2016). By providing a structured approach to designing a solution to fulfill a purpose, testing and validating that the solution does serve the intended purpose and then improving the solution as needed (March and Smith, 1995), DSR represents one method to conduct "bottom-up" engineering informatics research in conversation with engineering practitioners (Hartmann and Trappey, 2020).
In this paper, the DSR methodology led to consideration and eventual combination of two emerging phenomena. The first is the use of cloud-based BIM. Cloud-BIM is the integration of growing cloud-computing technologies with the BIM practices enabling more collaboration and dynamic real-time communication among all stakeholders (Bello et al., 2021). The second is the concept of crowdsourcing. Crowdsourcing is a method of involving a group of people toward a common goal (ideas, financing or work) through a chosen medium, such as the internet, social media or mobile applications (Estellés-Arolas and Gonz alez-Ladr on-de-Guevara, 2012). The combination results in the development of a crowdsourced workflow to generate "as-is" BIM models using smartphones as the capture device, as will be described later in the paper.
The paper proceeds as follows. First, we review the existing literature on as-built and asis BIM, including the practical limitations to create these models using laser scanning and image reconstruction approaches. Next, we follow the DSR approach to define the problem further, define a set of solution objectives, design and development the "crowd-to-cloud" workflow, demonstrate and test the workflow for participant use through practical implementation, and evaluate the tool for future implementation. The paper concludes with a discussion of the implications of the proposed workflow and limitations to the research.

Departure
BIM is a digital representation for physical and functional characteristics of buildings that has increasingly been accepted in the Architecture, Engineering and Construction (AEC) sector. BIM offers significant benefits to FM, including improved processes for restoration, documentation, operation, maintenance, quality control, energy and space management JFM (Macher et al., 2017;Yi-Kai and Nai-Pin, 2017). However, despite emerging BIM processes for FM, most existing buildings are not maintained, refurbished or deconstructed with BIM yet (Volk et al., 2014).

From as-built to as-is building information model
One reason for the lack of BIM in FM is the lack of "as-is" models that are available. The creation of a design BIM during the design stage of a new project has become common. By contrast, the handover of an as-built BIMa BIM that accurately reflects the facility's geometry and attributes after the completion of construction on-site (i.e. "as-built")is much less common. Even when an as-built BIM is provided, subsequent changes and renovations mean the as-built BIM might not reflect the current state of the building "as-is" (P atr aucean et al., 2015). Past scholarship has continuously insisted on the necessity to move from asbuilt to as-is BIM due to significant variations between the constructed and current condition of a building, subsequent changes and renovations arising to buildings over time, absence of design BIM and/or the lack of blueprints (Jung et al., 2015;Tang et al., 2010;Xiong et al., 2013). Therefore, facility managers who wish to operate and manage facilities using an as-is BIM (Dore, 2014) must face the challenging but necessary process to construct and update data models continuously.
To help FM with this updating, there has been a consistent effort in automatically generating as-is BIMs for existing facilities. This workflow includes four stages: data acquisition, 3D reconstruction, 3D modeling and application ( Figure 1). Early approaches to as-is BIM used laser scans to generate point clouds and then used 3D reconstruction algorithms and/or manual methods to create 3D models. Recent scholarship has focused on the photogrammetric translation of indoor/outdoor scenes to semantically enriched 3D models. We briefly summarize the two approacheslaser scanning and image reconstructionbelow, including a critical perspective on limitations with respect to the FM end-users.

Laser scanning
Laser scanning systems are the most adopted and well-experimented technologies for data acquisition of as-BIMs in the AEC industry. Laser scanners capture point cloud data with speeds of 1,000-100,000 point measurements per second (Tang et al., 2010) and with great accuracy [1] ($12 mm at 100 m) and point density (Bosché, 2009). Laser scanned point clouds are the simplest form of 3D data representing coordinates and texture of the realworld scene. From here, it is possible to manually model the building using the laserscanned point clouds merely as visual support (Macher et al., 2017). However, this does not take advantage of the effort or cost to capture the data and has been classified as timeconsuming, error prone and demanding skilled labor (Wang and Cho, 2014).
A more effective 3D reconstruction of the point cloud data uses segmentation algorithms. The acquired raw point clouds must first undergo noise removal and structuring. De-noising and outlier removal methods include (Ning et al., 2018) the discontinuous operator-based method (Wang et al., 2013;Zhang et al., 2009;Huang et al., 2010) and the surface fittingbased method (Weyrich et al., 2004). Next, segmentation methods group points into subsets From crowd to cloud defined by common characteristics and classification assign these points to specific labels according to different criteria. Post segmentation, automatic modeling has been previously achieved using heuristics (Pu and Vosselman, 2006;Rusu et al., 2009), ontologies (Ben et al., 2012), context and prior knowledge (Guo et al., 2014). Although research in this field has demonstrated success and potential, industry adoption has been limited by the cost. This technology suffers from high initial equipment costsprevious estimates range from US$50,000 and US$100,000 for standard versions (Bosché, 2009)making it infeasible for small-and medium-sized projects. The usage of the equipment takes time to learn and requires skilled knowledge workers. Usually, scanning from a single location cannot cover the entire facility and scans must be obtained from multiple locations, consequently increasing the capturing time spent on-site. Furthermore, the registration of point clouds and de-noising the data needs additional manual effort and checking. 3D reconstruction algorithms require fine-tuning of different parameters according to the captured scene.

Image reconstruction
Image-based technologies in practice can be divided into: Photogrammetry and Videogrammetry. Photogrammetric techniques are adopted for 3D restitution of scenes using images taken from different points of view. These techniques depend on the geometry or surface characteristics of building elements. Image-based technology holds the advantages of being automatic and having low equipment cost, fast on-site data acquisition and high portability. However, it has the downsides of reduced accuracy and its unfamiliarity to existing surveyors (Dai et al., 2013).
3D reconstruction for images requires computational algorithms to transform images into a 3D point cloud/mesh. The resulting point cloud is unordered and unstructured. Detection of geometric primitives (points, patches, edges and lines) is the fundamental step in identifying objects in images. Image processing researchers have proposed several algorithms, for example, SIFT, SURF, MSER and DAISY for image registration, image differencing and image recognition (Lu and Lee, 2017). Using these algorithms as the base, computer vision and civil engineering scholars developed methods to identify and recognize buildings.
At the core of all methods, the task is to correlate some sort of visual information (regions, edges, lines or points) between the image-pairs in the collected data set. Among all methods, the most widely used and representative for building recognition is image-based point cloud generation. Structure from Motion (SfM) is a method to recover 3D scenes (point cloud) from unordered two-dimensional (2D) images. Several open-source implementations of SfM, such as Bundler [2], OpenMVG [3], VisualSfM [4] and Colmap [5] are available. SfM has been successful in achieving automatic image-based construction monitoring (Golparvar-Fard et al., 2011), image-based indoor navigation (Dong et al., 2015;Gao et al., 2014;Noreikis et al., 2018) and indoor reconstruction (Lehtola et al., 2014). The resulting 3D point cloud from a SfM can be reconstructed into a mesh using one of several available meshing algorithms, such as Poisson Surface Reconstruction, Smooth Signed Surface Distance reconstruction and Floating Scale Surface Reconstruction.
Modeling for image-based point clouds can be categorized as model-driven methods and data-driven methods. Model-driven methods rely on detecting differences between manually created models and structural relationships for object recognition. Data-driven methods (Guo et al., 2014) for image-based point clouds use captured data and its features for segmentation. Image-based 3D reconstruction has been disregarded in the past due to accuracy trade-offs compared to laser scanners. With improvement in algorithms to JFM reconstruct image-based point clouds, this field has been gaining attention recently. Photogrammetry is considered a suitable method when the scenes to be captured contain a lot of texture and gradient. Laser scanners are adopted when accuracy is the priority. Another major drawback of attaining image-based point clouds is the intense computational power consumed by the reconstruction algorithms.

Design science research
DSR concerns itself with the designing and making of artefacts to fulfill a purpose, testing and validating that those artefacts serve the intended purpose and do not have unintended consequences, and then improving the artefacts as needed (March and Smith, 1995). Design science research (DSR) is driven by field problems or opportunities because it believes instrumental knowledge is developed by deep engagement with these real-life problems or opportunities (van Aken et al., 2016). DS has been applied in multiple domains related to this paper, including construction management (Tommelein, 2020;Voordijk, 2009), construction informatics (Chu et al., 2018;Fang et al., 2018), information systems (March and Smith, 1995;Peffers et al., 2007) and operations management (van Aken et al., 2016). Hartmann and Trappey (2020) have called for researchers in advanced engineering informatics to approach problems in a "bottom up manner closely involving engineering practitioners" while making use of social science methods to help formalize and validate knowledge. Bottom up "co-creation" of digital services for FM requires dialogue between the project parties and a shared understanding about both the FM's needs and the way that a digital service can satisfy those needs (Lavikka et al., 2017). In particular, there is a need to explore advanced computational methods in combination with novel information acquisition systems including understanding practitioner needs for graphical user interfaces, workflows for knowledge capture using cloud-based technologies and methods to support engineers and FM teams in knowledge intensive tasks. DSR offers a structured approach to uncover these needs from FM users, formalize solution targets, design a solution prototype and then demonstrate and evaluate the proposed workflow.

Research gap
One limitation of the modeling algorithms discussed in the previous sections is the investigation of only partial segments of the complete workflow, with limited involvement or consideration of the work routines and needs of facility managers. Research interest has focused on the best geometric representation and increasing the speed or efficiency of the algorithm. In addition, modeling approaches are developed for working locally, which requires powerful machines/clusters. In a practical setting, for a firm working on a smaller project, this would mean a high investment cost which overshadows the benefit from such a reconstruction.
The required efforts to create an acceptable as-is BIM from these workflows can overshadow the benefits of the process (Kim, 2012). The time consumed to scan large buildings is very high and structuring the data can still require manual processes resulting in high costs. Furthermore, there is a need to understand and analyze the entire chain that leads to an enriched 3D model (Hichri et al., 2013) beneficial to the end FM user. Much of previous research has emphasis on methods, algorithms and techniques to extract a geometrically and semantically rich BIM model. These have resulted in successful technical breakthroughs, but we note the absence of attention to a complete workflow from data acquisition to value-added application in the field.
In summary, there is a gap between "top-down" algorithmically-strong methods with "bottom-up" industry-ready workflows. Ideal 3D digital asset reconstruction should be economical, efficient, accurate, and practical (Lu and Lee, 2017). Furthermore, scholarship finds additional benefits can occur when new technologies and data workflows are cocreated alongside existing FM teams (Lavikka et al., 2017). Critics of BIM find it to act as a standalone system framework that restricts project stakeholders' access to a common set of data (Chuang et al., 2017). As an alternative, the concept of cloud-based BIM as an emerging technology is needed to enable higher levels of cooperation, collaboration and provide an effective real-time communication platform for involved stakeholders .

Research approach
To address this gap, we follow the DSR methodology to develop a crowdsourced, cloudbased approach to create as-is BIM models. First, we conduct semi-structured interviews with two groups of stakeholders to understand the specific limitations of BIM for FM in today's practice. Second, we use a series of exploratory tests to develop solution targets regarding automation, efficiency, accuracy, practicality and scalability. Third, we design the initial prototype including the development of the mobile client, cloud architecture and Web client. Fourth, we conduct an experiment to demonstrate implementation of the prototype. Finally, we evaluate user and expert feedback and propose potential further use cases based on this feedback. The specific DSR process is summarized in Figure 2.

Problem identification and motivation
To better identify the specific problem, we began the research by conducting 12 semistructured interviews lasting between 30 and 45 min each. This dialogue includes experts from two distinct fields (Table 1): AEC and computer science (CS). All interviewees were identified through industry partners and research labs, contacted digitally by the first author.
AEC interviewees were chosen for their expertise in FM, energy retrofit and spatial development. These interviewees worked during the operations and maintenance phase of DSR flowchart material JFM the building lifecycle; therefore, they would most benefit by solving the observed problem (Franz et al., 2018). During the interviews, AEC experts were asked if the lack of a digital asset is a primary issue, their needs and problems on regular projects, their current workflow to tackle the issue, the potential use cases, knowledge on reality capture and surveying methods and their readiness to adopt an innovation. In addition, experts from geoinformatics and surveying were also interviewed to understand the current surveying technologies in the AEC industry.
From CS, the interviewees were chosen for their expertise in computer vision, reality capture and 3D reconstruction. During the interviews, CS experts were questioned about reality capture methods to reconstruct building-related scenes, the extent of current work, implementation in the field, their knowledge on the needs of the AEC industry and if they were aware of any application focused pipeline.
Data collection occurred through note-taking by the first author. These notes were compared and contrasted to develop a set of common responses regarding the demands and problems of FM (AEC) and the state-of-the-art solutions (CS). The quotes selected for presentation in the paper were later shown to the interviewees for confirmation that they represent the speaker's views. A synthesis of the main problem identification is shown in Table 2.
3.1.1 Synthesis of architecture, engineering and construction expert knowledge. AEC experts first stated an urgent need for digitalization of the existing building stock. One Present algorithms could be modified according to the needs of practitioners, but this must come from AEC Data Often collected but not used or shared effectively From crowd to cloud participant stated, "more than 90% of our projects are existing buildings" and "a good deal of them are at least 50 years or older." If existing assets could be digitized, it would "make their lives easier." In particular, there is a benefit to having the as-is digital model during the concept phase to understand the current and potential functionality of the spaces. The current documentation is frustrating and there needs to be a "connection between paper and digital model of the asset." Next, AEC experts described how approximation runs their daily job. As opposed to the state-of-the-art research, which focuses on high accuracy for as-is BIM, practitioners do not need a "perfect BIM model." Instead, the need is "very basic geometrical insights such as volume of the room, area of windows and room relationships," which "could add a lot of value." Most typical work is approximated via hand calculations and excel sheets, with low levels of automation, so reconstructed digital assets with high levels of accuracy are simply not needed at this time.
AEC experts described how the new techniques demand too much learning and wished there was a one-click solution. One engineer who was experienced with scanning-based modeling algorithms stated that "the learning time and effort was way too high for a planner to go through it." From a cost perspective, one MEP engineer with point cloud experience voiced displeasure with the "high number of hours to manually model the structure and elements." Overall, there was no clear and simple "one-click solution" without disrupting the daily routine of planners and facility managers.
Finally, AEC experts explained that data is collected but not used effectively. Many described a recent shift of techniques from manned surveying to laser scanning. Many had conducted experimental scanning with terrestrial laser scanner and drones but seldom had they successfully passed on this data as part of a meaningful project. One interviewee described that the existing in-house laser scanner has been "hardly used." An expert in energy modeling claimed that "the collected data becomes unusable if it is only acquired for one specific purpose and restricted in modifications." 3.1.2 Synthesis of computer science expert knowledge. CS experts first described how many state-of-the-art methods for reality capture and reconstruction of real-world scenes have been developed or are in development. CS experts described how the reconstruction of scenes related to buildings are among the most complex systems to reconstruct and therefore are of high interest for computer vision scientists. In contrast to AEC experts, these algorithms are so well-established in the CS domain that the researchers could mention several techniques and research groups without hesitation.
Next, CS experts viewed existing CS work as highly-focused on algorithm development. A researcher in semantic segmentation mentioned that "most current research is focused on optimizing existing algorithms in terms of accuracy, speed, efficiency and computing power. Research work toward an entirely new framework is very rare". Another participant expressed his view that "to work on a reconstruction algorithm for building-sized structures is really time-consuming and painstaking" and that the present algorithms could be modified according to the needs of practitioners.
Finally, CS experts expressed curiosity at the absence of service-oriented tools in AEC. There were curious questions about the current state of practice in AEC, such as one CS expert asking, "Why do construction practitioners use a laser scanner instead of a total station?" Another interviewee brought up the "absence of complete workflows to install on the engineer's desk." Although existing algorithms are extremely advanced, they do lack an industry-specific workflow. However, this adaptation should come from AEC as CS experts would not know the specific needs of industry practitioners.

Define objectives for a solution
From the above synthesis of the interviews, a preliminary set of objectives was defined to explore the potential workflows to automate reconstruction for FM practitioners. To do so, potential workflows were evaluated based on the following objectives: level of automation: least manual intervention and potential for "one-click" solution; efficiency: time, cost and computing load; accuracy: degree of difference between model and target scene; practicality: user-friendly, adaptability and customization; and scalability: generic, large-scale implementation possibilities.
A series of initial tests were performed on two different potential workflows. The initial testing focused on identifying a suitable transformation (input to output) of the development pipeline. Both workflows were built on the same underlying algorithm, SfM and Multi-view stereo. The first reconstruction pipeline, Colmap, is an open-source research tool which takes 2D images as input and reconstructs a dense 3D point cloud. The second pipeline, Autodesk Forge ReCap API is a cloud-based reconstruction engine API from a commercial software provider in the AEC industry. This API allows users to custom build tools for reconstructing 2D images into a 3D mesh. Two different indoor typologies, a corridor and an office room, both with maximum clutter were tested to understand the capabilities and limitations of the workflows. The acquisition, computing, cleaning times and the result mesh were analyzed. An Image Acquisition Manual was defined specifying guidelines for a user on best practices for image capture to generate significant 3D meshes/point clouds. Incorporating the learnings and addressing limitations of the two methods, a further field test was carried out in an indoor auditorium to provide generality and draw strong conclusions for further design. A common drawback of both methods was inefficiency in reconstructing windows, reflective and texture-less surfaces. This was addressed by testing the auditorium as both non-textured (as-is) and textured (manually adding colored notes) scenes. Predefined control points were introduced to the indoor scenes, measured and used to analyze the geometric accuracy of the reconstructed results. A detailed description of these initial tests and results are available in the supplemental material.
From these initial tests, the scope and idea for the solution were further iterated to consider that the model should be crowdsourced and cloud-based. From here, the specific requirements needed for a solution could be more precisely defined.
3.2.1 Mobile client for data collection. Multiple users should be allowed to collect image data when and as they wish, including simultaneous capture. Therefore, the workflow has to include a user-friendly mobile client (application). This smartphone application must provide access to different users and instruct them on how to gather images for the best possible reconstruction.

Data visualization.
To facilitate a structured collection of consecutive images, all users must be able to visualize the current state of reconstruction of the zone/room. On this ground, the developed smartphone application needs to provide means to visualize collected images and reconstruction results.
3.2.3 Cloud processing and computing. A crowdsourced reconstruction process based on the input of multiple scanning devices requires continuous aggregation and processing of scanned data (Franz et al., 2018). Since mobile devices have restricted capabilities and setting up a local server would mean additional hardware expenditure and maintenance, a From crowd to cloud cloud processing server is considered best. Staging all the computing to a remotely located cloud also provides flexibility for parallel processing.

Network channel/communication infrastructure.
Users with mobile devices must have continuous access (upload and download) of all acquired and reconstructed data. The stability of the network infrastructure is of prime importance to enable multi-directional data exchange between the client and the cloud. The system should be designed to work on both an independent network long term evolution and established Wi-Fi.
3.2.5 Hardware equipment agnosticism. The target is beyond users with specific skill sets or equipment. The workflow should be designed agnostic to the type of smartphone (model and make), operating systems (Android, iOS) and should be scalable for images taken on any other device.
3.2.6 Web client (or mobile client) for application. The goal of such a reconstruction workflow goes beyond just the data collection and processing. Users should be able to use the reconstructed result, use it for their needs and solve routine problems they face. This insists on the requirement of a user-oriented functionality to add/modify and delete data onto the model. The developed concept must include a Web-based application (and/or) an interface in the mobile client to add such functionalities.

Design and development
As the development is hardware independent and can be deployed on any smartphone supporting either Android or iOS operating system, this section focuses more on the software architecture (Figure 3) of the framework. A conceptual framework was designed based on the objectives and requirements (Section 3.2). The proposed framework consists of three major modules: Mobile Client, Cloud Architecture and Web Client. The mobile application developed would incorporate features for crowdsourced image data collection and dynamic visualization. The cloud computing platform should handle uploading collected images to the reconstruction engine and translate reconstructed meshes for visualization. The external Web application should dynamically retrieve reconstructed meshes and provide customized functional features. The reconstruction engine chosen as ReCap API, it was reasonable to build the entire development around the comprehensive Forge API. The defined framework was proposed for an Autodesk Forge Accelerator [6] and Autodesk Forge developers supported the first author with the application development during the five-day intensive AEC hackathon.
From this framework, a specific implementation was developed and prototyped. Below outlines algorithms, technicalities and source code that were developed. The inspiration for the source code of the mobile application and the cloud architecture was from public development repositories published by Autodesk Forge Specialists. This specific prototype includes additional features, such as multi-user data collection through the smartphone application, dynamic retrieval and visualization of partially reconstructed results by users at any point of time, adding new set of images to an existing photo scene, interactive instruction screen for guiding the user experience, Web-client interfacing with the storage to retrieve reconstructed data and three distinct Web applications with identified use cases.
3.3.1 Mobile client. To bypass double work in mobile implementation (Android and iOS), Expo.io and OS agnostic integrated development environment (IDE) was preferred. The mobile client was scripted on JavaScript supported by out of the box packages from Expo. Expo is an IDE that enables developers to create React Native [7] applications that can run in any native environment containing the Expo Software Development Kit.
The construct of the mobile client was based on some general considerations: user-friendliness; security; visualization/user guidance; user instructions; API management; network; and backend.
Conceptually, the first step was to authenticate the user to access the secure mobile application which was achieved by using Autodesk Single Sign-On. The demand for a user-friendly experience designed the succeeding steps: The users are expected to select captured images from their mobile camera or album and once satisfied. The users are expected to send the selection to Autodesk Cloud (hosted on Amazon Web Services [AWS]) for processing. On completion of the image set processing by the Autodesk ReCaP API, the user should be notified that the reconstructed mesh data (3D model) is ready to be retrieved through the Autodesk Model Derivative API and visualized in the viewer on the mobile client.
Steps 1 and 4 are implemented locally on the device. Steps 2 and 3 overlap with the backend functionalities demanding network related activities (discussed in Cloud Architecture).
As the workflow depended on crowdsourcing, the users of the application had to be instructed on how exactly the images had to be captured. The application reflected this requirement by including an Instruction Screen (Figure 4). These instructions directly adopted the learnings in the "Image Acquisition Manual." The mobile application was devised to perform simple network activities like image uploads, processing requests and visualizing retrieved data. Intensive processing was From crowd to cloud moved to the cloud infrastructure to ensure reliability (Cloud architecture). Such a workflow has precedence (Franz et al., 2018) and proved beneficial to evade network issues and lower computing capabilities of a mobile device. 3.3.2 Cloud architecture. As detailed in the previous section, Steps 2 and 3 of the application concept demanded strong network-related activities. It was decided to adopt this as Node.js backend service apps: The first app handled creating, processing and deleting the Reality Capture photo scene (bucket of uploaded images) on request by the user through the mobile client. The second app included code for handling the reconstructed (by the Forge reconstruction engine) output in the Autodesk Object Storage Service and translating it into a Forge viewable format, .svf.
Prior works have successfully hosted intensive processes on a single server backend built and maintained on powerful local machine/s. The disadvantages, though were setup and management of the servers, hardware requirements and specificity of the backend service. The particularity of currently implemented architecture is the choice of Serverless Computing. Serverless Computing is a cloud-computing execution model in which the cloud provider runs the server and dynamically manages the allocation of machine resources. The strength lies in the fact that any type of backend service can be deployed with no administration troubles and pay-per-use pricing. It was of prime importance to adopt this new cloud technology that could strengthen the ease of adoption and positively influence a potential business model. AWS was picked as the cloud provider due to its comprehensive support on Serverless Computing and successful integration with the Autodesk Forge infrastructure. Four distinct serverless computing modules were incorporated ( Figure 3): AWS Lambda functions: AWS Lambda is an event-driven, serverless computing platform provided by Amazon. AWS API Gateway: is an AWS service for creating, publishing, maintaining, monitoring and securing REST and WebSocket APIs. Screenshots of the reality capture smartphone application prototype JFM Amazon S3: Amazon S3 is a "simple storage service" offered by AWS that provides object storage through a Web service interface. Claudia JS: Claudia is a JavaScript library that handles deployment, modification and destruction of AWS Lambda functions.

Web client.
The Web client is not an integral part of the smartphone application but rather a use-case-based Web application which retrieves the reconstructed mesh data from the same cloud infrastructure. Three distinct modular but integrable use cases were identified for facility managers (primary target, but could also be used with slight modifications by other disciplines) to use the reconstructed 3D mesh model: Issue and information tracking: dynamically add issues and information to a simple 3D mesh model on the Web. Issue monitoring panel enlisting current and closed issues and meta-properties panel (for static text, image, link, document formats) were the two major components to ensure smoother workflow collaboration. 3D mark-up: a tool for on-site personnel to record as-is condition by attaching images to created pushpins/markups on the model. Each mark-up associated itself with a customizable icon (Issue, request for information, Status and Warning) and adopted to the camera position of the user, ensuring smooth rendering on mobile devices. Multi-model configurator: space management tool for dynamically modified spaces (meeting rooms, cafeteria and conference) to efficiently test varying configurations on the Web (move and play) and aid in decision-making.
All the applications were built on a Forge Viewer. The Viewer is a WebGL-based JavaScript library for 3D and 2D model rendering. Concerning the Web client for the prototype, a Web viewer was developed as a Node.js application scripted on JavaScript. The Web application consists of both client-side HTML/CSS code responsible for the Web interface and serverside code handling the backend and API requests. All the use cases were developed as modular viewer extensions. Viewer extensions are JavaScript classes written specifically by the developer to achieve customized functionality.

Demonstration
As demonstration of the artifact, an experiment was devised to understand if the proposed tool could solve the observed problem when used by non-experts. The experimental design is described in Table 3. Ten participants were chosen in total through an expression of interest form. The first five were put into the unguided crowdsourcing group and the rest into guided crowdsourcing. A regular seminar auditorium was chosen as the case study for this experiment. Selected metrics, both quantitative and qualitative were obtained and analyzed by conducting the experiment. Irrespective of the group, each participant was responsible for collecting exactly 40 pictures. This number was identified from initial tests as an intuitive minimum to achieve From crowd to cloud partial reconstruction (geometrically meaningful). Participants in G1 were asked to follow the instruction screen (Section 3.3.1) and take pictures without any further guidance. G2 participants could additionally access the Viewer screen on the mobile application and visualize the partially reconstructed model from the previous participant in their group. This difference was introduced to analyze the advantage of visual guidance in crowdsourcing, as the reconstruction on the cloud was dynamic. The perimeter of the room was measured manually using a meter scale. Other dimensions, such as wall length, height and door dimensions were also measured. Two fixed distances, 1.15 m each, were marked on opposite walls of the auditorium using "X" marks on paper (Control points), remaining unchanged for all participants. It was made sure that the room was empty during the capture and any movable objects located in its original position. The lighting conditions were maintained the same.
The participants were required to attend an online survey after completing their experiment. The questions were related to the metrics of analysis and usage of the smartphone application.
For both the guided and unguided activities, the 3D reconstruction was triggered in steps of 40 (40, 80, 120, 160 and 200). The reconstructed mesh model was saved after every consecutive step and analyzed as follows: Quality of mesh with respect to the number of images: Mesh size, Mesh faces and Mesh points. Boundary fulfillment: Percentage of actual perimeter reconstructed in every step. Total time: Sum of time of capture and time of upload. Geometric accuracy: Distance between the control points on the model versus the manually measured distance.
The 40 images from each participant were also reconstructed individually without cumulating to evaluate the aggregation effect and modularity of the partial models. The mobile devices (4 Android, 6 iOS) used by the participants were at least 12 MP in camera resolution or higher. The entire participant set was covered over a period of four weeks according to the availability of the auditorium.
For both groups, the captured 40 images were uploaded by the participant in the relevant storage bucket. The core analysis was the consecutive [8] reconstruction with additional 40 images in every step. G1 participants required an average time of 4.4 min to capture 40 images each compared to an average capture time of 5.5 min by G2 participants. The higher time of capture for the guided group is justified by the time taken to refer to the partially reconstructed model, comprehend the mesh and identify locations to take further pictures.
The time to upload depended on the participant's affinity to interact with their phone. There was no identified pattern differentiating the groups. However, Android users required slightly more time than iPhone users due to the user interface design (two pictures per row) of their image gallery. It took an average of 15.8 min and 16.4 min by G1 and G2 participants, respectively, to upload 40 images each.
The reconstructed meshes from individual participants (40 images) and cumulative image sets (40, 80, 120, 160 and 200) for G1 and G2 are presented in Figures 5 and 6, respectively. It can be observed that the individual mesh reconstructions in unguided participatory crowdsourcing are very random, reconstructing almost nothing (P1 and P5) to achieve a complete boundary (P3). It was observed there was no order in the collection of images and hence the resulting meshes. The cumulative results showed that a highly JFM satisfactory result (geometric accuracy and boundary fulfillment) was achieved at 120 images. Images added further produced redundant meshes containing bumpy surfaces and poor feature matching. This can be attributed to excessive similar images containing too much overlap which are not required by the algorithm. This redundancy did not intrinsically reduce the effective reconstructed area. Of worth mention is a manual error by P5, where the participant stood in the center of the room and took panoramic shots of the room. The instructions required the participants to stop along the perimeter and capture the opposite side of the room. This resulted in individual P5 reconstruction (40 images) to fail. However, the images captured from the center of the room did contribute to the cumulative reconstruction providing some overlap to existing holes.
The guided participatory crowdsourcing in which the participants had the choice to refer to the previously reconstructed mesh (partial) produced modular meshes ( Figure 6) from individual reconstructions (40 images) which fit as perfect pieces to complete the auditorium. The cumulative reconstruction built up slowly on the back (P1 þ P2), on three  From crowd to cloud sides (P1 þ P2 þ P3) and finally the complete auditorium (P1 þ P2 þ P3 þ P4). Images from P5 reconstructed an individual mesh but did not contribute to the cumulative model because the participant captured too much of the ceiling without overlap to the existing model. This participant was indeed expected to capture the ceiling, as that was the only missing part in the previous mesh. However, the visual guidance also needs to align with the prerequisites of the algorithm itself to improve the results. The reconstruction time (Figure 7) on the cloud for the cumulative image sets varied significantly between the two groups. In the unguided scenario, the number of minutes required increased with an increasing number of input images, peaked at the third participant (120 images) and then decreased for 160 and 200 images. Again, this trend is rationalized by the redundant images after 120 inputs. The algorithm dropped out/did not match all the images and consumed less time. The mesh size (Figure 8) of the unguided group also followed an identical trend. It was interesting to note that this reduction in reconstruction time and mesh vertices did not affect the geometric accuracy (Supplementary material) or the completeness of the reconstructed model. However, it brought forward the sensitivity of the reconstruction engine to the images being added. It can be safely concluded that a higher number of unordered images does not always mean a more accurate reconstruction.
In the guided scenario, the cumulative reconstructions required increasing time ( Figure 7) with increased inputs. The mesh sizes ( Figure 8) increased linearly for every consecutive model. The data for the 5th participant is excluded as the images added failed to contribute to the cumulative reconstruction. The observations from guided participatory crowdsourcing conclude the effectiveness of visual guidance in reconstructing a satisfactory mesh step by step as modular partial models. The total reconstruction time for 160 images in the guided scenario was 42.4 min compared to 95.7 min in the unguided scenario. This was additional validation to the easier and faster processing of guided and ordered images.
Boundary fulfillment (Figure 9) of reconstructed models were calculated as the percentage of the total perimeter covered by each cumulative reconstruction. The model Total reconstruction time for both the groups JFM perimeter was measured as dimensions of walls on the mesh and documented (supplementary material). The unguided models swiftly achieved a high perimeter cover compared to the gradual stepwise growth of the guided models. At 120 images, the unguided group already had several overlapping images and reconstructed a complete  From crowd to cloud model (98%). However, images added after proved to be of less use as they only added redundancy and decreased surface smoothness. Interpreting the guided models, the boundary fulfillment grew through 0%, 45.8%, 57.8% and 97.7% for 40, 80, 120 and 160 images, respectively. This highlighted the optimal usage of input images and nearly absent redundancy. In the field, redundancy can be directly related to increased time, cost and inefficiencies to arrive at the same output. In summary, the validation experiment yielded noteworthy results (Table 4). One significant limitation is the absence of a sensitivity analysis of the reconstruction to the number of input images. An optimum was observed in the unguided group, but it is still unclear what is expected out of the field user in terms of image acquisition. The take of the author on this area is the clear advantage of using visually guided crowdsourcing for indoor scene reconstruction.

Evaluation
The evaluation seeks to understand how well the artifact supports the needs of the industry practitioners and supports further improvement. Evaluation was solicited in two stages. First, the smartphone application requested subjective responses when users completed the task. Second, industry experts were presented with a demonstration of the prototype or allowed to use the app themselves. Qualitative feedback was solicited and recorded.
3.5.1 Smartphone application responses. The participant survey used in the smartphone application recorded some subjective responses based on the experiment design. A short analysis of these responses is presented below. More than half the participants were interested in having a 3D model of their home or office. In general, participants expressed a willingness to perform this task without a specific incentive other than the final creation of a 3D model of their working space. In contrast, those participants who felt they would require an incentive of some sort for the opportunity cost mentioned incentives, such as money, gamification and food or beverage. The participants also provided feedback on potential use cases. These included interior design for a rental advertisement, Airbnb including mesh models of their homestays, 3D printing and so on.
All 10 participants answered that they were aware of what to capture after reading the instructions. This validated the usefulness of the Image Acquisition Manual. Two minor comments from the participants whose model did not contribute to the reconstructions (either individual or cumulative, P5 in both groups): there was confusion on how to align the mobile camera both vertically and horizontally to get the widest field of view. When asked if the partially reconstructed model assisted in capturing the set of images, the majority answered that the visualization of the model on the application guided them to acquire their pictures. However, one participant specifically stated that the model resolution was not good enough to visualize where to take the pictures. One mechanical, electrical and plumbing expert in the field tested the application to reconstruct a meeting room. Impressed with the results, provided confirmation that it is an easier, faster and effective workflow compared to manually modeling models from unorganized point clouds. The FM lead, happy with the results, perceived it as a digital platform where they could link all their static data. Other experts in digital twins foresaw huge potential in such a workflow and showed interest in integrating their solutions with their own reconstructed meshes to create a holistic service offering to the market. Another digital twin portfolio manager asserted the need for a complete pipeline. They proposed a potential use case to integrate the meshes with dynamic IoT data from their systems and achieve a digital communication platform.

Iteration and further use case development
Following the results and the analysis from the validation study, some of the use cases developed using Forge Viewer and other APIs are presented.
The classroom mesh was uploaded on the Issue and Information tracking application and tested for entering meta-data and tracking issues ( Figure 10). Image, link and file data were tagged to the mesh. Information and issues were added as text and monitored at a later point using the developed panel on the user interface ( Figure 11).
The 3D markup tool was also tested with the classroom mesh uploading some test images collected by the participants. The images were randomly assigned an identification and a customized icon (Issue, Information and Warning) (Figure 12).
In the multi-model configurator, a corridor mesh was chosen due to the frequent arrangement modification for exhibitions, displays and events. Three object models, a chair, Figure 10.

Issue and information
tracking on the Web browser From crowd to cloud a table and a white board were uploaded to be configured within the space. The object models can be scaled, transformed and rotated according to the user requirements. This opened doors for configuring spatial arrangements of event spaces, the interior of houses, storage facilities and any space whose functionality is dynamic.

Discussion
The resulting implementation achieves a realistic 3D model characterized by different typologies, minimal trade-off in accuracy, and low processing costs. By crowdsourcing the images, the proposed approach can reduce costs for asset reconstruction by an estimated 93% compared to manual modeling and 80% compared to locally processed reconstruction algorithms. The approach shows how techniques from CS and Machine Vision can be used to fulfill practitioner needs within a fragmented and conventional sector (AEC) that suffers from a lack of coherence and interconnection. Scarce adoption of prevailing tools could be perceived as Figure 11. 3D markup on the browser Figure 12.
Multi-model configurator JFM a question of acceptance and cultural baggage within the construction sector, simultaneously raising concerns on the knowledge gap between "the provider" and "the user."

Need-based paradigm
This work successfully interlinked the two different fields by using a bottom-up approach. The goal definition started from questioning the everyday hurdles of the AEC practitioners. The concept focused less on algorithm development rather took advantage of existing tools and optimized it for the demanded use case. It can be conclusively claimed that the users are more satisfied and readier to adopt even with a small enhancement in the process efficiency.

Building information model-as-complete vs building information model-as-needed
The past scholarly discourse has focused on achieving the conventional industry notion of BIM. BIM, at its completion, contains all information and relationships attached to the geometric representation of the asset. It is important to highlight the difference between perception and perfection in such a study. A simple 3D model, easy to navigate, containing only the required information, could pass as perfect for a specific user within the divided industry. Using a simplified approach resulting in BIM-as-needed can evidently reduce costs, time and increase efficiency within the industry. In addition, the requirement of the practitioners mostly revolved around the decision-making phase. A geometrically relevant, visually aiding and manipulative model on the browser can serve this need with high confidence.
The above discussion does not imply an anti-BIM notion. The resulting realistic mesh model from the workflow is flexible in terms of usage. It can be modeled manually or automatically to reach an enriched BIM status. Realistically, not all of the existing buildings can be digitalized. The ones that have or want to be can be converted smoother if innovations are designed as a speed breaker and not as a diversion in this journey.

Building information model as a basis for digital twins
Cloud-BIM integration is considered as the second generation of BIM development and is expected to produce another wave of changes across the industry . It does not take into consideration the current understanding and minimal exploitation of BIM within the industry. Furthermore, for existing buildings, BIM is near absent concept and the definition is commonly misunderstood.
This work discusses the potential of BIM as a basis for Digital Twins, a virtual duplicate of the physical environment. The suggested workflow already opens possibilities for such a concept. Buildings are living entities with human involvement. Data is smarter and more dynamic. It is evident that enriching models during data collection is a more feasible workflow rather than collecting data and then attempting to reverse engineer it. A mesh model on the Web, stored and retrieved in the cloud is one step closer to implement technologies like internet of things and Big Data. In addition, FM requires data capturing the current states and process of the building, which is made easier through a Web interface eliminating the need of desktop software.

Limitations and future work
Despite validation of the implemented workflow, some limitations are brought forward in this section. As explained in the literature review, a typical as-is BIM reconstruction pipeline is divided into two transformations. This work consciously dropped the automated modeling after attempting some existing algorithms. Future scope includes analysis on what possible modeling methods could be used and integrated with this workflow.

From crowd to cloud
The technical capabilities of the smartphone application are bounded by its development environment and API provider (Autodesk Forge). At this point, users can upload only one image at a time (from camera roll/instantaneous shot) using the prototype. A common benchmarking of the benefits of automatic reconstruction is necessary. At what point does automation surpass manual effort? The size and investment of the projects must be the deciding factors in calculated adoption of such a tool.
As all data is hosted on a cloud storage architecture, the questions of governance, ownership and security become key.
This work concludes the adoption of guided crowdsourcing is more suitable for reconstruction of indoor scenes. A sensitivity analysis on the number of pictures is not considered, especially in the unguided crowdsourcing task. This might lead to redundant effort and costs overshadowing the automation.
Reconstructed models are manually oriented, not locally or globally referenced to the building. Existing algorithms allow automatic orientation, often needing another data point such as an inertial sensor or Wi-Fi for indoor localization. Mesh gluing; attaching different individual reconstructed zones to one big model is currently manual. Scholarship in this aspect is scarce and could be a beneficial addition to this implementation.
Some other concepts that deviate from the core of this work but could potentially contribute are: Segmentation by crowdsourced annotation of mesh model, i.e. involving humans earlier in the loop for accuracy. Reconstructing remote buildings by scraping images from internet websites, such as Facebook, Instagram and Twitter. Firms with a global presence could reduce project costs with such an implementation.

Conclusion
Using the DSR, this work provides a firm base for innovative research and potential business models in the operation and maintenance phase of the building lifecycle. This work stands out in developing, testing and validating a mobile-to-mobile novel crowdsourced cloud-based approach for the reconstruction of digital building assets. It started as a question of technical possibility and, in due course, transformed into a "one-click, all done" solution by incorporating the needs of the industry. We use futuristic technologies, such as Autodesk Forge and Serverless Computing, turning the reconstruction process into a parallel and dynamic computing process. The crowdsourcing reduced the huge burden in data collection, secondarily aiding in understanding the importance of human behavior and mentality, which acts as a prime factor in the construction industry. Results of study demonstrated that a realistic 3D model of different typologies can be achieved with minimal trade-off in accuracy and roughly one-fifteenth of the manual costs. The workflow is also five times cheaper than using a representative automation pipeline existing today. Use cases were developed as Web applications serving different demanded functionalities. The retrospective approach is a strong ground to conclude industry-readiness. As for any work, the assumptions and limitations pave the way for future research.  Figure A4(a)]. The Forge ReCap reconstruction [ Figure A4(b)] was managed through CURL commands. Figure A2. Field test classification Figure A3.
(left) Acquisition path in HIL E7

From crowd to cloud
The raw output of Colmap was a dense point cloud, while that from the Forge reconstruction engine is a triangulated mesh. The results (Table A3) discussed pertain to cleaned (removing unwanted visual noise) point cloud/mesh. Colmap and Forge reconstruct the output in an arbitrary scale with relative distances between the surfaces. This is transformed to metric (real world) scale by one controlled measurement. Total cost [9] was calculated as the product of active manual time and the average planner cost per hour. Active time: minutes/hours of manual effort to arrive from real world scene to reconstructed model. Passive time: minutes/hours of machine effort.  No occupants/moving objects Table A2.

JFM
The Colmap graphical user interface (GUI) required the user to be on screen for the four distinct steps: Feature Matching, Feature Extraction, Sparse Reconstruction and Dense Reconstruction. In-built meshing algorithms were not suitable for indoor scenes due to the amount of clutter involved. The algorithm was computationally intensive occupying full process memory and graphics memory on a high-end laptop [10]. Consequently, the machine time overlapped with human effort while using Colmap. The situation was entirely different for the Forge engine as the only local activity was to upload the images using the CURL commands. A stable Wi-Fi connection proved more than sufficient. The wait time during the reconstruction could be used as man-hours on some other activity. This conclusively eliminated a lot of active time and cost. The presence of windows on one side of the corridor influenced Colmap to reconstruct a lot of external noise. Autodesk Forge engine differentiated the internal and external zones and reconstructed the window as an overlaying frame.
Colmap results are output as. Ply and interconvertible to several other point cloud/mesh formats (such as .pts, .xyz, .obj). The Forge reconstruction results can be requested from the cloud cluster in . rcm (high resolution streaming ReCap textured mesh) or .obj (open-source textured mesh), which can be post processed to any other format. The Forge API also provides management for notifications through e-mail once the reconstruction is complete, which was implemented in the testing.
Similarly, for the office, a total of 42 images were captured and processed through Colmap [ Figure A5(a)] and Forge [ Figure A5(b)].
The detailed results are tabulated (Table A4). The distortion and noise due to the presence of full wall sized window in the office room turned out higher than the corridor case in both algorithms. This can be attributed to the increased variation in the external environment which SfM cannot recognize as features of the captured zone. Colmap matched 34 out 42 images requiring a total time of 71.5 min. The cloud reconstruction took 39.5 min, with just about 16% active manual time.

Figure A5
(a) Colmap reconstructed office; (b) forge reconstructed office From crowd to cloud These tests were used as a learning method to understand the intricacies of image acquisition, limitations of the reconstruction algorithms and guidance for the field test. The outcome of this test was twofold. The first being the "Image Acquisition Manual," which is a step-by-step best practice guide for users to capture data for an optimal reconstruction. The other outcome was the understanding of time (influencing cost) consumption by the different tools, influencing the field test design. The conversion of point cloud/mesh to a surface/volumetric model was attempted with two chosen academic algorithms. Cleaned and ordered corridor and office point cloud/meshes were input into Manhattan Modeler and Structured Indoor Modeling. Manhattan Modeler produced appreciable result ( Figure A6) for the corridor case whereas failed with the office for a high amount of clutter. This is justified by the specific algorithmic design as it was developed for reconstructing exterior urban scenes from point clouds and did not include high tolerance to indoor objects. The source code of Structured Indoor Modeling was modified by the author to accommodate this study. However, the output from the implementation was unsatisfactory as the script worked with free space and point space evidences (Ikehata et al., 2015) of registered and ordered point clouds. The resulting geometry was a reduced cube neglecting the actual boundaries of the generated mesh.
1.2.2 Field testing. Both the non-textured and textured scenarios of the classroom had 136 images captured, all factors remaining the same. The outcomes of non-textured ( Figure A7) and textured ( Figure A8) differed in how the texture-less surfaces were reconstructed. Metrics similar to the initial tests are recorded (Table A5) with addition of geometric accuracies (Table A6).  The non-textured room was only partially reconstructed due to the absence of any variation in color or surface gradient on the other three walls. The sticky notes behaved as differentiating texture rendering a more suitable reconstruction. The differences between Colmap and Forge were similar to the initial tests for both non-textured and textured studies. It was observed that the number of images dropped in the textured case was considerably lower (3.6% as compared to 19% in the nontextured), highlighting the fundamental need of gradient in the images for feature matching. The numbers showed that Forge reconstruction is faster compared to Colmap. However, the difference in speed of reconstruction between the tools decreased as the number of images increased. The geometric accuracy of the reconstructed models was assessed by manually measuring 11 distances within the test room. After scaling, the meshes were sectioned and the corresponding points were identified and measured. Both the pipelines resulted in highly tolerant reconstructions. The maximum difference in distances was 38 cm for Colmap versus 17 cm for Forge.
A comparative analysis was conducted using the results from the field test. To assess the generality, the same analysis was also performed for the initial tests. The corridor and textured auditorium are considered as full reconstructions for this analysis (Table A7).
Interpretation of the results concludes that transforming mobile captured into images into point cloud/mesh models are faster with the Autodesk Forge API compared to Colmap. Using the Forge infrastructure eliminated the need for computing power, which previous scholarship has classified as the largest hindrance for graphical reconstruction. The processing cost is lower in the cloud pipeline. This can be attributed to the requirement of manual intervention and inability to use the local From crowd to cloud machine for other activities during Colmap runtime. Two major positives of Forge API's are modularity and scalability. Both the pipelines were geometrically accurate, Forge API performing considerably better than Colmap. However, Colmap performed extremely well in terms of robustness and structural representation of the output. This conclusion might be biased because of different output formats. Colmap results are visualized and point clouds as compared to meshed Forge models. Meshing algorithms use surface smoothening and this might be the cause of uneven surfaces in the Forge model. Of worth mentioning is the accessibility of the source code for Colmap. In theory, it was possible to customize the tool and call the functionality from any other self-developed software. This demanded user learning and the final tool could only be implemented locally. The Forge pipeline overtook in this aspect with several code samples, extensive support in development and Web/mobile implementation possibilities. The level of automation is perceived as the distribution of total processing time between active (manual) and passive (machine) time ( Figure A9). It was observed in all cases that a satisfactory expected reconstruction was achieved with lower manual intervention through the Forge pipeline. The automated modeling algorithms did not provide successful results for the field tests. This was due to the indoor clutter in the auditorium. The use cases attended did not demand a highly accurate volumetric model rather a digital asset that served their purpose. In this work, this approach is defined as serviceoriented or need-based paradigm.  Figure A11. Graphical user interface -Colmap Figure A10.