Offline viewing (2) - rendering and viewing whole maps

A different way – pre-render a whole map

The method described here was rather complex – render tiles, set up a tile server, adapt a viewer. It had the advantage that it is close to the most common OpenStreetmap setup, a map web-app. But it is also possible to render a whole map image (for each zoom level) that can then be viewed with a browser or image viewer.

The advantages of this approach are:

• less complexity because fewer different programs are involved
• every pixel is rendered only once, unlike when rendering tiles, where an overlap at the edge has to be included to avoid discontinuities
• resulting map image in PNG format can be further processed by standard software

The disadvantages are:

• only one rendering process while multiple tiles could be rendered in parallel
• only one zoom level can be rendered at a time
• few image viewers / processing programs can handle really large map images

Up to "Configuring Mapnik", the same has to be done as for the tile generation / tile server approach, only apache, mod_tile and renderd need not be installed and run. But instead of rendering tiles, we now render a larger map image. This requires a custom program, the price we have to pay for deviating more from the usual workflow. This program is easiest to write in Python 2, for which Mapnik bindings are available. (There are no bindings yet for Python 3, the current version of the language, so make sure to run python2 and associated programs if you have an up-to-date Linux distribution.) Of couse the PostgreSQL service has to be running, but renderd is not needed.

I wrote an example program that renders a rectangular map region given by two pairs of geographical latitude and longitude or an OpenStreetmap URL you can copy from your browser. (In the latter case it guesses the size of your browser window at 1600x1200, because it has no way to know that.) The other optional parameters are the output file and width / height. Mapnik infers the zoom level based on the output size, so you may have to experiment if you want a specific zoom level. Run it without arguments to read a usage message. There is a Python version and a C++ version &emdash; the latter saves you buiding the python bindings for Mapnik 3.x where they are not included in the main project any more.

Viewing a map image

Or: crash-testing image viewers

Using a standard image viewer or browser works up to a point. These programs assume that the image will fit into memory uncompressed and may crash if that is not true. This places a hard limit on system memory. But it also takes significant CPU power to decompress a large image. I have compared two viewers and two browsers with map images of three different sizes. display and gm display are the image viewers of ImageMagick and GraphicsMagick (its fork focused on code quality). Feh is a modern light-weight image viewer. links is a lightweight browser for which I have personal patches here; xombrero is a browser using the webkit engine. The results are:

[1] Additional time to display thumbnail for navigation in parentheses

[2] X server crash after scrolling beyond 2³¹ pixel offset from top.

[3] See here for git branch with personal patches; see below for explanation.

(Test system details: Opteron 3380 8x2.6 GHz, 16 GB RAM, Xorg 1.17.2, NVidia driver 304.128. Compressed images were read from SSD, and results of first runs were discarded to exclude disk read time.)

Surprisingly (to me at least), the browsers are more efficient than the image viewers. The main exception is feh, which is fastest for images under 1 Gigapixel but whose libraries throw errors for larger ones. gm display is at least fast at displaying JPEG and uses less memory compared to PNG and other competitors. The browsers refuse to display the largest image. In the case of links, I have written a patch that will be available here. This involved not only removing restrictions in the browser engine, but also finding a workaround for crashes caused by the X server or NVidia driver, one of which can handle only 32-bit offsets. The same effect caused gm display to crash after scrolling down beyond the middle of the image.

So, in summary, viewing a rendered map as a single huge image works fairly well so long as it is below a Gigapixel, and the best viewer in that case is clearly feh. For larger images, gm display offers a startup speed advantage for JPEG if you have the RAM, otherwise the patched links is the ticket. Conversion to JPEG is recommended, both to save disk space and for higher speed of gm display.

Creating tiles from a large map

If you have rendered an overly large map image, you can still easily divide it up with GrahicsMagick:

gm convert <image> -crop <width>x<height> +adjoin tile%04d.jpg

<width>x<height> are the width and height of each tile. (If they do not divide the size of the original image, there will be smaller tiles at the right and bottom edge.) The +adjoin option causes multiple output images to be created, with the names generated according to the printf format string given as the output file name.

Licensed under the Creative Commons Attribution-Share Alike 4.0 Germany License

TOS / Impressum