erst mal Gratulation, dass du (endlich) mit Postgresql/Postgis loslegst. Aber du hast ja selber mal geschrieben, dass du Zeit dafür brauchst.
Was mir so auffällt:
wilst du wirklich eine DB nach dem Snapshot-Schema anlegen?
Ich frage nur zu deiner Sicherheit, da gefühlte 95% aller** OSM**-Postgresql/PostGIS-DBs mit dem Simple-Schema und osm2pgsql &co angelegt werden.
“Meine” Planet-DB ist auch Snapshot und wird mit osmosis “gefüttert” und aktuell gehalten. Ich nutze die als Quelle für meine Auswertungen und Online-Projekte (Missing Residentials und demnächst PLZ 2.0). Ich kann damit aber nicht rendern und routen. Also denk noch mal kurz drüber nach.
Postgresql 9.2 ist ok; ich fahre 9.1 und drücke mich noch ein wenig vor dem Upgrade.
PostGIS 1.5 ist ein absolutes NOGO - total veraltet. 2.0 ist die aktuelle Version.
du benutzt total veraltete Sekundärliteratur von Anfang 2012 (sorry André). Sowas sollte man schon beim Hersteller nachlesen.
Ich erkläre mir einige deiner Probleme dadurch - plus Windows als Platform, kann dir aber wegen Windows nicht weiter helfen.
mache Dir nicht zuviel Hoffnung - primär möchte ich das Nutzen um Papierkarten unter QGIS zu erstellen und der Macher des Lübecker Fahrradstadtplan hat mir davon vorgeschwärmt und benutzt diese Konstellation. Der arbeitet allerdings auch unter LINUX. Mir steht aber primär nur Win zur Verfügung.
Dann muss ich mich mal auf die Suche nach entsprechender Literatur machen.
Frage ihn lieber nochmal welches Datenbankshema er verwendet. Ich persönlich bevorzuge auch für die Zusammenarbeit mit Qgis lieber das osm2pgsl shema. Das hat den angenehmen Vorteil das Flächen bereits flächen sind und Linien schon Linien. In der OSM DB gibt es das so nämlich nicht! Darum warnt wambacher ja so eindringlich davor. Geometrien werden erst durch osm2pgsql angelegt vorher sind es nur Datensätze.
Hi,
er verwendet osmosis. Warum? Weil man da nicht bevormundet wird. Was ich überhaupt nicht ausstehen kann, ist ein Ausfiltern von irgendwelchen Datentypen, und das passiert, soweit ich es gelesen habe, bei osm2pgsql. Im übrigen ist es ein Gerücht, dass osmosis keine Linien aufstellt. Alle Linien sind komplett dabei. Geschlossene Polygone eben mit posgis in einer Tabelle einzuordnen dürfte nach etwas Lesen kein Problem darstellen.
Die Multipolygone sind zugegeben etwas komplizierter, aber mit etwas Probieren bekommt man auch das hin. Die Dokumentationen von postgresql, postgis und qgis sind hervorragend. Es gibt nicht viele Projekte mit so guter Dokumentation.
Es gibt übrigens, das habe ich auch gesagt, osm2postgresql. Man achte auf die nicht abgekürzte Schreibweise. Das Script stellt bereits vorgefertigte Tabellen zu Verfügung. Damit hatte ich angefangen, später habe ich es dann durch eigene Scripte ersetzt.
Ein Unterschied: Unter Linux steht hstore zur Verfügung, der zwar mit qgis nicht nutzbar ist, aber jederzeit über Scripte die Erstellung von weiteren Tabellen, Spalten oder Werten ermöglicht, die dann von qgis genutzt werden können. Ich vermute, dass unter Windows dafür ein Textfeld genutzt wird, da hstore unter Windows nicht laufen soll. Das habe ich aber selbst noch nicht getestet.
Das war ja vor ca 3 Jahren für mich der Grund, die Finger von osm2pgsql zu lassen. Andauernd fehlten Werte, weil das Filter die netterweise sofort rausgeschmissen hat (“Brauchst du eh nicht”). Was ich haben wollte, war eine DB wo alles drinsteht und ICH entscheide was wichtig ist. Klar, man kann das Import-Schema erweitern und die DB neu aufsetzen - aber beim Planet macht das wirklich keinen Spass mehr.
Daß dann manche Sachen nicht so einfach sind, war mir klar, aber meine Freiheit war mir lieber.
Es gibt hier sogar Kollegen, die zweigleisig fahren: Eine DB zum Rendern/Routen und eine für speziellere Sachen.
Eine OSM-DB ohne hstore wäre für mich unzumutbar. Allerdings habe auch ich keine WIN-Erfahrung damit.
Welche Tags schmeißt osm2pgsql raus, wenn ihr hstore habt? Ich hoffe Euch fällt bei der Behauptung was gutes ein.
Ja man kann jederzeit das importschema so anpassen wie man es gerne hätte. Das dies vielleicht beim Planeten keine gute Idee ist, steht auf einem anderen Blatt. Wenn ich mir jeodch vorstelle wie ich aus alle Multipolygonen und Routen erstmal vernüftige Strukturen machen muss, bevor das auch nur angezigt werden kann, finde ich den Weg über osm2pgsql für die Anzeige von xy in Qgis nicht nur bequemer sondern erheblich schneller.
und spätestens bei allen Verwaltungsgrenzen und Landuses über Deutschland wird es denn bei der Anzeige auch eine performancefrage für den Server, wenn er das onthefly berechnen soll, oder?
Schau dir mal an ob du PostGIS richtig installiert hast.
Du schreibst oben
in den Skripten steht aber 1.5
Warum sollte hstore unter Windows nicht verfügbar sein?`Es ist als Erweiterung in der PostgreSQL Datenbank zu installieren und in osm2pgsql gibt es einen paramter --hstore
ok, gewonnen Ich glaube, dass es zu der Zeit als meine Entscheidung gefallen ist, hstore noch nicht das Thema war oder ich hab das damals (2009/2010) übersehen.
Offen und für Jan mMn relevant ist: “geht Hstore unter Windows”? Ich bin und bleibe der Meinung, dass eine OSM-DB ohne hstore Schrott ist und begrüße es, dass osm2pgsql hstore unterstützt.
Ich habe das Problem, das wirklich gravierend ist, anders gelöst: Die Arbeit, die osm2pgsql freundlicherweise beim Import erledigt (Flächen und Grenzen zusammenfassen), macht bei mir die Datenbank. Es gibt da einige Trigger, die das “on the Fly” erledigen, immer dann wenn sich daran was ändert.
War aber ein hartes Stück Arbeit.
Was mir jetzt unklar ist (hab mich eigentlich nie wieder richtig mit osm2pgsql beschäftigt): geht, und wenn ja wie, der Update mit minütlichen Diff-Files? Und um das zu toppen: was ist mit dem Streaming Update mit Osmosis, der das Lag auf unter 10 Sekunden runterschrauben soll? Hab den zwar noch nicht zum Laufen bekommen, aber das ist ein anderes Thema.
Wenn Jan ein ganz bestimmtes Ziel hat und der Weg dahin ausgebaut ist, soll er ihn ruhig so gehen - allerdings mit der aktuellen Software und passender Dokumentation.
Gruss
walter
EDIT: Nehmen wir mal an, dass hstore unter Windows geht. Hatte mvollmers Reply noch nicht gelesen.
Dann habe ich wie in [1] hingewiesen den Stack installiert und darüber dann Postgis 2.0.
Das Programm startet auch ! Dann habe ich im OSM-Wiki geschaut und mich mal auf [2] an 9.1 orientiert.
Das dort aufgeführte anlegen der Datenbank osm, die lang mit User OSM sollten nicht die Hürde werden. Das kann man dann auch ggf. noch manuell machen. Das werde ich mir gleich mal ansehen.
Wenn ich das richtig verstehe, dann ist ab 9.1 nicht mehr das Ausführen SQL-Dateien aus 9.0.1 erforderlich. Liege ich richtig?
Dann würde ich jetzt davon ausgehen das ist noch pgsnapshot_schema_0.6.sql aus dem OSMOSIS-Verzeihnis zu importieren? Allerdings verstehe ich das weiter nicht und auch nicht das was das mit dem Superuser auf sich hat.
Als nächstes würde dann ja der Import nach Import a osm file into the database folgen ?
Wäre klasse, wenn mir einer von Euch nochmal etwas weiterhelfen könnte.
Superuser ist der PGSQL-Admin. Ich nehme hier den user postgres
Ich importiere mit osmosis/script/pgsnapshot_load_0.6.sql .
Am Anfang hab ich die Befehle, die da drinstehen, einfach mit copy/paste einen nach dem anderen im Fenster ausgeführt. Dadurch hab ich viel gelernt. Man sieht auch gleich wo es klemmt. Jetzt rennt der bei mir sauber durch - zuletzt vor ca 3 Monaten für 5 Tage bei einem Planet-Import. Da war Geduld, gute Nerven und ein stabiles System angesagt.
aber gerne. (*)
Gruss
walter
*) “Schon wieder eine Seele vom … gerettetet, schon wieder eine Seele zu PostGis hingebracht”
Jetzt wollte ich das pgsnapshot_load_0.6.sql einspiele. Muss ja gestehen einwenig kenne ich solche Arten von Tools (Autodesk Topobase die auf oracle setzt).
Wenn ich das Script ausführen will (oder muss ich pgScript ausführen anklicken ?), dann kommt es im Block
zu folgender Fehlermeldung:
Ist das Linux-Syntax oder von wo soll da was geholt werden ?
Also osm2pgsql unterstützt updates, wenn man mit --slim startet, was bei größeren Importen mangels Arbeitsspeicher eh erforderlich sein dürfte. Ob da jetzt streaming geht wage ich zu bezweifeln, weiß ich aber nicht.
Viel schwerer wiegt eigentlich die Tatsache das hstore in der für windows komplierten Version bei osm2pgsql nicht funktionieren soll. In der alten Version war dies noch kein Problem, aber dort gibt es dann den 32bit Überlauf für die IDs. Man sollte sich also überlegen wieviel man importiert. Wer nur Bundesländer oder Deutschland importiert, wird mit osm2pgsql hinreichend schnell eine neue Datenbank aufsetzen, wenn er doch noch andere Tags braucht. Wird das Gebiet größer wird das ganze unangenehmer. jedenfalls mit dem Windowsclient. Aber es gibt ja für den Import auch Knopix und/oder virtuelle Maschienen.
Im Grunde sollte das auch klappen, egal ob über pgAdmin oder über psql. Bei pgAdmin ist darauf zu achten, in welcher Datenbank, Du das Script ausführst.
Kurz was Grundsätzliches: mit pgsnapshot_schema_0.6.sql wird für die schon erstellte Datenbank das Snapshot-Schema angelegt. Mit pgsnapshot_load_0.6.sql lädst Du dann in die Datenbank einen mit osmosis mit der Option --write-pgsql-dump erstellen Dump in die Datenbank. Alternativ kannst Du mit Osmosis direkt ohne Zwischenschritt mit –write-pgsql in die Datenbank schreiben. Zu Testzwecken solltest Du erstmal mit einem kleinen Extrakt (z.B. nur Lübeck) anfangen.
Halt nicht direkt auf der Kommandozeile, sondern über den psql-Befehl. Du kannst psql über die Kommandozeile starten. Denn Pfad solltest Du aber vorher in die Windows-Umgebungsvariable “PATH” aufnehmen. Dann kannst Du die SQL-Scripte auch so ausführen:
habe jetzt die Konsole geöffnet und folgende Eingaben gemacht. Das osm vorab steht vermutlich für die aktuelle Datenbank?
Das Protokoll hat zwei Versuche - im zweiten habe ich mir überlegt das das mit psql und -d vermutlich weggelassen werden, da ich schon da bin.
Habe dann nochmal versucht das ich den Pfad in “” gesetzt habe - weil jan angemerkt wird. Dem Kommando wird zwar nicht wiedersprochen - aber es kommt auch keine Protokoll!!!
Im pgAdmin ist weiterhin nur ein Schema (public) gelistet!
Du kommst hier mit der Bedeutung von \ auf den verschiedenen Kommandoebenen durcheinander. In deinen Befehl ist \ Bestandteil des Windows-Pfadnamens zur Scriptdatei. Die scheint er nicht zu finden. Ich dagegen rede immer von dem \ als ersten Buchstaben der Befehle für den PSQL-Interpreter. Mit dem würde ich mich eh mal beschäftigen, da du dort in der Regel die PSQL-Befehle (mit ) und später alle deine SQL-Abfragen (ohne ) ausführen wirst.
ja, das ist auch ok so. Hauptsache deine DB - ich nehme mal an, dass die osm heisst- ist da. Und darin wird ein Schema “public” gelistet. “snapshot” oder sowas wirst du da nie sehen. Osmosis “redet” zwar vom snapshot-Schema aber das ist kein postgresql-Schema sondern beschreibt nur die OSM-Struktur der OSM-DB. Klingt verwirrend - ignoriere es einfach.
Ansonsten ist pgadmin prima zum Nachsehen und späteren Administrieren gut, aber der Script zum Füllen der DB ist da fehl am Platz. Das ist Job von PSQL.
Hier mal 2 Screenshots meiner DB:
DB planet mit public-Schema (aber snapshot drin)
erst hier erkennt man das osm-Schema. Da findet man neben nodes auch users, relations, relation_members, ways, way_nodes und andere Kleinigkeiten plus die von mir erzeugten Tabellen. Man beachte tags als hstore in der aufgeklappten Tabelle nodes.
tl;dr: psql als Interpreter aufrufen (psql osm superuser) und darin die Befehle eingeben. superuser ist natürlich der von dir gewählte oder auch postgres
Gruss
walter
lang lang ist es her, da hab ich hier auch nicht durchgeblickt - aber das gibt sich
