Recently, there is no personal computer has the ability to satisfy the requirementsof loading the basemap tiles and oblique photogrammetry models at a time. Besides, 3D GIS not only need to load oblique photogrammetry models to display the realistic effects, but also need to load the basemap tiles with different functions. However, as the number of the basemap tiles increase, the number of requests sent by the client to server increases, resulting in excessive load on server. Eventually, the speed of the 3D GIS will drop off.
This paper proposes a dynamic strategy for loading basemap tiles to solve the above problem. The main idea of the strategy is that the basemap tiles loading is determined by the height of view and the range of the oblique photogrammetry models.
2. Data Introduction
2.1. Data Acquirement
We have acquired the raw images by drone equipped with sensors in five directions: vertical, font, rear, left and right . Approximately geographical coordinates in each image were recorded during aerial photography. Meanwhile, the ground surveyors provide ground control points with more accurate geographical coordinates. Then, these raw images with geographical coordinates can be converted to oblique photo-grammetry model by Context Capture Master. Finally, in order to obtain the final data in b3dm format, a series of format conversions have been applied.
2.2. Data Storage
As for the storage of oblique photogrammetry models, this paper adopts HLOD data structure  . As Figure 1 shown, from top to bottom, data resolution becomes higher and higher. Regular grid partitioning will be applied to single file which is extremely large. The files in different levels are named by the method shown in Figure 2. Figure 2 showed that data in different levels has different filename length. And the data index of the same level is different. Not only the hierarchical structure but also the geographical extent is recorded by the index file. The extent bounding box is recorded in the order of West, South, East, North, Lower, and Upper (Figure 3). Because of the lightweight of JSON data format, the storage format of the index file is JSON.
Refer to basemap tiles, Cesium builds a quadtree index in the same way as Bing map and Google Earth based on WMS service . The index of each basemap tiles corresponds to a certain tile extent under the specified hierarchy (Figure 4).
Figure 1. HLOD data structure.
Figure 2. Oblique photogrammetry models file naming rules.
Figure 3. The tile range contained in the json index file (west, south, east, north, bottom, top).
Figure 4. Bing Maps Tile Partition (Source: Microsoft).
3. Strategy Data Loading in Cesium
Cesium adopts the OOC (Out of Core) algorithm  for loading massive data. Due to the limited computer memory, the global data loading and processing at once are impossible. Therefore, only the data within the view frustum will be loaded and processed  .
The loading strategy of basemap tiles and oblique photogrammetry models in Cesium is: the loading of the basemap tiles and the oblique photogrammetry models are decided by the height of view and the scene range. Once the height of view is high and range of scene is large, Cesium loads low resolution basemap tiles only. On the contrary, once the height of view is low and range of scene is small, Cesium loads relatively high resolution basemap tiles and oblique photogrammetry models. Another case is that Cesium will load higher resolution basemap tiles and lower resolution oblique photogrammetry models when the height of view and range of scene are moderate.
However, the whole scene will be covered by the oblique photogrammetry models when the height of view is low and the scene range is small. At the moment higher resolution basemap tiles in covered area don’t need to be loaded.
4. Basemap Tiles Dynamic Loading Strategy
When the height of view is low, both the oblique photogrammetry models and basemap tiles require to be requested, loaded and rendered. Nevertheless, if the number of basemap layers is too large, the requests sent by the client increase, the system runs slower. Therefore, the excessive load of server can be relieved by reducing the requests of the basemap tiles from client. When the requests from client decrease, performance of 3D GIS will improve greatly.
4.1. Coverage Area of Oblique Photogrammetry Models
Oblique photogrammetry models and basemap tiles exist in the form of tiles. The range of oblique photogrammetry models is determined by the way of data division. While the range of basemap tiles is determined by specific data partitioning standard. The data division criterion between the oblique photogrammetry models and basemap tiles are different.
In order to speed up scene loading, the covered range of oblique photogrammetry models should be calculated in advance. The geographical range of each oblique photogrammetry model is recorded in the index file. Therefore, covered range in certain area can be calculated by the union of all oblique photogrammetry tiles (Some areas are shown in Figure 5).
4.2. Restriction Requests to Basemap Tiles
The strategy for dynamically loading basemap tiles means that the loading of basemap tiles is determined by whether the oblique photogrammetry models are loaded. When the height of view does not satisfy the condition of loading oblique photogrammetry models, only the basemap tiles are loaded; when there are oblique photogrammetry models loading, it is necessary to have some judgements on whether the current basemap tile to be loaded will be covered by the loaded oblique photogrammetry models. The judgement procedures are as follows (Figure 6):
1) Acquiring the coverage range of each oblique photogrammetry model in current scene;
2) Calculating the union of all the ranges in the corresponding area according to the range of each oblique photogrammetry model;
3) Acquiring four vertices of the basemap tile that needs to be loaded;
4) Calculating whether the four vertices of the basemap tile are include by the coverage of the oblique photogrammetry models;
5) Restricting the request of current basemap tile if all four vertices are within
Figure 5. Covered range of B3dm tile.
Figure 6. Flowchart loading b3dm oblique photogrammetry models and basemap tiles.
the union range of the oblique photogrammetry models, because the basemap tile will be covered under the oblique photogrammetry models;
6) Requesting the basemap tile if any of the four vertices of the base tile is outside the coverage of oblique photogrammetry models.
In order to demonstrate the performance of our strategy. In this section, the experiment is carried out based on 1 basemap, 5 layers of basemap and 10 layers of basemap. The number of requests for b3dm oblique photogrammetry models and the basemap tiles was recorded during the experiment.
The experimental data includes the National University of Defense Technology campus, Fenghuang Ancient City and parts of Changsha City. Three groups of experimental loading scenes shown in the Figure 7.
In Figure 8, we compare the dynamical basemap tiles loading strategy proposed in this paper with Cesium’s existing basemap tiles loading strategy. The comparison diagram of the number of basemap tiles requests, b3dm requests and total requests in National University of Defense Technology Campus is shown in Figure 8(a). The same experiments were also carried out for the Fenghuang Ancient city and some areas of Changsha, the experimental results are shown in Figure 8(b) and Figure 8(c) respectively.
The experimental environment is Intel® Core(TM) i7-7700K@4.20 GHz 64GB RAM, NVIDIA GeForce 1080 MB; 69.0.3497.100 version of Google Chrome, win7 64-bit Ultimate OS.
Figure 7. Scenes of b3dm data loading.
Figure 8. Comparison of request number. (a) National University of Defense Technology Campus; (b) FengHuang Acient City; (c) Some areas of Changsha.
In 3D GIS, loading multilayer basemap and oblique photogrammetry models simultaneously will lead to excessive number of requests from the client, which slows down the speed of 3D GIS. This paper proposes a strategy for basemap tiles dynamical loading. The strategy loads oblique photogrammetry models preferentially, and limits the requests of basemap tiles. In other word, the loading of basemap tiles is affected by the oblique photogrammetry models during the browsing from the users. It is not necessary to load the basemap tiles if they are covered by oblique photogrammetry models. The experiment shows reduction in the number of requests for basemap tiles can greatly improve the performance of 3D GIS.
The requesting, loading and rendering of b3dm oblique photogrammetry models will not be affected by restricting the requests of basemap tiles. Consequently, the strategy proposed by this paper can improve the running efficiency of the entire system without affecting the overall use of the system
Thanks to the 2nd Surveying and Mapping Institute of Hunan Province and Changsha Municipal Bureau of Land and Resources for providing us with oblique photogrammetry model for experiments.
 Niu, N., Li, C. and Guo, L. (2013) The Application and Research of Geoprocessing Service in WebGIS Spatial Analysis. 21st International Conference on Geoinformatics, 1-4. https://doi.org/10.1109/Geoinformatics.2013.6626054
 Miao, R., Song, J. and Zhu, Y. (2017) 3D Geographic Scenes Visualization Based on WebGL. IEEE International Conference on Agro-Geoinformatics. https://doi.org/10.1109/Agro-Geoinformatics.2017.8046999
 Song, Z. and Li, J. (2018) A Dynamic Tiles Loading and Scheduling Strategy for Massive Oblique Photogrammetry Models. IEEE International Conference on Image, Vision and Computing (ICIVC). https://doi.org/10.1109/ICIVC.2018.8492731