2 GB sind zwar fuer NRW auf der geringen Seiten, sollte aber machbar sein.
Das Verhaeltniss von 20 Relations/s zu 90k Nodes / Sekunde, erscheint mir (leider) in etwa richtig. Die Werte die ich auf meinem Laptop bekomme sind in etwas aehnlich. Wieso genau die Relations so langsam sind weis ich auch nicht, aber es scheint weitestgehen daran zu liegn die Nodes aus der Datenbank zu lesen um die Geometrie der Relation zu basteln. Die groesseren Relations haben 100erte Wege, jeweils mit 100erten von nodes. Eine Relation kann also schone einmal aus ein paar tausend Nodes bestehen, die aus der Datenbank gesucht und gelesen werden muessen.
Eine Optimierung die jedem zu empfelen ist, ist die Einstellungen der Postgresql datenbank zu optimieren. Die default Einstellungen sind noch von lang vergangen Zeiten. http://wiki.openstreetmap.org/wiki/Mapnik/PostGIS#Tuning_the_database gibt einen kurzen ueberblick ueber ein paar der empfohlenen Einstellungen.
angepasst werden. Wobei man natuerlich die Werte an den jeweiligen vorhanden Ram anpassen muss.
Moeglicherweise kann man auch noch
fsync = off
einstellen, wenn man damit leben kann das die Datenbank moeglicherweise unbrauchbar wird wenn sie abstuertzt. Was wenn man die DB einfach mit osm2pgsql neu importieren kann oft nicht so das Problem ist.
Leider kann man die Postgresql Einstellungen nicht wirklich automatisch anpassen, sodas man das nicht in die Installationspackete packen kann.
So, jetzt hab’ ich zwar die world_boundaries runtergeladen und gemaess mapnik-wiki-artikel importiert
und auch ein 0/0/0.png erzeugt (toll ! aber im Browser geht es immer noch nicht.
4 user (root postgres www-data)
und
3 dämonen (apache2 postgresl renderd)
sind einfach zu kompliziert für Otto-Normalos (wie mich
Hoffentlich könnte man das Teil wenigstens dann im JOSM verwenden.
Also ich verstehe deine Probleme nicht ganz. Ich habe das Ding installiert und nichts weiter gemacht als bei den Nutzern für die Datenbank meinen eigenen Usernamen mit einem Leerzeichen getrennt hinten anzufügen. Damit lief es dann. Im gegensatz zu gestern wo ich den Standarduser durch meinen ersetzt habe. Das runterladen und einrichten von Apache und Co macht das Skript alles alleine.
So, im zweiten Versuch klappt’s auch bei mir. Allerdings sehe ich die Tiles
erst nach mehreren Reloads. Kann man den TimeOut irgendwie beeinflussen?
Also wie lange mein Browser auf die Kachel wartet bevor er die 404 Fehlerseite anzeigt?
Das kann man in der mod_tile configuration ( /etc/apach2/sites-available/tileserver_site) einstellen. Der Parameter der das kontrolliert is ModTileMissingRequestTimeout. Per default ist der auf 10 Sekunden eingestellt. Manche tiles benoetigen aber laenger zum rendern
Nachdem ich aus dem svn schnell per dpkg-buildpackage ein Paketchen gebaut habe,
habe ich am Schluß erst gemerkt, dass noch ein “000-default” im “sites-enabled” lag und so
der apache mit dem renderd nicht sprach.
Yup, deswegen hat die neuste Version der packete im postinstall script ein
“a2dissite default” “a2ensite tileserver_site”, da man die default site und die tileserver_site nicht gleichzeitig betreiben kann.
Ich schummle da immer
indem ich den “postgres”-User nehme:
user@host:~$ osm2pgsql -U postgres bremen.osm.pbf
osm2pgsql SVN version 0.80.0 (32bit id space)
Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
HINWEIS: Tabelle »planet_osm_point_tmp« existiert nicht, wird übersprungen
Setting up table: planet_osm_line
HINWEIS: Tabelle »planet_osm_line_tmp« existiert nicht, wird übersprungen
Setting up table: planet_osm_polygon
HINWEIS: Tabelle »planet_osm_polygon_tmp« existiert nicht, wird übersprungen
Setting up table: planet_osm_roads
HINWEIS: Tabelle »planet_osm_roads_tmp« existiert nicht, wird übersprungen
Mid: Ram, scale=100
Reading in file: bremen.osm.pbf
Processing: Node(312k 104.2k/s) Way(57k 6.43k/s) Relation(1580 316.00/s) parse time: 17s
sowie In der /etc/postgresql/8.4/main/pg_hba.conf eingetragen habe (nach mapnik-wiki-artikel):
# Database administrative login by UNIX sockets
#local all postgres ident
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
#local all all ident
local all all trust
# IPv4 local connections:
#host all all 127.0.0.1/32 md5
host all all 127.0.0.1/32 trust
# IPv6 local connections:
#host all all ::1/128 md5
host all all ::1/128 trust
das importieren der Daten hat also schon mal geklappt?
Hast Du auch den renderd danch restartet?
Danach wuerd’ ich den
den renderd im Vordergrund laufen lassen per
sudo /usr/bin/renderd -f
um zu sehen wie er startet.
Desweiteren mal die Logfiles von Apache
sudo tail -f /var/log/apache2/error.log
umd das der Datenbank
sudo tail -f /var/log/postgresql/postgresql-8.4-main.log
beobachten waehrend Du einen request mit dem Browser erzeugst.
Jetzt nochmal langsam. Womit hast du genau Probleme. Hast du die Daten in die Datenbank eingelesen? Falls du das nicht geschafft hast wäre es kein Wunder wenn du keine Kacheln siehst.
Hast du die automatische Konfiguration des Tools benutzt? Dort habe ich alle Standardwerte übernommen und nur bei dem Datenbanknutzer meinen Benutzernamen zu www-data hinzugefügt. Sonst waren keine weiteren eingriffe nötig.
Ich hoffe du bist mir nicht böse, wenn ich deine Tipps mit Erklärungen zwischen die einzelnen Befehle geschrieben habe.
Kann jemand ein paar Screenshoots hochladen um das ganze etwas anschaulicher zu machen?
Macht es Sinn einen eigenen Bereich für die GUI Installation anzulegen?
Wollen wir einen Bereich ergänzen in dem die Konfiguration des OSMviewers für diesen Server erklärt wird?
Möglicherweise hat mein osm2pgsql beim Einsatz von pbf’s ein Speicherloch (nach Sekunden unbrauchbar)
oder es braucht wirklich soviel Speicher.
Habe daher per
osmconvert berlin.osm.pbf > berlin.osm
umgemodelt, dauerte bei mir 16 Sekunden.
Und dann per
$ osm2pgsql -U postgres berlin.osm
eingelesen. Ist zwar nicht schnell
Processing: Node(1339k 29.8k/s) Way(245k 4.30k/s) Relation(4467 319.07/s) parse time: 116s
dafür schafft es mein 1 GB netbook (mit verschlüsselter Platte) in 5 min:
Osm2pgsql took 299s overall
Ge-swap-t wird zwar immer noch, aber nur leicht und auch “mittelfranken.osm” (50% größer als berlin.osm) geht noch.
Bei bayern.osm wird’s wohl die Grätsche machen
Ciao,
Frank
EDIT:
So, jetzt hab’ ich mal eine neuere Library (protobuf-c aus dem svn) verwendet:
$ LD_LIBRARY_PATH=/usr/local/lib osm2pgsql -U postgres --slim -C 800 berlin.osm
Processing: Node(1339k 15.8k/s) Way(245k 4.02k/s) Relation(4467 78.37/s) parse time: 203s
Osm2pgsql took 550s overall
Es wird während der Installation gefragt ob man das Paket konfigurieren möchte. Danach kommt die Frage nach Datenbank, User und Küstenlinien. Möglicherweise auch in anderer Reihenfolge. Ob das Paket bei der Deinstallation die Konfiguration irgendwo speichert weiß ich nicht. Aber Kai hat schon erkannt, dass die Installation nicht sehr fehlertollerant ist und arbeitet vielleicht schon an weiteren Skripten.
Ich selbst habe Linux immer neu installiert bzw. die virtuelle Maschine kopiert und so immer ein frisches Linux gehabt.
aber im Browser geht es immer noch nicht.
