Hilfe bei Postgis Einrichtung

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.

Ich hoffe mal, du das den Script innerhalb von psql aufgeführt, oder?


walter@wno-server:/opt/install/yacy$ psql planet master
psql (9.1.9)
Type "help" for help.

planet=# \i /osmosis/script/pgsnapshot_load_0.6.sql
..
..
..
\q

oder auch mit psql planet master -f /osmosis/script/pgsnapshot_load_0.6.sql

planet ist bei mir der Name der db und master der superuser.

psql-Befehle fangen mit \ an. \i steht für include, \q für quit und ? für psql-Help.

\h gibt sql-help aus. also die Hilfe über die sql-Befehle. Mer reden hier derzeit aber über PSQL.

Gruss
walter

hi !

ich habe innerhalb von pgAdmin auf das Icon mit der Lupe und dem Text SQL geklickt. Dann kam ein Dialog und da war die Registerkarte SQL-Editor aktiv.

In das linke obere Feld habe ich den Inhalt aus der pgsnapshot_load_0.6.sql reinkopiert (sorry, im Posting oben xxx statt des Namens geschrieben).

Dann habe ich auf Abfrage ausführen (grüner Pfeil) geklickt - dann kam es zu genannte Meldungen gekommen.

War das falsch oder richtig ?

Was meinst Du ansonsten mit “innerhalb von psql” ??

Gruß Jan :slight_smile:

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:


psql -d osm -f pgsnapshot_load_0.6.sql

Christian

hi !

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!

Eine Idee ?

Gruß Jan :slight_smile:

ja -d osm meint entsprechende DB.

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 :wink:

hi !

mit Hilfe von Brogo bin ich heute Abend etwas weitergekommen und wir haben pgsnapshot_schema_0.6.sql einlesen können - fast, denn nachher kamen Fehlermeldungen … doch erst einmal das Protokoll:

… doch dann ist da diese Fehlermeldung…

Brogo meinte das dieses mit der fehlenden plpgsql zu tun haben könnte; doch auch ein…

hat nichts geändert.

Hat einer eine Idee zu später Stunde ?

Gruß Jan :slight_smile:

Hallo,

ich kenne den Installationsweg unter Windows nicht. Unter Linux ist es so, dass man zuerst einmal sich als postgres bei der Datenbank template1 anmelden und sich einen Benutzer mit entsprechenden Rechten für die Bearbeitungen einrichten muss.

Danach kann man dann im eigenen User mit createdb eine Datenbank einrichten.

Den Hinweis mit hstore habe ich von einem Windows-User. Ich habe es mangels Windows noch nicht getestet.

Gruß, Wolfgang

klaro,

installiere den Postgis Legacy Support indem du den psql-Script legacy.sql startest. Der befindet sich bei mir im Laufzeit-Verzeichnis /usr/share/postgresql/9.1/contrib/postgis-2.0/legacy.sql - sollte bei dir ja wohl in 9.2 liegen. Wo das Zeug bei windows liegt, kriegst du ja wohl selber raus.
Ansonsten ist der auch noch im Installations-Verzeichnis von postgis-2.0.1/postgis zu finden.

Gruss
walter

Moin !

ich habe nun das mit der* legacy.sql* “versucht” mit folgendem Aufruf:

und erhalte folgendes Protokoll - leider ist der Anfang nicht mehr im Befehlszeilenfenster von Windows zu erreichen und auch ein > Dateiname für die Ausgabe liefert immer nur ein* CREATE FUNCTION*.

Weiter ist dieses das Ergebnis des zweiten Versuchs! Nur der vollständigkeithalber.

Ich verstehe nur Bahnhof … ? \help

Auch wenn noch nicht alles soweit ist - ich habe mir schon einmal die Tabellen angesehen wie diese mit den Spalten angelegt sind. Die Tags sind alle in der gleichnamigen Spalte hinterlegt. Könnte man den osmosis-Import später (nur mal so prinzipell) so konfigurieren das es Spalten zu den Standardtags highway, building, name etc. gibt. Würde doch sicherlich die Auswertung in den QGIS-Rules vereinfachen?

Dann eine Frage zum allgmeinen. Wenn man dann mal ein Projekt im Süden, im Norden und Westen hat und diese relativ räumlich begrenzt sind würde man diese Daten in eine DB aufnehmen oder zur jedes eine eigene DB?

Zu guter Letzt das Thema Update. Kommen neue Daten - ich spreche jetzt nicht von einem Intervall-Update ! - dann müßte man pgsnapshot_schema_0.6.sql nur neu einlesen und alles ist für diese DB zurückgesetzt ! Korrekt ?

