|
I have been building a tile server from scratch based on the instructions here: https://switch2osm.org/manually-building-a-tile-server-18-04-lts/ Renderd runs, and the rendering process renders roads, streets names, etc., but it looks like all the polygons are missing (no forests, lakes, etc):
Renderd is not reporting any errors, and the osm2pgsql process likewise ran without issue. I used the following command for the import, with the standard OSM stylesheet: I'm not quite sure where I should start looking, since I'm not seeing any error messages. I may have made a stupid mistake somewhere, or maybe I got unlucky and grabbed a 'bad' version of one of the repositories? I intend to make some tests soon, with a smaller import before I restart the entire import again (if that is indeed necessary). But if anyone has some idea of what may have gone wrong, I would appreciate the help! (Edit) What I am looking for an answer to, as someone who is not an expert on the rendering process, which is more likely in this case? Is the import itself broken, or is something the rendering process (renderd) broken, or set up incorrectly
showing 5 of 6
show 1 more comments
|
|
So, I ended up rerunning the entire import twice with a stable release of openstreetmap-carto. After the first rerun, tiles took far too long to render. I discovered that osm2pgsql seemed to have missed generating some of the indices. And generating them manually after the fact did not seem to fix rendering performance. On the 2nd rerun, I made absolutely sure that there would be space for everything, including the indices, on the disk. And now everything works! So I think the reason for the polygons not rendering could be either
In any case, this problem has been resolved now, and the rendering times are now reasonable. |
Where did you get the data from? I would start with exact dataset from the tutorial to test it on something smaller than the whole world.
A hint - you don't have to drop the whole planet database in order to test another set of data, it's enough to temporary rename the database. I use a simple gis-swap.sh script which looks like this (I could use multiple names like planet/standard/small etc and name them as gis, but most of the time simple swapping two databases is enough for me):
It's simply the Planet PBF file from https://planet.openstreetmap.org And yes, I'm going to test with a smaller dataset when I can find the time for it. But I think what I'm looking for here, more specifically, is what this behaviour might indicate to someone experienced: Is this more likely to be an issue with the import itself, or the rendering process? I will add this to the question, for clarity.
And that's definitely helpful! Thanks! It's such a simple thing, but I hadn't actually considered that you can just rename the database to test other imports.
What was the outcome? Does it look the same with some other data?
I tried importing Iceland, and now it looks like it should! But I ended up doing this on a more recent openstreetmap-carto pull. I realized too late that I should have used the same conditions for the test import, because now I don't remember the exact commit I used earlier for the full import. But as it turned out, I wasn't using an official release, just the latest commit. So maybe the lesson is that I really should just use the releases when doing this. I think I'm going to start another full import later today, then we shall have to see how that works out in a couple of days.