PostGIS in der fgs-dev Umgebung kompilieren

Aus kvwmap
Version vom 17. März 2008, 11:08 Uhr von Pkorduan (Diskussion | Beiträge)

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

Kompilieren eines benutzerdefinierten Modules für fgs am Beispiel postgis

Ist irgendein Modul für fgs nicht so konfiguriert, wie man es braucht, dann muss man sich das Modul selber erzeugen. Dazu nutzt man fgs-dev, siehe:

http://www.maptools.org/fgs/index.phtml?page=fgs-sandbox.html

und

http://wiki.osgeo.org/index.php/FGSDevNotes

fgs-dev kann man sich mit dem folgenden Befehl auf seinen Rechner ziehen: 

$cvs -d :pserver:cvsanon@cvs.maptools.org:/cvs/maptools/cvsroot checkout fgs-dev

Dazu muss man cvs auf dem Rechner installiert haben. Wenn der Befehl nicht gefunden wird, mit Yast nachinstallieren. In dem Ordner, wo man den Befehl ausführt, wird der Ordner fgs-dev mit den benötigten Daten angelegt. Ähnlich wie bei fgs setzt man zunächst ein paar Umgebungsvariablem mit dem setenv.sh Skript. Bevor das Skript ausgeführt wird muss man natürlich die Variablen darin korrekt setzen, z.B. FGS_DEV_HOME auf /opt/fgs-dev: 

$source setenv.sh

Hinterher prüfen mit: 

$echo $FGS_DEV_HOME

Als nächstes legt man sich eine Liste an mit den Modulen, die man selber kompilieren möchte. Eine Liste verfügbarer Module findet sich unter $FGS_DEV_HOME/pkg_def/build.list 

$fgsdev custom_build_list create postgis-lib

Mit diesem Befehl wird die Datei build_list in fgs-dev erzeugt. Sie enthält den Modulnamen postgis-lib und alle, die davon abhängig sind. In unserem Beispiel: libstdc:: proj:: postgresql:: geos:: postgis:: Wenn man jetzt 

$fgsdev build_all

startet, werden alle Resourcen runtergeladen jeweils nach $FGS_DEV_HOME/src kompiliert und installiert. Dabei kann man erstmal Kaffee trinken gehn, denn für postgresql und vor allem geos dauert das eine Weile.

Mit der Postgis-Version 1.0.6 wird es höchstwahrscheinlich am Ende Fehler geben. Da haut was mit dem Parameter --enable-autoconf nicht hin. Ist aber nicht schlimm, denn alle anderen Module hat er richtig kompiliert und Postgis wollten wir ja sowieso noch anpassen. Ich habe mit 1.0.6 lange rumprobiert, aber das configure Script läuft schon nicht richtig durch und wenn dann kommen beim make noch Fehler. Also habe ich gleich auf die PostGIS Version 1.3.1 gesetzt.

Man läd postgis-1.3.1.tar.gz von http://www.postgis.org/download/ und entpackt nach $FGS_DEV_HOME/src. Dann erzeugt man in dem Verzeichnis symbolische Links, die auf $FGS_DEV_HOME/pkg_def/postgis/fgs_build und ...fgs_install zeigen z.B. mit: 

ln -s /opt/fgs-dev/pkg_def/postgis/fgs_build fgs_build
ln -s /opt/fgs-dev/pkg_def/postgis/fgs_install fgs_install

Diese kann man dann in $FGS_DEV_HOME/src/postgis-1.3.1 ausführen.

Die Module, die in $FGS_DEV_HOME/modules entstehen, kann man dann nach $FGS_HOME entpacken. In unserem Fall habe ich gelernt mindestens postgis und geos. Soweit erstmal das neue Modul.

Um das neue PostGIS Modul nutzen zu können, muss man jetzt leider noch mal die Datenbank neu anlegen. Denn die Funktionen in Postgis zeigen auf die alte Version.


