Hilfe bei Postgis Einrichtung

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

Moin !

ich habe jetzt nochmal neu installiert und zunächst von http://www.enterprisedb.com/products-services-training/pgdownload#windows die entsprechende Version.

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.

Gruß Jan :slight_smile:

[1] http://postgis.net/windows_downloads

[2] http://wiki.openstreetmap.org/wiki/Osmosis/PostGIS_Setup

Jo, richtig

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” :slight_smile:

hi !

so - einen Schritt weiter …

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 ?

/help !

Gruß Jan :slight_smile:

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