Compiling mod_tile on Ubuntu 16.04: up-to-date guide or config script?

I had mod_tile compiling on Ubuntu Server 16.04 about a year ago but I’m trying again now on a fresh install and can’t seem to do it.

I looked at the tile Chef recipe but I can’t see anything triggering a compilation there.

There are guides out there but they suggest using user SomeoneElse’s mod_tile fork because “it has been modified to work for Ubuntu 16.04” but that confuses me because apparently Yevaud is running 16.04. So does Yevaud use the openstreetmap repo or the SomeoneElse repo?

There’s very little actual code difference now between (which is where my “switch2osm” version has moved) and the upstream version. Mostly it’s the config files, typos and some external changes (which are bundled up into ).

You could follow with , but you’d need to modify the config files.

Obviously the repositories that mod_tile depends on change all the time, and it’s possible that something’s broken, but I did do a clean install of mod_tile (actually of all of the branches at ) only last week, so I don’t expect there’s a current problem. One thing that I did notice was that I needed to do a “make clean” before a “make” to get it to behave, but that’s fairly normal I think.

Ahh, straight from the source. Thanks for all the detail; I will try make clean and if that fails I will try again following switch2osm by the letter.

Just to confirm for anyone experiencing the same problem: I did indeed get it working on 16.04 and didn’t have to use SomeoneElse’s repo. I just followed the Switch2OSM guide, installing the packages listed even if I didn’t think they were required.

At least one problem on the failing build was that I had used the UbuntuGIS PPA in an attempt to get the latest version of PostGIS and that had led to a dependency conflict.

@Peter_Devoy Actually, you’re not the first person to hit problems with the UbunutGIS PPA. I’ve added caveats to and .

I guess the problem might be with newest Debian/Ubuntu Mapnik package. It depends on mapbox-variant, while mod_tile doesn’t currently. More details here:

I hope that talaj (Mapnik developer) will be able to produce proper mod_tile package for Debian, so a lot of the people could use it without compiling.

The packages are here, but they are untested:

Could you test how do they work on Xenial? If that will prove to be working, we could make the process simpler and update switch2osm documentation.

@kocio I’m not sure that I see the benefit to someone starting from scratch of using a PPA to use the latest Mapnik version on Ubuntu 16.04. If they really want Mapnik 3.0.19 wouldn’t they just use Ubuntu 18.04 from the outset? If they’re constrained to use 16.04 I’d imagine that they’d be constrained to use other non-“bleeding edge” packages too, so would probably just mostly use the same versions that uses.

Having said that I can see why you’re keen to get someone to test it, since you’d like to see Mapnik 3.0.19 on before 18.04.1 comes out :slight_smile:

Exactly. :slight_smile: I wouldn’t bother at all if this was smooth process of releasing and deploying software, but this bug has shown that some action is needed. I can imagine more people who don’t like living on the bleeding edge.

Also bear in mind that while 3.0.9 doesn’t sound too different from 3.0.19, it’s only because Mapnik doesn’t use semver scheme. 3.1.x is gonna be another big change, but 3.0.19 added new algorithm for placing labels (grid) and I hope to use this functionality soon to tune area labels rendering.

There are more packages backported now in talaj’s PPA:

python-mapnik has been added to the stack.

Anybody willing to test it?

If anyone does, I’d also suggest looking at performance compared with similar non-PPA packages such as those in . A server here set up as per seems to be somewhat slower than I’d expect it to be compared to 16.04.

I’m currently trying to remove VM configuration differences between the two machines to rule out problems in that area, and obviously almost every software package is updated between 16.04 and 18.04, but a comparison based on just this PPA should reduce differences even more.

Do you have any automatic test/script to measure general performance (I’m aware that this is not simple, especially under real life load)?

Not as such, but the things that I’ve noticed taking longer are:


Which does a full database reload after a styling change. Obviously that’s nothing at all to do with rendering…


Which rerenders all tiles in a given area up to zoom 12.

(2) obviously is to do with rendering but the fact that (1) takes longer as well means that it’s not just to do with rendering. As I said previously I need to align some “virtual hardware” differences too.

Backported packages from are working good on xenial:

There’s a tool called render_speedtest from renderd package, maybe you could use it as a basic benchmark. Here is example output snippet from my virtual xenial using Liechtenstein data:

Zoom(9) Now rendering 4 tiles
Rendered 4 tiles in 1.34 seconds (2.98 tiles/s)

Zoom(10) Now rendering 12 tiles
Rendered 12 tiles in 5.78 seconds (2.08 tiles/s)

Zoom(11) Now rendering 36 tiles
Rendered 36 tiles in 11.45 seconds (3.14 tiles/s)

Zoom(12) Now rendering 120 tiles
Rendered 120 tiles in 37.66 seconds (3.19 tiles/s)

Zoom(13) Now rendering 456 tiles
Rendered 456 tiles in 163.32 seconds (2.79 tiles/s)