Those gvSIG users that usually load WMS layers know very well that the response time, each time we pan or zoom on the view, is not insignificant. If, besides, we have more than one WMS layer loaded, the response time is even lower, which could require a big dose of patience. gvSIG 2.0 brings two new features that improve the user experience when accessing remote raster data.

The first of them is the WMTS (Web Map Tile Service) support. This service is a OGC standard which aim is just fix the mentioned performance problems of the WMS by using tiles. Tiles are portions of image that provides the server and that are stored in our hard disk, being locally accessible from that time on so the software don’t have to connect to the server anymore to load that data, improving the response speed. In the following video we can see gvSIG accessing a WMTS.

Despite a increase of the number of WMTS servers available is expected, nowadays there are far fewer WMTS servers than WMS ones, which makes even more interesting the second of the new features this post talks about: the raster data tile cache.

Raster data tile cache consists on applying the WMTS principle, this is, managing tiles locally, to all raster data sources in general. This is particularly interesting in the case of WMS as it reduces the data traffic through the network and, thus, the response time. In the following video we can see the difference between accessing a WMS with the tile cache option activated and not activated.

The difference between the tile managing in the case of WMTS and in the case of WMS is that in the first case the tiles are generated in the server side whereas in the second case they are generated in the client side. This means that, in the case of WMS, the first time we visualize a specific zone at a given scale the response time is not specially good as data is accessed through the Internet, but the following time we visualize the same zone at the same scale the response time is appreciably higher. Thus, a good practice would be to pass all over the zone we are going to work with, at different scales, as a first step, so all the needed tiles are stored in the cache memory.

Another thing to take into account is the tile size. Each tile involves a network request so the lower is the tile size, the higher number of requests will be done and, thus, more time will be needed to load the whole view extent. It is important to say that this is not only a problem for users but also for servers. Making massive requests involves a strong work in the server side. For both reasons it is strongly recommended to configure a relatively high tile size (e.g. 1024) for the remote raster data source (WMS/WCS) within the menu Preferences>Tile cache.

We hope that you enjoy this two new features.