Suggestions on using the cached tiles |
In a scale, the more tiles of the map we get, the higher hit rate they will be. However, the greater hit rate could also result in the huge amount of tiles to be transferred, which will, in return, affect the map response time. Therefore, we need to find a balance between the server concurrency and the network traffic. In other words, the client side should display maps in an optimal way.
For preparing tiles, you can take account of the following factors.
SuperMap iServer supports map tile, vector tile, and attribute tile. Tiles can be used for online sharing and offline viewing. You can choose proper types of tiles according to your practical situation.
Map tile refers to tiling maps to raster pictures. It supports FastDFS (distributed storage), MongdoDB (distributed storage), SMTiles, MBTiles, and SuperMap UGC. SuperMap UGC type is the common and traditional type which can be used in all SuperMap products if the SuperMap UGC tile versions are the same. The UGCV5 tile is just refers to V5.0 original cache.
In addition, the picture format of the map tiles include PNG, JPG, GIF. If you choose PNG and the color value is less than 256, pictures will auto stored as PNG8 in SuperMap iServer for saving more storage space.
The vector layer can be splitted and stored as the vector tiles. iServer supports SVTiles.
In the real map service field, users not only view maps, but also query, select or highlight elements on maps. So, element service becomes a necessity. Similar to the improvement of map tile access, the rendering of elements on the client side can be improved by pre-caching vector data. Here comes the vector tile technology. The storage space of vector data is smaller than map tiles, so it is more suitable for expressing geospatial elements which requires timeliness, such as POI, routes, etc. The popular online map services, such as Google Maps, Baidu Map, use map tiles as the base map and vector tiles as element service.
The attribute data in the vector layers can be stored as the attribute tiles. iServer supports UTFGrid.
In the real map service field, if there are massive mouse interactive operations, in the traditional way, we will overlay the element layers on the maps, and every element has its own hot spot and event. However, in the environment of massive amount of data and high concurrent requests, the clients, especially the mobile terminal, cannot smoothly render so many geographic elements. In this case, we choose another way, that is, every tile also records the attribute information. In other words, we input attribution information, divided by grids, of elements into the original tiles. This pre-stored element attribute information for each tile is so-called attribute tile. The integration of map tiles and attribute tiles has been widely used in many sectors. The most typical one is MBTiles specification and its subsidiary UTFGrid specification.
There are two sizes of tiles in the precaching services of SuperMap iServer: 512*512 and 256*256.
When visiting the map service of SuperMap iServer with the tiles layer of the iClient, by default you use the 256 * 256 image. For example, iClient for Ajax can use SuperMap.Web.Mapping.TiledDynamicRESTLayer (default is 256 * 256); iClient for Silverlight can use SuperMap.Web.iServerJava6R.TiledDynamicRESTLayer (default is 256 * 256). Of course , you can also change the TileSize into 512 * 512.
You need to set the size of the cache image during caching so as to take advantage of precaching.
To take full advantage of the precaching service of SuperMap iServer and realize multi-scale zoom, you can precache a map into multiple scales of caches. Setting the scale array on SDK of SuperMap iServer such as for JavaScript, for Flash and for Silverlight to realize the multi-scale zoom.
Take iClient for JavaScript for example, sets the scale array of the map into the same scale of precaches. All the layers of the map during scaling will only display the scale of the precaching images.
Users can precache the frequently accessed map area, and then generate dynamic caches for the less accessed map area according to their needs.
For example, when accessing a world map, we usually don't pay attention on the sparsely populated areas which don't need generating caches, and hence we can specify the map into areas as shown in the figure below: