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.
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 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 .
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 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.
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.
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 … ?
Ich brauche noch die Details von WAYS - du hast mir nodes aufgelistet. Es geht darum ob linestring und bbox als Spalten vorhanden sind. Die entsprechende Frage hast du noch nicht beantwortet.
Achtung: die beiden Scripte GENAU in der Reihenfolge laden, wie es in der Doku steht.
Da du pgsnapshot_load_0.6.sql offensichtlich nicht verwendest, mußt du zumindest die Befehle zum Erzeugen der Indices laufen lassen.
Nachher muss ways so aussehen:
Table "public.ways"
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 |
nodes | bigint[] |
bbox | geometry(Geometry,4326) |
linestring | geometry(Geometry,4326) |
Indexes:
"pk_ways" PRIMARY KEY, btree (id)
"idx_ways_bbox" gist (bbox)
"idx_ways_linestring" gist (linestring) CLUSTER
also bbox VOR linestring, sonst knallt es beim Import, den du eh neu machen musst.
und 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)
"idx_nodes_geom" gist (geom)
Inzwischen ist die Lage bei dir ziemlich konfus und es ist schwer, Bedienungsfehler zu erkennen. Zumindest sehe ich, dass bis jetzt einiges fehlt. (Spalten und Indices).
beide SQL sind in GENAU der Reihenfolge eingelaufen! Leider funktioniert das bei mir (Windows?) mit der Kurzschreibweise nicht! Hatte das wohl in dem anderen Posting irgendwie übersehen.
… was meinst Du damit - noch ein anderes spezielles Kommando oder Script ??
Anm.: Parallel schreibe ich schon ein Installationsprotokoll - dann kann man es später in einem Stück nochmal nachvollziehen …