VTS Geospatial is one of the few end-to-end open-source solutions when it comes to 3D mapping. It is a complete set of technologies that enables its users to build and operate 3D geospatial applications at any scale, with any level of detail, for almost any platform. It was designed and developed specifically with big geospatial dataset fusion and streaming in mind. The article deeply describes VTS Backend, which creates one pillar of the VTS Geospatial stack and makes the whole system unique.

VTS Backend is a package of several technologies that allow, among other things, management, reprojection, fusion, and streaming of basically any kind of geospatial datasets you might want to serve to the clients of your applications. It is composed of two geospatial data streaming HTTP 1.1 servers, VTSD and VTS Mapproxy, a CLI (command-line interface) toolbox that holds various encoders and utilities and VTS Registry – a central configuration that contains all reference frame and spatial reference system definitions. To install all the components is as easy as to run a single line of code in the command line.

VTS Backend is a massively scalable and performance-oriented system, with some unique characteristics when compared to other 3D mapping technologies. The following paragraphs describe VTS flexibility when dealing with reference frames and at a wide range of supported geospatial formats.

Reference frame flexibility

One of the key concepts of VTS Geospatial is a reference frame. It can be thought of as a blueprint for interpreting the spatial aspect of the data. It is a set of spatial references that handles all the complexities of working with 3D data from mesh and vector layers geometry, to navigation on a virtual globe, a spatial division into tiles or interfacing with the user in a comprehensible way.

VTS Geospatial doesn’t enforce usage of a specific spatial reference. Reference frames are declared in human-readable configuration files within VTS Registry and the user can define as many reference frames as they need. Since VTS employs PROJ library as one of its building blocks, it is compatible with most coordinate reference systems, projected or geodetic, that you might need to work with. Even if you handle datasets referenced in some national/regional system, there is a good chance that you’ll be able to fuse and stream that data from VTS Backend natively in that specific CRS.

One of the advantages that emerge from such an approach is the fact that you can rather easily define an appropriate spatial reference also for extraterrestrial bodies – planets, asteroids or stars. A common mapping scheme for referencing celestial bodies is QSC – Quadrilateralized spherical cube, an equal-area projection with moderate and evenly distributed distortion across the depicted body.

This concept gives VTS users great freedom to define a specific reference, but once a user works within some ordinary setting, there is no need to dive into the reference frame complexities. VTS Backend comes with several reference frames pre-defined for convenience. Whenever on Earth, use the ”melown2015” reference frame. It contains a subtree in WebMercator projection for the bulk of the Earth and subtrees with polar caps in corresponding stereographic projections. Due to the geocentric physical system, it gives the look of a nice round Earth including polar caps. Thanks to the WebMercator subtree, you might use Google Maps, Bing Maps, Open Street Map, 2D maps on Here Maps and other mapping data providers as an external bound layer.

One of the huge advantages of VTS Geospatial is the support to visualize data from celestial bodies. When creating a mapping project on Mars, there is a mars-qsc reference frame ready for you out of the box as well as some other celestial bodies in the Solar system. As a matter of interest, mars-qsc represents Mars as a folded-out cube. This makes things easier because you don’t have to spend time with reference frames complexities and can stay focused on your application development instead. But if your project requires a less common reference frame, VTS Geospatial will not limit you.

Geospatial data support

When it comes to geospatial data format support, VTS Backend lets you read basically any common raster and 2D vector format, as it relies heavily on the GDAL/OGR library under the hood. Support for vector tiles (i.e. Mapbox Vector Tiles) is also very useful, especially when the spatial extent of your project grows big. Loading and rendering large monolithic vector layers over a wide area might be a serious killer of your application’s performance.

When it comes to the styling of vector data, VTS does that through a JSON file, a VTS specific style sheet, inspired by CartoCSS and extended for 3D mapping purposes. The stylesheet is stored as a separate top-level resource and referenced within the configuration file of a specific map. It is the main controller or all the vector datasets within a given map. It enables you to define the appearance of the data, and also clamp layers into groups or specify rules that will drive their visibility. It gives VTS users a versatile tool to define complex hierarchical patterns, specifically designed to address challenges that 3D cartographic functionality and visual hierarchy come with. To learn more on this topic, watch this talk from FOSS4G 2019 in Bucharest.

VTS Backend also has native drivers for serving data provided by WMS and WMTS services. It is a convenient way to source large extent, general level layers, typically base-maps or satellite imagery without the need to host the data on your infrastructure. Once configured, VTS clients may request the data from connected service providers directly or make it run through VTS Mapproxy in case any transformations or other processing steps are required.

To stream and visualize 3D content, whether it’s Digital Terrain Models or True 3D Geometric reconstruction of reality, VTS uses its own data format. It is designed specifically for the purpose of 3D data streaming and storage efficiency and server-side data manageability. Other common 3D formats aren’t directly supported in VTS clients (frontend libraries). However, VTS Backend comes packed with encoder CLI tools, that allow converting the most common hierarchical 3D mesh formats into VTS. Currently, there are tools to convert data from Cesium’s 3D Tiles or ESRI software’s native SLPK format, both recognized by OGC.

In conclusion

To sum up, VTS Backend is a powerful solution for managing and serving 3D geospatial content. It was designed to offer its users freedom to work with a wide variety of data formats and to use arbitrary spatial reference systems, to address each project’s specificities. VTS Backend comes with several basic configurations out of the box that will be compliant with most of the common project’s requirements. Users can thus focus on their data and application development, without the need of putting much attention to these low-level settings.

VTS Backend has some other remarkable characteristics when it comes to data fusion and data streaming. These will be introduced more in-depth in the next blog post. If you’d like to explore more and play around with VTS-backend you can find some guidance and/or inspiration for that matter at VTS Geospatial tutorials page.

Ladislav Horký, CTO

Ladislav is the person in charge of all 3D mapping projects carried out in Melown Technologies. As such, he is both an expert in the subtleties of Vadstena, Melowntech's 3D reality-capture system, and a power user of VTS geospatial software stack.