Datenbanklayer über CRON erzeugen

Aus kvwmap
Version vom 28. November 2006, 14:33 Uhr von Markus Hentschel (Diskussion | Beiträge)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

--Markus Hentschel 14:33, 28. Nov 2006 (CET)
Einige Operationen mit Daten der PostGIS-DB können ganz schön lange Laufzeiten verursachen, wenn man die Geometrie "on the fly" erzeugen lässt. Z.B. kann man alle Flurstücke in einem Layer ausgeben lassen, die eine Eintrag im ALB haben, dass sie in einem BOV liegen. Wenn man darauf ein GEOMUNION loslässt, um für jeweils ein Verfahrensgebiet auch nur ein Objekt zu erhalten, dann dauert das und man kann Kaffee trinken gehen. Es ist aber auch möglich, das entsprechende SQL in ein Shellscript zu packen und die Abfrage z.B. einmal die Woche durchzuführen. Dann hat man eine immer aktuelle PG-Datenbanktabelle mit den bereits fertig fabrizierten Geometrien und kann auf diese mit kvwmap wie gewohnt zugreifen.

Mein Script für obiges Beispiel sieht so aus:

#!/bin/sh
cd /usr/local/pgsql/bin
./psql -d dbname -U username -c "DROP TABLE gd_lk_bov_lauf;"
./psql -d dbname -U username -c " CREATE TABLE gd_lk_bov_lauf ( id varchar(10), ausfstelle varchar(50), verfnr varchar(10), the_geom geometry, CONSTRAINT enforce_dims_the_geom CHECK (ndims(the_geom) = 2), CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) = 'MULTIPOLYGON' OR geometrytype(the_geom) = 'POLYGON' OR the_geom IS NULL), CONSTRAINT enforce_srid_the_geom CHECK (srid(the_geom) = 2398) );"
./psql -d dbname -U username -c "ALTER TABLE gd_lk_bov_lauf OWNER TO kvwmap;"
./psql -d dbname -U username -c " INSERT INTO gd_lk_bov_lauf ( SELECT v.verfnr AS id, v.ausfstelle, v.verfnr, geomunion(o.the_geom) AS the_geom FROM alb_f_verfahren v, alknflst f,alkobj_e_fla o WHERE v.verfbem = '10' AND (v.ausfstelle = 'F0024' OR v.ausfstelle = 'F0100' OR v.ausfstelle = 'F0101' OR v.ausfstelle = 'F0103' ) AND v.flurstkennz = f.flurstkennz AND f.objnr = o.objnr GROUP BY v.ausfstelle, v.verfnr, o.the_geom ORDER BY v.ausfstelle );"
exit 0

Wenn man genauer hinschaut, sieht man, dass außer dem cd-Befehl vier Befehle auftauchen, die mit "./psql -d dbname -U username -c " anfangen. Diese Befehle machen Folgendes (den "ALTER TABLE"-Befehl ignorier ich mal):

  • 1. Lösche die Tabelle gd_lk_bov_lauf (also die Tabelle mit den laufenden BOVs)
  • 2. Lege die Tabelle neu an
  • 3. Schreibe die Geometrien in die Tabelle (der eigentliche Befehl)

Es ist sicherlich etwas die Holzhammermethode und geht bestimmt viel besser, aber es funzt. Vielleicht fühlt sich ja jemand berufen, dieses Skript zu verbessern, nur zu.

Problem bei geomunion: Verlaufen zwei Linien von zwei zu vereinigenden Objekten nahezu parallel, versagt die Funktion. Man erhält einen Fehler: "TopologyException: no outgoing dirEdge found - GEOS union() threw an error!". Für das Skript heißt das, dass es nur bis zum "INSERT" ausgeführt wird und dann abbricht, d.h. die Tabelle ist dann zwar da, aber leer. Weil in der ALK viele Linien ganz oder fast parallel laufen, ist die Gefahr also sehr hoch, dass das Ganze nicht funktioniert.

Wenn das so ist, hilft eigentlich nur, den geomunion-Befehl rauszunehmen (oder hat jemand eine bessere Idee?). Dann bringt aber der ganze Umweg über das Skript eigentlich auch keine Punkte mehr :-)

Die Lauffähigkeit des Skriptes nicht vergessen zu prüfen, in dem man es ausführbar macht und als root manuell startet.

Hat man das Skript geschrieben, speichert man es (unter SuSE) in einem der cron-Ordner ab, z.B. /etc/cron.weekly/ und macht das Skript für root ausführbar. In der Datei /etc/crontabs (wieder nur für SuSE) kann man noch einstellen, wann das Skript starten soll. Und dann harrt man der Dinge, die da kommen...