Package Details: mod_tile-git 0.4.r278.ge25bfdb-1

Git Clone URL: https://aur.archlinux.org/mod_tile-git.git (read-only)
Package Base: mod_tile-git
Description: Mod tile is an apache module to serve raster Mapnik tiles
Upstream URL: http://wiki.openstreetmap.org/wiki/Mod_tile
Licenses: GPL2
Submitter: Calimero
Maintainer: Calimero
Last Packager: Calimero
Votes: 2
Popularity: 0.000000
First Submitted: 2013-12-21 09:27
Last Updated: 2018-02-04 20:53

Latest Comments

Calimero commented on 2018-06-01 08:38

newmentos, mapnik is listed as a dependency and provides that file, there's something wrong on your end.

newmentos commented on 2018-06-01 07:08

/usr/include/mapnik/util/variant.hpp:27:10: fatal error: mapbox/variant.hpp: No such file or directory #include <mapbox variant.hpp=""> ^~~~~~~~~~~~~~~~~~~~</mapbox>

jerry73204 commented on 2018-02-10 12:57

It's great to have unit files in this package. Well, I still consider /usr/share/fonts a better alternative to /usr/share/fonts/TTF. Several official packages, like noto-fonts, have truetype fonts installed under /usr/share/fonts.

Calimero commented on 2018-02-04 20:50

Thank you.

It has come to my attention that /usr/share/fonts/TTF seems to be the place where truetype fonts are placed in Arch, so I modified the package's renderd.conf to match this for ease of use, rather than /usr/share/fonts. I doubt anyone would keep that configuration verbatim, given it is merely the test settings of J. Burgess; but it is obviously sensible to set the font directory in this example as Arch users would want it.

I have included two Systemd unit files based on your suggestions.

jerry73204 commented on 2018-02-04 15:45

Could you please alter this line font_dir=/usr/share/fonts/truetype to font_dir=/usr/share/fonts in /etc/renderd.conf?

jerry73204 commented on 2018-02-04 15:43

Oops, the previous post is messed up. I re-post one here.

This is an example unit file placed at /usr/lib/systemd/system/renderd.service. The renderd daemon can be started by systemctl start renderd.service, and run journelctl -u renderd.service to check out the logs.

=========== [Unit] Description=renderd Documentation=man:renderd(1)

[Service] Type=forking ExecStart=/usr/bin/renderd

[Install] WantedBy=multi-user.target ===========

This unit file does not bother with postgresql service since PostGIS data source is not necessary. (I provide GeoJSON files in my case.) If the feature is needed, put the snippet under [Unit] section to make renderd restart when postgressql restarts.

=========== After=postgresql.service Requires=postgresql.service PartOf=postgresql.service ===========

jerry73204 commented on 2018-02-04 15:40

This is an example unit file placed at /usr/lib/systemd/system/renderd.service. The renderd daemon can be started by systemctl start renderd.service, and run journelctl -u renderd.service to check out the logs.

[Unit] Description=renderd Documentation=man:renderd(1)

[Service] Type=forking ExecStart=/usr/bin/renderd

[Install] WantedBy=multi-user.target

<hr>
This unit file does not bother with postgresql service since PostGIS data source is not necessary. (I provide GeoJSON files in my case.) If the feature is needed, put the snippet under [Unit] section to make renderd restart when postgressql restarts.

After=postgresql.service Requires=postgresql.service PartOf=postgresql.service

<hr>

Calimero commented on 2018-01-30 09:41

I'm not using systemd, but you're welcome to offer one that works for you. Here are the challenges: You'll need to assume the postgresql cluster to start after; renderd can't properly reestablish connections to the postgresql instance if it restarts. That needs fixing upstream. As a result, renderd also needs to restart whenever postgresql does, otherwise reliability will be bork-tier. But again, that really needs fixing upstream, because it breaks any rendering scripts, that will end immediately having failed all of their rendering commands.

jerry73204 commented on 2018-01-29 04:35

Can you create a systemd service file for renderd?

Calimero commented on 2014-05-25 18:11

No specific reason I can remember; except I hadn't tested it on 32bit.

All comments