--Markus Hentschel 12:17, 8. Nov 2007 (CET)
Wenn man die Datenbank neu anlegt, kann man ein sogenanntes HARD UPGRADE durchführen und die restore-Funktionalitäten von Postgis verwenden, d.h. es ist keine Einspielung von Erstausstattungen usw. nötig. Siehe dazu z.B. das Postgis Manual.

Zunächst wird ein Dump der kvwmapsp-DB gemacht: 

pg_dump -Fc kvwmapsp > /pfad/zu/kvwmapsp.dump

Dann benennt man die laufende kvwmapsp um. Dazu in der Konsole mit psql in eine Datenbank gehen, die *nicht* kvwmapsp ist. also z.B. 

psql alktemplate;

Jetzt kann man die DB umbenennen, z.B. so: 

ALTER DATABASE kvwmapsp RENAME TO kvwmapsp_sicherung;
(Achtung: Groß- und Kleinschreibung und das Semikolon am Ende beachten!)
(Wenn der Befehl durchgeführt wurde, psql mit "\q" wieder verlassen)

Anschließend kann man mit postgis_restore.pl die Datenbank neu erzeugen. Schematisch sieht der Befehl so aus: 

sh utils/postgis_restore.pl lwpostgis.sql newdb olddb.dump -E <encoding> -O <db-owner> > restore.log
  • utils/postgis_restore.pl: Die Datei liegt in den Quellen, bei mir z.B. in /home/fgs/fgs-dev/src/postgis-1.3.1/utils/
  • lwpostgis.sql liegt in den Quellen, ich habe es in meine fgs-Umgebung kopiert und so liegt es bei mir also in /home/fgs/fgs/apps/pgsql/share/. Wichtig: Sicherstellen, dass in der Datei die Pfade in den Funktionen auf den richtigen Ort zeigen, wo die liblwgeom.so.1.3 liegt!
  • olddb.dump ist der zuvor erzeugte Dump, bei mir also z.B. /home/fgs/fgs/kvwmapsp.dump
  • -E <encoding>: Sollte in unseren Breiten -E LATIN1 sein

Der ganze Befehl heißt dann bei mir beispielsweise: 

sh /home/fgs/fgs-dev/src/postgis-1.3.1/utils/postgis_restore.pl /home/fgs/fgs/apps/pgsql/share/lwpostgis.sql kvwmapsp /home/fgs/fgs/kvwmapsp.dump -E LATIN1 -O xxxx > /home/fgs/fgs/restore.log

Die im Manual angesprochene Prüfung habe ich so durchgeführt: 

grep ^KEEPING /home/fgs/fgs/restore.log | less

und der Inhalt ist bei mir folgender: 

KEEPING FUNCTION: [linefrompoly(geometry)]
KEEPING FUNCTION: [linefrompoly(geometry)]
KEEPING FUNCTION: [linen(geometry, integer)]
KEEPING FUNCTION: [linen(geometry, integer)]
KEEPING FUNCTION: [snapline(geometry, geometry)]
KEEPING FUNCTION: [snapline(geometry, geometry)]
KEEPING CAST bool,text (see CAST)

Jetzt noch die Tabelle spatial_ref_sys aktualisieren, denn die hat ja noch den alten Stand. Dazu mit psql in die kvwmapsp-DB gehen: 

psql kvwmapsp;

und die folgenden Befehle durchführen (Pfad evtl. anpassen): 

delete from spatial_ref_sys;
\i /home/fgs/fgs/apps/pgsql/share/spatial_ref_sys.sql
\q

Nach erfolgreichem Neuaufbau der DB aufräumen nicht vergessen...


Am Ende sollte dann bei SELECT postgis_version(); 1.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1 rauskommen und transform() funktionieren.

Von „https://kvwmap.de/wiki/index.php?title=PostGIS_in_der_fgs-dev_Umgebung_kompilieren&oldid=3656“