## 4 Results
### Data Visualization
#### 4.3.2 Features of the Mobile Application  
The 4D City application is a browser-based web application that runs on iOS/WebKit and Android/Chrome browsers. The application is built by using Angular and three.js. Users can explore the scene at their current location. This requires access to device sensors, i.e., geolocation and device orientation sensors. By limiting the user's geolocation and the view to a first-person perspective, there is no need to load a huge 3D city model, only the buildings in the vicinity, which reduces the amount of data transmitted. All content with spatial attributes is usually delivered in polar coordinates, i.e., WGS 84 (latitude, longitude). Since the 3D scene requires a Cartesian coordinate system, the spatial attributes are converted to a metric system, specifically UTM coordinates, which preserve the actual dimensions. The following sections present the main features of the 4D City application. Figure 19: Technology stack and communication layout: the backend application queries and serves custom data to the frontend applications, but also requests and caches data from external APIs. Projective Texturing  
The users explore the scene from a first-person perspective. This contrasts to the 4D Browser, where a cityscape is explored more from an aerial perspective. To let users experience historical photographs of the urban scenery in the 4D City application, the photographs are used as textures on the 3D geometries. A huge number of spatialized photographs can be used as potential textures, but not all of them might be suitable, so only a small number should be selected and assigned to each building geometry. Which photographs are potentially good textures for which buildings is determined in a two-step process. An offline background process on the backend first determines which buildings of the 3D city model are actually visible from the camera perspective in the year the photo was taken for each photo. The scene at this point in time is rendered from the perspective of the photograph (a) with unique colors for each building and (b) as a depth map. A weight value can then be calculated from the number of pixels a building covers in relation to the total number of pixels in the image. In addition, the distance derived from the gray value of the depth map affects the weight value. A building close to the camera position is given a higher weight than a building further away. The weight value is stored in the database as a relationship between the building and the photo. It is now possible to query the 3D geometry of buildings with potential textures sorted by weight (Figure 20). Instead of assigning different UV texture coordinates and multiple materials to the 3D building geometry, a custom shader is used to project multiple images onto the building surface at runtime. The number of photographs passed to the shader as texture units is currently limited to six in order to support older devices that have a limited number of fragment uniform vectors. With each texture, the virtual camera's transformation and projection matrices are also passed to the shader. The fragment shader determines which parts of the textures should be applied to the surface and where. For each pixel, a weight value is calculated for each virtual camera c_i. If the surface position p is outside the frustum of the respective virtual camera, or the surface normal points in the opposite direction, the weight is zero (\(\omega\_i=0\)). Otherwise, the vector v_i between the camera position and the surface position is calculated and the weight depends on a) the angle \(\alpha\_i\) between v_i and the surface normal n and b) the length of v_i (i.e., the distance between the two positions). The highest ranked virtual camera or texture is applied to this pixel. Thus, for a given part of the geometry, the texture with a more perpendicular view to the surface and which is closer (i.e., shows more detail) is selected.