In my previous article, I discussed about how to publish map layers using web services here. This article is continuation with it, which focuses on how to increase the speed and performance of web mapping applications.
As a GIS developer, I feel this as a challenge every time I develop or think of developing new application. One of our client always asks, is there any way to speed up the rendering of the map layers? I feel it was a genuine request. The layers were too slow to load and infact we need to refresh the browser sometimes to render all the layers. I have done some googling about how to speed up the rendering of WMS layers and I found few solutions like creating spatial indexes and zoom based filtering and regionated layers etc.., which were not that efficient in enterprise wide application where you will be dealing with multiple layers and multiple users requesting multiple layers at frequent intervals. I came across a solution to my problem after spending a fair amount of time in searching online.
The solution was to use some kind of a cache server in between your WMS Server and Client application. It uses caching technique to cache your wms layers as tiles and communicate with the server based on client requests.
The purpose of caching is to create a copy of the original data into the cache, enabling a faster access for future use of the cached data. When the dataset is huge the use of a cache can improve the performance while accessing the data. The cache memory has a mechanism to create the tag to the copied data with a label so that it will be recognised if the same data is requested.
Web Services Caching through proxy server
The proxy server acts as a medium between clients and servers. The clients send a request to a server but it first passes through the proxy server where the evaluation of the request is done. The web proxies handles different tasks. The major task that the proxy performs is to improve the performance of the request by having web cache installed. If the proxy server is connected to many different clients, one client can access the content at one point. The request is saved in the web cache and will speed up the process the next time the same request is performed for the same content by a different client.
Tile cache services / tile servers
The tile caching server’s architecture is similar to web proxies with a cache on the proxy server between the clients and the WMS-server. When a client performs a request to the WMS-server the map is rendered from the WMS server and split into tiles. The tiles are aligned with a pre-defined zoom level which has been configured in the web cache. Indicating the tiles specific location, each tiles is given a row and a column name and are then saved in that particular zoom level in the cache. Every time the client performs the same request it’s not directed to the WMS server. Instead it is directed to the cache where the tiles requested already exist, and renders the map layer.
Tile Map Service
Tile map service (TMS) is a specification from OSGeo that is based on the WMS-C recommendation with the same fixed grid as the origin in the lower left corner. A TMS differs from a WMS-c in that way that the user is able to make a request of a specific tile with the extent and specify on which zoom level the tile should be fetched.
Web Map Tile Service
The OGC standard Web Map Tile Service (WMTS) is based on the TMS specification dividing the map layers into tiles to improve performance and scalability of the WMTS over the performance of requesting a WMS directly. The WMTS serves spatial referenced data in form of tile images that have predefined its content, extent and resolution. A difference from WMS-C and TMS specification, except it is an OGC standard, is that WMTS has its origin at the top left corner.
I am going to discuss about three cache implementations. These are TileCache, GeoWebCache and MapProxy.
The tile cache application developed by MetaCarta is a middleware between the WMS and the client side. The tiles are rendered with regular map servers such as Geoserver, Mapserver etc. or fetched from a remote WMS and then stored in a disk cache or a memory cache. TileCache written in Python with CGI scripts and use WMS-c or TMS as a tile reference system. The services that tile cache offers are WMS and TMS version 1.0.0. Tilecache does not support a GetFeatureInfo requests or a Getlegend requests. For more information, please refer to http://tilecache.org/.
GeoWebCache (GWC) is developed by OpenGEO and it’s an open source tile map service. GWC can be read by any TMS and WMS client and it complies with various services i.e. WMTS, WMS-c, TMS and KML, Google maps and Microsoft Bing Maps.
Similar to TileCache, GWC also runs in a standalone configuration, reading WMS files served by various WMS compliant servers enabling different data sources. GWC can also be configured as an extension to Geoserver. It automatically read all the layers and perform the tile division automatically. GeoNode an open source SDI platform is an example based on the Geoserver and GWC. GWC supports a feature called caching on demand which uses WMS and renders as a PNG image. GWC is both implemented as a Java application in Java Run time and as a Java Servlet named Apache Tomcat. Unlike tilecache, GWC enables GetFeatureInfo and GetLegend requests. For more information , please refer to geowebcache.org.
MapProxy is an open source web cache proxy and can be run on unix/linux or windows. It is configured by Yet Another Markup Language (YAML) which use the programming concepts from Python, C and Perl and the implementation is based on XML. MapProxy supports OGC WMS standards, OSGEO TMS and OGC KML standards.
MapProxy can recombine tiles in the way that the output format can be read by any WMS client. In this way, MapProxy act as a WMS and therefore enables any GIS client to read the response of the request even though if the client doesn’t not support the tiling specification such as WMS-c or WMTS. Another feature of MapProxy is that when a request does not fit any resolution in the configuration, it can stretch the image in order to fit the requested resolution and then returns the WMS request to the client. MapProxy can also re project several different coordinate systems and combine individual map layers from different WMS sources. MapProxy does not support a GetLegend request but it can be configured to handle a GetFeatureInfo request. For more information, please refer to mapProxy.
Squid is an open source web cache reverse proxy and can be run on linux or windows. It follows the web proxy server architecture implementation. Squid can be placed in between Geoserver in tomcat and Client Application running on the browser.
Squid can be easily configured by enabling mod_proxy in Apache web server. A simple virtual host configuration is required to bypass the requests through Squid. For more information please refer to https://github.com/danfruehauf/squid-geoserver.
These are the various implementations of cache servers to increase the performance of rendering the map layers. Depending upon the requirements , infrastructure and support from the community, one can adopt any of the above mentioned cache servers in their architecture while developing enterprise wide GIS based web applications. GeoWebCache has been picked up well due to its efficiency and default support for Geoserver. MapProxy and TileCache are the niche players with their own pros and cons. Squid is also a generic proxy server which supports the cache for custom layers .
I hope this article gives a brief understanding on cache servers to the developers whose major concern is on speed and performance which are crucial for GIS applications.
Please feel free to contact us if any help is required regarding the implementation of Cache Servers in your next project.