mapConfig.json file which is the first file the client asks for and which contains complete configuration needed to render given map.
The VTS Mapproxy is an HTTP server that performs on the fly conversion of non-VTS GIS formats (GDAL rasters, OGR vectors, Mapbox vector tiles) to VTS streaming formats like surfaces, bound layers and geodata that are directly usable by clients. Part of mapproxy that deals with imagery can be viewed a powerful SRS transforming TMS server.
The vtsd (aka VTS-Daemon) is a thin HTTP server with nginx-like configuration streaming static tilesets as surfaces and free layers. Usually, the only static tilesets are 3D models and corresponding glues from storage. To read the static tilesets, vtsd implements TILeARchive - an efficient format for 3D tile hierarchy storage.
Generally, if you intend to work with 3D models or you want to create some complex map configurations, you will always need the vtsd and a storage.
It is expected that streamed resources (especially dynamically generated ones) are cached somewhere in the network layer. Both mapproxy and VTSD serve configurable caching headers for this purpose. We recommend setting up the VTS Backend using vts-backend package which takes care of that by inserting thin nginx caching proxy in front of both mapproxy and VTSD.
Data Management Tools¶
The vts is referred to as a Swiss army knife of VTS storage management. The storage is a filesystem-based datatabase that contains all tilesets (both static and dynamic) and all glues between those tilesets. The glues ensure that any combination of tilesets can be displayed together in seamless fashion. The vts command line tool takes care of all operations around storage, such as storage creation, tileset adding with corresponding glue creation, tileset removal and many others.
Mapproxy tools take care of raster preprocessing for mapproxy. This includes overview generation (generatevrtwo), dataset measurement (mapproxy-calipers) and creation of tiling metainformation (mapproxy-tiling). There are also helper scripts that shrink data preparation for mapproxy in a single command.
Encoders are used to convert external hierarchical mesh formats (VEF, I3S/SLPK, LODTree) into VTS tilesets. Currently, there are vef2vts, slpk2vts and lodtree2vts. There is also vts2vts that can be used to convert tilesets from one reference frame to another if there is a need but this practice is discouraged because of possible quality loss.
All rendering libraries consume the same data from the backend, provide sample browser and API allowing them to be plugged into existing (web)applications or build applications on top of them.
The vts-browser-js is all encompassing WebGL-based VTS client-side implementation with comprehensive API and very small footprint - currently about 176 kB gzipped and minified. It works in all modern browsers with rudimentary mobile support.
The VTS-Browser-cpp is a multiplatform lightweight c++ client library. It is separate from actual rendering layer, although a thin rendering layer based on modern OpenGL or OpenGL ES is also provided. It may be used for building full-fledged VTS based applications form scratch. There are currently several example applications. First, a fancy desktop application with advanced controls, search, layers configuration and many customization options. Second, an iOS application with two different touch controls available. We also have minimal applications for each language binding: c++, c and cs. Finaly, we provide a plugin for VTS integration into Unity 3D game engine.
Sample production setup¶
Typical production setup of the whole stack may look like the following: