-
Notifications
You must be signed in to change notification settings - Fork 500
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
Help! Not able to render detailed tiles #72
Comments
It should be
50 GB will not be enough space for the full planet import. Importing it on a hard disk drive (HDD) instead of an solid state disk (SSD) will take weeks instead of hours.
Meaning the import process was killed / aborted. (Probably a memory problem, see issue 31) |
Thank you very much Robin for taking time to reply. I will try with SSD. |
Same issue here... only a basic contour map with no details. This is the last log from the
and the log from the or
|
I have the same issue. CREATE INDEX |
Same issue.
|
Is there any update on this issue? I'm facing same issue |
What may be happening is that the tiles just take a very long time to render rather than never rendering at all, especially if you import the whole planet. |
I have the same issue. Anyone solved the problem? |
Checkout this issue related to openstreetmap-carto v4.23: gravitystorm/openstreetmap-carto#3942 After adopting the query in mapnik.xml accordingly I finally could render detailed tiles very quicky as well. |
@ruhepuls can you share what exactly should be set in mapnik.xml? I can see only gray tiles. Thanks! |
For a quick test search in mapnik.xml for
and replace by
Afterwards restart the renderd daemon or container. |
@ruhepuls Thanks a lot! I will look into it! |
I have same/similar issue:
Run:
And my
|
@tajchert Looks like your import process was killed by the oom killer. What EC2 instance type are you running on (how much memory does it have?) and is there anything else running on that instance? I'm no expert in tuning postgresql or the osm import process. But here is what I think to be right (but might be wrong). You set With You don't increase I assume the database workers to be separated over multiple threads/processes of up to 256 MB each, meaning the the import itself with 4 GB is the process consuming the most memory and gets killed. So, in sum your settings would require a system with at least 12 GB of memory as a minimum for the import (running it with automatic updates would require more, because the amount of possible threads/connections doubles by the update process). Because you increase In my company we decided against running our OSM server in AWS because it would cost too much, but settled on classical server hosting for it (unlike most of our other productive systems that run in AWS). |
Thanks. |
Hi,
First, sorry for the long write up.
Steps that i followed
2.docker run -v \planet-190930.osm.pb:/data.osm.pbf -v openstreetmap-data:/var/lib/postgresql/10/main overv/openstreetmap-tile-server import
3.docker run -v \planet-190930.osm.pbf:/data.osm.pbf -v openstreetmap-data:/var/lib/postgresql/10/main overv/openstreetmap-tile-server import
I am able to start the instance and access the tiles. But I see only country outlines. If I zoom in i do not see any detailed tiles rendered. Just the blank. Could you please tell me did I miss something or should I have to perform any other steps?
My Env:
Windows 10 running Docker Desktop, Run Docker CLI and execute above mentioned steps.
I7, 4 cores, 16GB RAM and 500 GB harddisk (only 50 GB free space)
Here is the tail output of import(step 2). I see "155 killed".
Reading in file: /data.osm.pbf
Using PBF parser.
Processing: Node(52910k 348.1k/s) Way(0k 0.00k/s) Relation(0 0.00/s)/run.sh: line 67: 155 Killed sudo -u renderer osm2pgsql -d gis --create --slim -G --hstore --tag-transform-script /home/renderer/src/openstreetmap-carto/openstreetmap-carto.lua --number-processes ${THREADS:-4} ${OSM2PGSQL_EXTRA_ARGS} -S /home/renderer/src/openstreetmap-carto/openstreetmap-carto.style /data.osm.pbf
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
...done.
Thanks
Prakash
The text was updated successfully, but these errors were encountered: