Common pitfalls when printing maps on the web

In this article we describe a number of pitfalls that are common to printing maps from web based applications: insufficient resolution, printing of large formats, cut or redundant labels, issues with scales, including non-geographical information in reports;

A frequent use case

… common with web mapping applications is the printing of the geographical information shown in the map canvas. The task sounds simple, however most of the time taking a screenshot does not provide the desired result. In this article we will try to point out why generating professional prints of maps within a web based solution is more complicated and discuss some of the most common issues related to web map printing.

Within a web GIS typically several layers are shown at a time, this could be a background WMS or displaying an orthophoto overlayed by a WFS containing vector information on a network (e.g. roads, broadband infrastructure, tree cadastre etc.). While a screenshot taken directly within the browser would show all the relevant information on the map, the first issue, resolution, comes to mind. In order to generate a high resolution printable image of the map canvas, the layers need to be rendered along with additional information such as bounding box and projections by a separate processor. This processor would be considered the engine of a printing service, which itself can run directly in the browser (e.g. Inkmap) or as a backend service (e.g. MapFish Print). The printing service then has to process the different data sources where each layer needs to be loaded and rendered separately.

The layers are requested from the corresponding server(s) with WMS/WFS considered as standard formats. When trying to print large maps (i.e. A0 format) in a decent resolution, the requested image gets so big that WMS servers refuse to serve and the image size can no longer be handled via memory. As a solution, we can query WMS-Requests in a tiled manner.

When composing the map layer out of tiles, a common issue occurs when labels are not completely contained by one tile or rendered several times (for each tile). A potential solution in this case is to query larger tiles and/or set a buffer around the tile, query that larger image and use only the unbuffered part for the map.

With growing demand for better performance and greater efficiency many servers are now providing not only WMS but delivering pre-rendered tiles (WMTS), which enables faster panning and zooming inside a WebGIS, and reduces the impact on memory usage.

Another important requirement

… is that all layers shown in the print are true to scale (e.g. 1:10000) and are correctly displayed under the defined common coordinate system. If a layer can not be requested in the required coordinate system (as specified in the WMS, WFS or WMTS), the printing service needs to handle the coordinate transformation.

Besides the common OGC map services, other formats that should be supported by a comprehensive printing solution are: GeoJSON, GeoTIFF, GML, grid, image or OpenStreetMap (OSM) layers. In addition to the geographical content of the map canvas essential map elements such as the north arrow, the scale bar and the legend need to be displayed as well. As for the legend, additional tables and information might have to be shown, especially when the objective is to generate a print with extensive additional information or even a multi-page report. For such cases the application needs to allow for detailed layouting and for the use of templates or offer a proper tool for configuration. Regarding the content of the report and corresponding tables, the tool needs to be able to bundle the information of various attributes from different layers and display everything correctly in the table(s) of the report. In some cases spatial restrictions or constraints need to be considered where information from one layer (e.g. households) is grouped based on geographical units defined in another layer (e.g. municipalities).

The many challenges of printing maps from web applications showcase that in order to meet the current demands linked to resolution, complexity of reports or supported data formats, solutions must be constantly evolving as well as offering a very high degree of flexibility. We believe that these challenges can be best met with Open-Source built technologies and the joint effort of the community.