# Geo-Spatial Context Provision for Digital Twin Generation
## 4 Related Work
### Geo-Spatial Context, LiDAR Technology, and Digital Twins  
A wide selection of existing research from different fields focuses on the geo-spatial information of some sort of asset itself (or of multiple assets) as the central building block of a digital twin. In [34], LiDAR scan data was used to create a digital representation of a bridge that can be viewed in a virtual reality environment to facilitate bridge inspection. The authors in [36] proposed a framework for the geometric quality assessment of facades, based on digital twins. A 3D as-built digital replica (enriched with semantic information) is created from LiDAR point cloud data of the physical facade and compared to the as-designed model. In [37], a methodology for the creation of digital twins of large-scale structures based on RGB images and LiDAR scans was proposed and demonstrated for a wind turbine transition piece. The twin can be updated in regular intervals to reflect the current physical state of the structure. Specifically, based on the comparison between 3D reconstruction and the initial design of the structure, geometric deviations and production tolerances can be discovered and assessed. The authors also provided an algorithm for detection and classification of paint defects from the captured images, which can be mapped to the 3D reconstruction. In [14], a workflow for creating digital twins of trees from 3D point clouds produced by a mobile LiDAR scanner was discussed. The authors of [38] aimed to automate the population of a digital twin of the city of Singapore with tree models (following the CityGML standard), with (mobile and airborne) LiDAR being among the used data sources. The modeling of city objects from LiDAR point clouds to subsequently support the creation of digital twin cities was discussed in [39], with the authors providing an unsupervised method. In [13], an automated inspection system for power lines was described, using a multi-modal sensor system, including LiDAR technology. Sensor data and inspection results are organized to create a digital twin of the power line. The 3D point cloud is semantically segmented, a 2D object detector is run on captured RGB camera images, and the resulting 2D bounding boxes are combined with the segmented point cloud. This forms the basis for the digital twin representation of the line. Similarly, in [16], a system for vegetation management in power line corridors was proposed. To this end, the authors created a digital twin by fusing data derived from LiDAR scans together with other relevant data sources through their proposed processing pipeline. They also provided approaches for encroaching vegetation detection and data segmentation for learning vegetation growth simulation. In [40], a digital twin of an intersection was created to enable the real-time monitoring of intervisibility between pair-wise conflicting agents. To this end, point cloud data and trajectory data of traffic participants is used as inputs. First, conflict points and their associated agents are identified, and agents are modeled as 3D bounding cuboids, representing road users in real-time. Subsequently, dynamic line-of-sight analysis is performed and virtual warning signals can be given based on the results. Compared to the digital twin conceptions underlying most of the approaches listed above, where the focus lies on the geo-spatial information itself as core of the twin, our approach starts with the behavior of certain active assets in an environment (CPS components) and adds the geo-spatial information as context (together with and in relation to other context data) to increase the semantic richness of the behavioral twin. For certain examined applications, the geo-spatial context information needed for generating the twin is captured once, e.g., to facilitate one inspection task of the twinned asset (e.g., [34; 36]). The twin is sometimes also consistently updated to correctly reflect the state of the physical object(s) and changes over time (e.g., [13; 37]), depending on the underlying use case.