… so nun muss erst einmal die ganze Sache rund gemacht werden.

Gruß Jan :slight_smile:

Der sieht vernünftig aus. kannst es das nächste mal mit psql osm postgres -f … versuchen. hat nix mit dem Problem zu tun, ist einfach weniger Tipperei.
(zumindest bei mir unter ubuntu)

Die Hinweise sind unkritisch. Was mit den Fehlern ist, kann ich auch nicht erklären. Hat denn der Import geklappt? Insbesonders die vorher berechtigte Meldung bei “SELECT AddGeometryColumn(‘nodes’, ‘geom’, 4326, ‘POINT’, 2);” sollte weg sein. Diesen Befehl einfach mal in PSQL eingeben. Entweder kommt der selbe Fehler (AddGeometryColumn nicht bekannt) oder er sagt, dass die Spalte “geom” in der Tabelle nodes bereits existiert.

So sollte **nodes **aussehen:

 walter@wno-server:/opt/install/yacy$ psql planet master
psql (9.1.9)
Type "help" for help.

planet=# \d nodes
                  Table "public.nodes"
    Column    |            Type             | Modifiers 
--------------+-----------------------------+-----------
 id           | bigint                      | not null
 version      | integer                     | not null
 user_id      | integer                     | not null
 tstamp       | timestamp without time zone | not null
 changeset_id | bigint                      | not null
 tags         | hstore                      | 
 geom         | geometry(Point,4326)        | 
Indexes:
    "pk_nodes" PRIMARY KEY, btree (id), tablespace "tablespace1"
    "idx_nodes_geom" gist (geom)

planet=# \q
walter@wno-server:/opt/install/yacy$ 

Wichtig ist die Spalte “geom”. Ich meine aber in deinem Output gesehen zu haben, dass irgendwo geom fehlt.

Nicht so einfach und mMn unnötig. Außerdem könntest du dann gleich osm2pgsql nehmen. Du willst ja “nur” das machen, was dein Kumpel (?) erstellt hat und solltest da sowenig wie möglich andern.

Ich würde EINE DB für alle Bereiche nehmen, diesen Bereich (Germany?) aber immer komplett importieren/pflegen. Du kommst dann nur in Versionskonflikte. Und spätestens, wenn du ein wenig mit Postgis “rumgespielt” hast, bekommst du das Problem, dass dir genau die Ecke fehlt, die du für irgend eine Ad-Hoc-Query brauchst.

Natürlich nicht :frowning: Du müsstes pgsnapshot_load_0.6.sql neu laufen lassen.

btw: hast du pgsnapshot_schema_0.6_bbox.sql und pgsnapshot_schema_0.6_linestring.sql laufen lassen? solltest du machen,** wenn die aktuellen Probleme weg sind.** dann muss aber pgsnapshot_load_0.6.sql laut eingebauten Kommentaren geändert werden.
Zeig mal den output von \d ways .

Gruss
walter

Möglicherweise postgis nicht korrekt installiert?

Das ist nicht falsch, aber afaik ab postgis 2 nicht mehr notwendig. Geometry-Columns können genauso wie alle anderen Datentypen erzeugt werden.

Das dürfte der hstore sein. Es ist sinnvoller, sich später die Spalten zu machen, die man dann wirklich braucht. Die paar Standardspalten lohnen den Aufwand nicht, den Gedankengängen der vorgefertigten Skripte folgen zu müssen. Bei mir habe ich alleine für Linien 85 Spalten. Vielleich käme ich mit 10% weniger aus, aber irgendwas braucht man immer für irgendeine Logig.

Das kommt darauf an, was du machen willst. Wenn du Pläne in verschiedenen Maßstäben machen willst, die voneinander unabhängig sind, sich teilweise sogar noch überlappen könnten, dann mache ich für jede Karte eine DB. Wenn du eine weltweite Karte online stellen oder sonstige Auswertungen fahren willst, ohne irgendwelche Daten manipulieren zu müssen, kommt es wieder auf deinen Platz, die Rechenkapazität und das Gebiet an. Ständige Auswertungen für ein einigermaßen zusammenhängendes Gebiet sind natürlich mit einer einzigen, ständig aktuell gehaltenen DB sinnvoller.

Installiere deine DB erst einmal sauber. Dann sieh dir den Prozess an und vollziehe es nach. Das ist sowieso wichtig, weil du früher oder später das noch einmal machen musst, spätestens auf einer neuen Platte/Rechner. Wenn das ganze reibungslos läuft, erstelle dir ein Script, das das Ganze automatisch erledigen kann. In den Punkt solltest du ruhig Arbeit stecken, davon lebst du später. Das Script vervollständigst du dann im Verlauf der weiteren Bearbeitung Schritt für Schritt. Dann kannst du jederzeit deine DB wegschmeißen und neu aufbauen, falls du nicht gerade ganz Europa laden willst. Während die Kiste läuft, holst du dir einen Kaffee und kannst dann weiter machen ;-). Wenn du die DB nicht löschst, sondern nur die Tabellen, kannst du qgis sogar weiterlaufen lassen. Natürlich nicht gerade dann zoomen oder sowas :wink: Dann kannst du auch Daten, die nicht gelöscht werden sollen, in einer extra-Tabelle aufheben, die erhalten bleibt und anschließend ggf. wieder eingepflegt wird.

Versionskonflikte gibt es dabei gar nicht. Falls wirklich postgres mit einer neuen Version eingespielt wird, prüfst du dein Script mit der neuen Version, haust die alten DBs weg und erzeugst sie, soweit gebraucht, neu. Erhaltenswerte Tabellen müssten dann mit pgdump vorher gesichert werden, aber das sollte das Script automatisch sowieso machen. Außerdem ist das ggf. auch eine Frage der Datensicherung.

Die einzigen Versionskonflikte, die wirklich ärgerlich sind, entstehen bei neuen Versionen von qgis. Der kann teilweise sein Konfig-file aus der vorhergehenden Version nicht korrekt lesen.

Wie gesagt, wenn du die ganze Welt mit allen Daten ständig aktuell vorhalten willst, sieht das natürlich anders aus.

Gruß, Wolfgang

Moin !

das sieht wohl nicht gut aus :frowning:

Ich hatte das in die Console unter Plugins>PSQL Console eingegeben!

Gruß Jan :slight_smile:

PS: habe nochmal gegoggeld und unter https://www.pg-forum.de/viewtopic.php?t=4565 einen Beitrag von dem akretschmer gefunden:

Kann das bei mir auch der Fehler sein ? Wie könnte ich das prüfen?

Hier noch mein Strukturbaum

Gruß Jan :slight_smile:

Prüfe den Installtionsweg, besonders postgis. Ich habe nicht den Eindruck, dass es funzt.

Gruß, Wolfgang

Eben erste gesehen…

Ja, das ist wahrscheinlich der Fehler.

    psql -d "$DATENBANK" -f /usr/share/postgresql91/contrib/postgis-2.0/postgis.sql
    psql -d "$DATENBANK" -f /usr/share/postgresql91/contrib/postgis-2.0/postgis_comments.sql
    psql -d "$DATENBANK" -f /usr/share/postgresql91/contrib/postgis-2.0/spatial_ref_sys.sql
    psql -d "$DATENBANK" -c "create extension hstore;"

wird unter Windows wohl etwas anders heißen.

Das ist der Nachteil bei den Scripten: Man installiert dauernd und kennt die Einzelheiten nicht mehr;-)

Gruß, Wolfgang

Hallo Wolfgang,

ich mir derzeit nicht mehr sicher die 3-SQL eingebunden zu haben !?!??!?

Habe nochmal nachgesehen und unter http://wiki.openstreetmap.org/wiki/Osmosis/PostGIS_Setup#Postgres_9.1 wird bei 9.1. nicht mehr davon geschrieben.

Dann muss ich die wohl nochmal nachschießen !!

Gruß Jan :slight_smile:

Stimmt! Da sind viel zu wenige Funktionen drin. Du hast 216 und ich habe 1350 - siehe meinen 1 screenshot aus post #20. Ca 20 sind von mir also sollten es etwa 1330 sein.

→ PostGis nicht richtig installiert.

Gruss
walter

Könnte was dran sein :wink:

Hi !

ist da was von wegen Reihenfolge wichtig ?

Gruß Jan :slight_smile:

PS: habe nicht gewartet und habe die 3 SQL eingebunden…

Es gab keine Fehlermeldungen und aus 216 Funktionen sind jetzt schon einmal 741 geworden.

@wambacher: zu #25 - jetzt gibt es folgende Rückmeldungen…

und

looks better ?

hi !

ich habe jetzt einfach mal wieder Mut zur Lücke gehabt und den osmosis-Import in Betrieb genommen - dabei ist folgendes herausgekommen:

An den abweichenden Richtungen des osmosis-Aufrufs kann es nicht gelegen haben. Vielmehr ist es die Zeile

Wenn ich das richtig gesehen habe, dann hat meine DB das Schema 0.6 - wie kommt osmsis dann auf den Gedanken das Schema 0.5 anwenden und kann man das zuweisen ?? Das DB-Schema stammt doch aus dem osmosis-Verzeichnis … ?

Gruß Jan :slight_smile: