-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"render_expired" doesn't use TILEDIR from map name in /etc/renderd.conf when deciding if tiles exist already #286
Comments
I removed "and you’re not worried about automatically marking updated tiles as “dirty” to force re-rendering" from the "osmosis" instructions. At the time I wrote that I hadn't got osm2pgsql-replication to handle dirty tiles at all because I hadn't yet identified the problem as openstreetmap/mod_tile#286 . With the instructions in place elsewhere in the switch2osm documentation there's no need for this caveat.
I removed "and you’re not worried about automatically marking updated tiles as “dirty” to force re-rendering" from the "osmosis" instructions. At the time I wrote that I hadn't got osm2pgsql-replication to handle dirty tiles at all because I hadn't yet identified the problem as openstreetmap/mod_tile#286 . With the instructions in place elsewhere in the switch2osm documentation there's no need for this caveat.
@SomeoneElseOSM It looks like you need to specify the tile directory as part of the command with mod_tile/docs/man/render_expired.1 Lines 53 to 54 in f521540
|
The point I was trying to make above was that "I've already told it where the tiles are, in '/etc/renderd.conf'; I shouldn't need to tell it again". However, if you're happy that "render_expired" is well enough documented then I guess that this can be closed; I've already changed the switch2osm documentation so that new users following that won't hit this problem. |
Aha, I apologize for not understanding completely, I see your point, yes that is indeed true. Perhaps the I.E.: Lines 898 to 1032 in f521540
|
@SomeoneElseOSM, here's a first attempt at implementing this functionality: |
Thanks, but I don't think I've got an environment to test that in right now. |
I removed "and you’re not worried about automatically marking updated tiles as “dirty” to force re-rendering" from the "osmosis" instructions. At the time I wrote that I hadn't got osm2pgsql-replication to handle dirty tiles at all because I hadn't yet identified the problem as openstreetmap/mod_tile#286 . With the instructions in place elsewhere in the switch2osm documentation there's no need for this caveat.
Hello @SomeoneElseOSM, I have some good news for you. This would make the command you need to run more like this: sudo -u _renderd render_expired --config /etc/renderd.conf --map=s2o --min-zoom=1 < /path/to/dirty_tiles.txt Of course, if you still don't have an environment to build and test it out, hopefully it resolves your issue when the next release is made, otherwise, let me know if it is of assistance to you! Thanks! Lines 259 to 298 in dd90553
|
One thing I have been wondering about is how to test all this before it gets packaged into the new Ubuntu / Debian releases. I expect I'll want to create a new page at https://switch2osm.org/serving-tiles/ for Ubuntu 24.04 LTS when that comes out; will changes such as this be in it, or has what will be in that already been frozen? |
Well, the latest "release" does not include the aforementioned code and also has not been packaged, however if you would like to test these changes, I can configure the CI pipeline to push up |
Thanks - https://packages.ubuntu.com/noble/renderd suggests that Ubuntu 24.04 will contain 0.6.1-2 which is the same as https://packages.debian.org/bookworm/renderd (which I'm already running live), so right now I don't need to test any post-packaging changes before April (which was what I was worried about). With regard to testing the above changes, I'll do that next time I install a server, since I build from source (in order to increase max zoom levels). |
has this been resolved in anyway ? This seems to be the same issue with render_list for instance in /var/lib/mod_tile/default i have my pre-compiled tiles but if i run render_list -m default -a -z 0 -Z 1 --num-threads=1 it recreates the tiles every time, even though they already exists and are not marked expired in any way that i know of ? if that is normal for render-list -a .. then a feature request for -M missing only might be appropriate |
@mxdog Just checking - have you seen #286 (comment) ? I think that that answers your question before you asked it? |
Yes, it shouldn't be re-rendering, unless you're using Lines 382 to 389 in 2a4532f
It's likely that it's being re-rendered because the default value for The comment mentioned by @SomeoneElseOSM also refers to some recent updates allowing you to override the defaults for several options with the corresponding values from the specified |
Thanks for the answers adding --tile-dir /var/lib/mod_tile to the command line fixed my current use case , It seems to be a self inflicted gotcha because the tiles are being rendered to /var/lib/mod_tile ( and always have ), I have to assume from the settings in /etc/renderd.conf (Debian) where I specifically use that path , so the case where it can not find the files seems like a bug to me IF it is using that config file to write to that location it seems like it should use that config file to read from that location and not the default path . /var/cache/renderd/tiles is empty and has never had any tiles in it . |
That's good to hear @mxdog! Yes, that's basically what I was intending to resolve with the updated code mentioned in the comment (#286 (comment)). The default directory is actually printed in the $ render_expired --help
Usage: render_expired [OPTION] ...
...
-t, --tile-dir=TILE_DIR tile cache directory (default is '/var/cache/renderd/tiles')
... But perhaps some additional notes are needed in the Let me know if you have any ideas. Thanks! |
I am going to remove the path lines from /etc/renderd.conf and see where tiles get written too . here is my config file and what I have been using since I started trying to set up this server right or wrong, notice I commented out my path tile_dir=/var/lib/mod_tile [renderd] [mapnik] [default] after restarting renderd the tiles are getting written to the default /var/cache/renderd/tiles/default, which proves to me that the WRITE routines are using the config file path from /etc/renderd.conf BUT the READ routines are still using the DEFAULT hard-coded path , hence the reason I have been always recreating tiles . I can live with just adding the path to the command line ... again I reiterate if it will write to one place it should be reading from the same place . in my experience of course, this all depends on that config file actually being correct, with the many guides I have looked at that, this config may be wrong and that is the problem and am just wasting everyone's time. |
Yes, that is correct, the mod_tile/includes/render_config.h Line 31 in 743cf65
The issue you are running into is that Furthermore, if you are using
|
An example:
With /etc/renderd.conf containing
[s2o]
URI=/hot/
TILEDIR=/var/lib/mod_tile
XML=/path/to/mapnik.xml
HOST=localhost
TILESIZE=256
MAXZOOM=20
and a "dirty_files.txt" containing:
18/131010/87170
This command
sudo -u _renderd render_expired --map=s2o --min-zoom=1 --max-zoom=20 -s /var/run/renderd/renderd.sock < /path/to/dirty_tiles.txt
returns
Total for all tiles rendered
Meta tiles rendered: Rendered 0 tiles in 0.00 seconds (0.00 tiles/s)
Total tiles rendered: Rendered 0 tiles in 0.00 seconds (0.00 tiles/s)
Total tiles in input: 1
Total tiles expanded from input: 18
Total meta tiles deleted: 0
Total meta tiles touched: 0
Total tiles ignored (not on disk): 18
even when the corresponding metatile /var/lib/mod_tile/s2o/18/17/245/244/200/0.meta does exist.
However, when I comment out "TILEDIR", delete all cached tiles and generate the new tile for http:///hot/18/131010/87170.png (which creates a metatile below /var/cache - the default location), and rerun
sudo -u _renderd render_expired --map=s2o --min-zoom=1 --max-zoom=20 -s /var/run/renderd/renderd.sock < /path/to/dirty_tiles.txt
I get
Rendering client
Starting 1 rendering threads
render: file:///var/cache/renderd/tiles/s2o/18/17/245/244/200/0.meta
Waiting for rendering threads to finish
Total for all tiles rendered
Meta tiles rendered: Rendered 1 tiles in 12.67 seconds (0.08 tiles/s)
Total tiles rendered: Rendered 64 tiles in 12.67 seconds (5.05 tiles/s)
Total tiles in input: 1
Total tiles expanded from input: 18
Total meta tiles deleted: 0
Total meta tiles touched: 0
Total tiles ignored (not on disk): 17
It looks like whatever's deciding whether a tile already exists or not isn't looking at the location indicated by the map section in /etc/renderd.conf but always below /var/cache
This is with Ubuntu 22.04 set up as per the version of https://switch2osm.org/serving-tiles/manually-building-a-tile-server-ubuntu-22-04-lts/ that exists now** - the render_expired is from the mod_tile diistributed with 22.04.
** As I write this it has "TILEDIR=/var/lib/mod_tile" in the example there, which I suspect I should remove as it doesn't matter for that guide where tiles are created. Historically they were below /var/lb/mod_tile, but there's no reason they have to be there.
The text was updated successfully, but these errors were encountered: