WMTS + ECW = The best of 2 worlds

WMTS + ECW = The best of 2 worlds

Limitations of WMS

Everybody who knows its way around in the GIS-world, has dealt with WMS at some point. The Open Geospatial Consortium, or OGC in short, stood at the cradle of this acronym at the end of the last century. Meanwhile, this WMS (Web Map Service) grew up, and became an adult and worldwide standard. Everywhere in the world services are available that allow you to retrieve images from publically available geographic data. These images are generated and rendered on the fly. Close to all tools doing anything with geodata, allow their users to send a WMS request to a server. The standardised protocol is so well adapted, that most dialects have disappeared. By putting a part of our globe, using coordinates and a projection system, in a screen (based on the height and width of that screen) in a standardized fashion, WMS offers the most liberal way to retrieve geodata.

But this freedom has a downside. By allowing for random requests both in image size and in location, the performance of a WMS server can be manipulated easily. It would not be the first time that some print service asks for a huge image, so big that the WMS server simply comes to a grinding halt. Obviously mechanisms have been implemented server-side, to ignore these huge requests, and some client applications also constrain themselves by not allowing for requests greater than 256 × 256 pixels.

WMTS – how does it work?agiv

This concept was also used in a new standard, called WMTS. This standard was the answer to continuous initiatives in the world of tile serving. The most important property of these servers, is that the data is chopped up into standard dimensions at different levels. It generates some sort of a pyramid shape, in which there is a significant but limited number of possible requests. This type of request is also called an xyz, whereby x and y define the row and column of the tile in the pyramid and z defines the required level. Within a certain coordinate system is every part of the world, or part of the world within a certain projection at least, unambiguously and well defined.

This opens up doors and perspectives: a predefined unambiguous set of requests allows us to predefine the requests in advance. This is what happens in so-called cache servers. Certain tiles are prerendered, so that requests can be served directly from the cache and not from the source data. There is a serious performance gain because of that! The cache-strategy can be configured reactively (only store in the cache what has already been asked for) or proactively (generate the full cache in advance). Mass market mapservices like Google Maps or Bing Maps use data farms that allow for the storage of all these tiles. One has to count with the fact that every extra level implies an exponential number of extra tiles: level 0 has 1 tile, level 1 has 4 tiles, level 2 has 16 tiles, level 3 has 64 tiles and so on. This can go up to about 20 levels. And it is easy to see that this can introduce another significant challenge: the cache needed to make such a WMTS service as performant as possible, is gigantic. And data storage is not for free…


And this is exactly what the WMTS server in APOLLO Essentials avoids. In stead of expanding the original file by generating innumerous amounts of tiles, the file is actually reduced using the ECW-compression. The tiles will be generated at request, by the server. But the fact that the requests remain small (256×256 pixels) and the fact that the decoding mechanism of ECW to jpg or png is extremely performant, Make this server as fast as a cache server. Or how one can maintain speed, without investing in huge amounts of very expensive storage hardware.

And so, that’s the best of both worlds.

Check out this winning combination on http://apollo.imagem.nl/AGIV_WMTS.htm