ich habe den Befehl ausgeführt und es wird diesmal auch etwas angelegt in der DB … allerdings nur die Tabellen “geometry_columns” und “spatial_ref_sys”.
Der Rest fehlt immernoch. Jetzt sind es aber auch, laut der ausgabe von der konsole, mehr tabellen die fehlen.
user@osm:~$ LD_LIBRARY_PATH=/usr/local/lib osm2pgsql --slim -C 1500 hamburg.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« existiert nicht, wird übersprungen
HINWEIS: Tabelle »planet_osm_point_tmp« existiert nicht, wird übersprungen
Setting up table: planet_osm_line
HINWEIS: Tabelle »planet_osm_line« existiert nicht, wird übersprungen
HINWEIS: Tabelle »planet_osm_line_tmp« existiert nicht, wird übersprungen
Setting up table: planet_osm_polygon
HINWEIS: Tabelle »planet_osm_polygon« existiert nicht, wird übersprungen
HINWEIS: Tabelle »planet_osm_polygon_tmp« existiert nicht, wird übersprungen
Setting up table: planet_osm_roads
HINWEIS: Tabelle »planet_osm_roads« existiert nicht, wird übersprungen
HINWEIS: Tabelle »planet_osm_roads_tmp« existiert nicht, wird übersprungen
Allocating node cache in one big chunk
Mid: pgsql, scale=100, cache=1500MB, maxblocks=192001*8192
Setting up table: planet_osm_nodes
HINWEIS: Tabelle »planet_osm_nodes« existiert nicht, wird übersprungen
HINWEIS: CREATE TABLE / PRIMARY KEY erstellt implizit einen Index »planet_osm_nodes_pkey« für Tabelle »planet_osm_nodes«
Setting up table: planet_osm_ways
HINWEIS: Tabelle »planet_osm_ways« existiert nicht, wird übersprungen
HINWEIS: CREATE TABLE / PRIMARY KEY erstellt implizit einen Index »planet_osm_ways_pkey« für Tabelle »planet_osm_ways«
Setting up table: planet_osm_rels
HINWEIS: Tabelle »planet_osm_rels« existiert nicht, wird übersprungen
HINWEIS: CREATE TABLE / PRIMARY KEY erstellt implizit einen Index »planet_osm_rels_pkey« für Tabelle »planet_osm_rels«
Reading in file: hamburg.osm.pbf
Unable to open hamburg.osm.pbf
Error occurred, cleaning up
wenn Du keine libgdal (oder libprotobuf-c) unter /usr/local/lib hast, dann lass mal das
LD_LIBRARY_PATH=/usr/local/lib
einfach weg.
Bei mir sieht das ganze für Hamburg so aus:
$ osm2pgsql -s hamburg.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
Allocating node cache in one big chunk
Mid: pgsql, scale=100, cache=800MB, maxblocks=102401*8192
Setting up table: planet_osm_nodes
HINWEIS: CREATE TABLE / PRIMARY KEY erstellt implizit einen Index »planet_osm_nodes_pkey« für Tabelle »planet_osm_nodes«
Setting up table: planet_osm_ways
HINWEIS: CREATE TABLE / PRIMARY KEY erstellt implizit einen Index »planet_osm_ways_pkey« für Tabelle »planet_osm_ways«
Setting up table: planet_osm_rels
HINWEIS: CREATE TABLE / PRIMARY KEY erstellt implizit einen Index »planet_osm_rels_pkey« für Tabelle »planet_osm_rels«
Reading in file: hamburg.osm.pbf
Processing: Node(1256k 27.9k/s) Way(245k 6.45k/s) Relation(4790 133.06/s) parse time: 119s
Node stats: total(1256896), max(1478161792) in 45s
Way stats: total(245039), max(134438061) in 38s
Relation stats: total(4797), max(1806442) in 36s
Going over pending ways
processing way (173k) at 0.87k/s
Pending ways took 199s at a rate of 872.71/s
Going over pending relations
node cache: stored: 1256896(100.00%), storage efficiency: 2.16%, hit rate: 100.00%
Committing transaction for planet_osm_roads
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Sorting data and creating indexes for planet_osm_line
Sorting data and creating indexes for planet_osm_polygon
Sorting data and creating indexes for planet_osm_roads
Stopping table: planet_osm_nodes
Stopped table: planet_osm_nodes
Stopping table: planet_osm_rels
Building index on table: planet_osm_rels (fastupdate=off)
Committing transaction for planet_osm_point
Sorting data and creating indexes for planet_osm_point
Stopping table: planet_osm_ways
Building index on table: planet_osm_ways (fastupdate=off)
Stopped table: planet_osm_rels
Indexes on planet_osm_roads created in 19s
Completed planet_osm_roads
Indexes on planet_osm_point created in 44s
Completed planet_osm_point
Indexes on planet_osm_line created in 58s
Completed planet_osm_line
Indexes on planet_osm_polygon created in 97s
Completed planet_osm_polygon
Stopped table: planet_osm_ways
Osm2pgsql took 424s overall
$
Ciao,
Frank
EDIT:
Wenn die libprotobuf-c nicht gefunden würde (unter z. B. /usr/local/lib) wäre die Fehlermeldung:
Reading in file: hamburg.osm.pbf
error parsing member type of BlockHeader
Error unpacking BlockHeader message
Error occurred, cleaning up
So hat es funktioniert … also habe jetzt die datei entpackt und eingelesen mit osm2pgsql! die fehlenden Tabellen wurden angelegt die DB ist jetzt 313MB groß… ist das normal ? ich meine im vergleich, als ich die karte mit osmosis eingelesen habe war die 1,x GB groß …
über die datei “slippymap.html” bekomme ich leider noch nichts angezeigt, bzw nur eine weiße fläche, wenn ich beim Base Layer “local Tiles” ausgewählt habe und unter http://localhost/osm/0/0/0.png bekomm ich nur ein “NOT FOUND” error. Den Renderer job habe ich auch neugestartet aber der tiles ordner ist noch leer.
Die Slippymap steht standardmäßig irgendwo ziemlich weit im Süden von Deutschland, wenn es nicht sogar die Schweiz ist. am besten stellst du mal auf Layer Mapnik um und schaust wo du bist. Dann kannst du deine Position korrigieren und nochmal auf deinen Layer zurückschalten.
Sollte es dann nicht klappen, liegt es wahrscheinlich am Rendereing. Hier könnten zum Beispiel die Küstenlinien fehlen? Hast du auch den User www-data für die DB? Immerhin läuft der rendering job unter diesem Account.
Soll es ja auch. Wirklich gearbeitet wird ja erst auf anforderung. Aber wenn das Tile 0/0/0 nicht da ist, lässt das vermuten, dass entweder der Server nicht rennt und die Anforderung weitergibt oder das Mapnik die Küstenlinien nicht zur Hand hat, denn das zeichnet er bei mir in das Tile rein. auch wenn ich nur Berlin oder ein andere Bundesland nehme.
die Position habe ich schon mit korrigiert (in der HTML datei ) … da wird mir trotzdem nichts angezeigt
der User www-data existiert in der DB. hab dem eben nochmal superuser rechte gegeben und den rendering job neugestartet, was aber keine änderung gebracht hat.
also das Ganze läuft definitv unter Debian 6 (64 Bit), denn bei mir geht’s auch
Zum Debuggen könntest Du noch den renderd im Vordergrund laufen lassen:
# /usr/bin/renderd -f
(bei dessen Start könnten schon Fehlermeldungen auftauchen).
Desweitern hat mod_tile auch eine Art “Statusseite” unter http://localhost/mod_tile
Diese diversen
NoRespZoom08: 34
müssten sich beim Verschieben/Reinzoomen der Karte hochzählen.
Bekommt der renderd dann Anfragen, muesste sowas wie
renderd[2302]: DEBUG: Got incoming connection, fd 11, number 1
renderd[2302]: DEBUG: Got incoming connection, fd 12, number 2
renderd[2302]: DEBUG: Got command RenderPrio fd(11) xml(default), z(13), x(4349), y(2801)
renderd[2302]: DEBUG: Got incoming connection, fd 13, number 3
auftauchen.
Hat er fertig gewuselt, dann
renderd[2302]: DEBUG: DONE TILE default 14 8696-8703 5600-5607
renderd[2302]: DEBUG: DONE TILE default 14 8696-8703 5600-5607 in 6.007 seconds
also mit dem Renderd -f befehl bekomm ich die folgenden errors … hab das script jetzt ca 20 min laufen lassen und es kam nichts mehr … (CPU load war auch auf 0%)
renderd[6222]: Starting stats thread
renderd[6222]: An error occurred while loading the map layer 'default': /etc/mapnik-osm-data/world_boundaries/shoreline_300 does not exist (encountered during parsing of layer 'world')
renderd[6222]: An error occurred while loading the map layer 'default': /etc/mapnik-osm-data/world_boundaries/shoreline_300 does not exist (encountered during parsing of layer 'world')
renderd[6222]: An error occurred while loading the map layer 'default': /etc/mapnik-osm-data/world_boundaries/shoreline_300 does not exist (encountered during parsing of layer 'world')
renderd[6222]: An error occurred while loading the map layer 'default': /etc/mapnik-osm-data/world_boundaries/shoreline_300 does not exist (encountered during parsing of layer 'world')
Der Ordner “world_boundaries” ist nicht vorhanden … also weder so auf dem System noch in der Datenbank(falls es ein “Virtueller” Ordner/Tabelle etc. sein sollte)
und wenn ich die Statusseite von mod_tile aufrufen will bekomm ich nur ein 404 NOT FOUND Error.
So langsam habe ich das gefühl, dass irgendwas bei der installation schief gegangen ist ^^
Bitte vorsichtig. oneandonlycore benutzt nicht Ubuntu, sondern Debian. Zwar basiert Ubuntu auf Debian, aber es gibt eben auch Unterschiede, so dass zum Beispiel die Installation nicht richtig klappt. Dann ist die Ganze Sache Handarbeit.
Ich persönlich habe schlechte Erfahrung mit der Wiki Anleitung gemacht, als ich diesen Server hier nachbauen wollte: http://wiki.openstreetmap.org/wiki/DE:HowTo_minutely_hstore
Und das nur weil sich die Software weiterentwickelt. Es gab andere Versionsnummern. Plötzlich standen Skripte wo anders etc.
Die Pakete machen es einem wirklich sehr viel Leichter als bei Windows. Aber auch nur wenn sie direkt für diese Distribution gepackt wurden und nach Anleitung installiert werden.
ich habe den befehl grade ausgeführt und jetzt lädt er fleißig runter … nur stell ich mir grade die frage, ob er nun die küstenlinen für die ganze welt runterzieht … weil das anscheinend ja doch recht groß ist was da runtergeladen wird …
Ja die Küstenlinien gibt es nur Weltweit. Du hast die Möglichkeit entweder die zu nehmen oder den Mapnikstyle zu ändern. Je nach resourcen ist das eine oder andere besser.
Gemacht hat man das übrigens, da in der Datenbank öfter mal Wege verloren gehen und die Küsten dann nicht geschlossen sind. Das führt dann aber zu Überflutung ganzer Kontinente. Daher gibt es in bestimmten Abständen einen Prozess zu Erzeugung dieser Küstenlinien, aber eben nur weltweit und nicht nach Regionen oder gar Wunschausschnitten.
so … ich habe jetzt nochmal den renderd -f befehl gestartet … allerdings passiert da nicht mehr als das (das wurde mir vorher auch schon angezeigt … und danach kamen die errors … jetzt passiert das selbe nur ohne errors :/):
Das läuft jetzt ca schon 40min … CPU load ist bei 0% und beim Aufrufen von slippymap.html wird mir immernoch nichts angezeigt. Die Statusseite “mod_tile” und http://xxx.xxx.xxx.xxx/osm/0/0/0.png ist immernoch nicht verfügbar → 404Error!
die DB ist jetzt 313MB groß… ist das normal ? ich meine im vergleich, als ich die karte mit osmosis eingelesen habe war die 1,x GB groß …
) … da wird mir trotzdem nichts angezeigt 
