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?
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 https://github.com/SomeoneElseOSM/mod_tile ) 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.
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.
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.
@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 osm.org 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 osm.org before 18.04.1 comes out
Exactly. 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.
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.
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.
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)