HowTo-Liste: Unterschied zwischen den Versionen

Aus kvwmap
Wechseln zu: Navigation, Suche
(→‎Darstellung der Straßennamen im extra layer)
(→‎Darstellung der Straßennamen im extra layer)
Zeile 265: Zeile 265:
  
 
Viele Grüße aus Parchim
 
Viele Grüße aus Parchim
 +
 +
--[[Benutzer:Heinz Schmidt|Heinz Schmidt]] 07:26, 10. Jul 2006 (CEST)<br>
 +
Eine andere Möglichkeit besteht darin in pgAdmin III eine Sicht strassennamen anzulegen und diese als Layer einzubinden.
 +
Hierzu in pgAdmin folgendes Statement ausführen:
 +
 +
CREATE OR REPLACE VIEW strassennamen
 +
AS SELECT t.objnr AS oid, t.objnr AS id, t.label, t.winkel, t.objart, t.folie AS alkfolie,
 +
makeline(t.the_geom, setsrid(makepoint(x(t.the_geom) + cos(t.winkel * pi() / 180::double precision) * 10::double  precision,
 +
y(t.the_geom) + sin(t.winkel * pi() / 180::double precision) * 10::double precision), 2398))
 +
AS the_geom FROM alkobj_t_pkt t
 +
WHERE t.objart >= 5100 AND t.objart <= 5299 AND t.folie::text = '022'::text
 +
UNION SELECT l.objnr AS oid, l.objnr AS id, ''::text || l.label::text AS label, '0' AS winkel,
 +
l.objart, l.folie AS alkfolie, l.the_geom
 +
FROM alkobj_t_lin l
 +
WHERE l.objart >= 5100 AND l.objart <= 5299 AND l.folie::text = '022'::text;
 +
ALTER TABLE strassennamen OWNER TO kvwmap;
 +
 +
Im Feld data der Layertabelle steht dann nur:
 +
 +
the_geom from strassennamen as foo using unique oid using srid=2398
 +
 +
Diese Methode hat bei mir gleich geklappt, im Gegensatz zum oben beschriebenen Verfahren.<br>
 +
Vielen Dank an Hendrik Reissland für den Tip :-)
  
 
== Große WLDGE Dateien einlesen ==
 
== Große WLDGE Dateien einlesen ==

Version vom 10. Juli 2006, 07:26 Uhr

Hinweise und Dokus der Anwender über Daten und Anwendungen (spezeille SQLs, spezielle Snippets, "wie hab ich das gemacht?")



Rahmenlinie in der Referenzkarte beim Druck

--Markus Hentschel 17:13, 29. Jun 2006 (CEST) Wer für den allgemeinen Druck die Referenzkarte im Druckrahmen mit dem Zoom-Parameter "-2" versieht, erhält einen doppelt so großen Ausschnitt wie das eigentliche Kartenbild. Wenn man jetzt ein Rechteck in der Referenzkarte sehen will, das den Kartenbereich anzeigt, dann legt man einen Layer an, der im Referenzkartenmapfile ganz unten stehen muss. So sollte er aussehen: 

LAYER
 NAME "rechteck"
 STATUS DEFAULT
 TYPE LINE
 TRANSFORM FALSE
 FEATURE
   POINTS
     225 200 675 200 675 600 225 600 225 200 # Die Werte
          sind abhängig von der Größe der Referenzkarte!
   END
 END  
 CLASS
   STYLE
     SIZE 3
     COLOR 0 0 0
     OUTLINECOLOR -1 -1 -1
     SYMBOL "punkt"
   END    
 END
END

Wichtig ist, das der TYP LINE ist und der Parameter TRANSFORM auf FALSE steht. Dann wird die Linie, die im FEATURE-Objekt definiert wird, in der Referenzkarte immer an dieselbe Stelle gezeichnet. Die Eckpunkte des Rechtecks, die im Objekt POINTS angegeben werden, müssen auf die Größe der Referenzkarte angepasst werden.

Angenommen, die Referenzkarte hat die Größe 225 x 200 Pixel. Da das Bild für den Druck in der Auflösung verdoppelt wird, vervierfachen sich die Pixelwerte. Fürs Rechnen also im Beispiel 900 x 800 Pixel. Der Rest ist einfach: Das zu zeichnende Rechteck hat oben links einen Abstand von 225 Pixeln zum linken Rand und 200 Pixel zum oberen Rand. Das zu zeichnende Rechteck selbst ist 450 x 400 Pixel groß. Das gilt natürlich immer nur, wenn der Zoomfaktor "-2" ist. Die erste Koordinate ist die linke obere, wobei der Rechtswert zuerst genannt wird. Dann gehts im Uhrzeigersinn weiter.

Problem zur Zeit: Es kann nur eine Refmap angelegt werden. Wer für verschiedene Druckmaßstäbe verschiedene Referenzkartengrößen verwenden will, steht vor einem Problem.

Mehrere Geometrien zu einer zusammenfassen

--Markus Hentschel 12:22, 3. Mai 2006 (CEST) Gefordert wurde, bestimmte Flächen, die geometrisch aneinander angrenzen, als eine Fläche erscheinen zu lassen. Konkret ging es um die farbige Hervorhebung von Flurstücken, die sich in einem Umlegungsverfahren befinden. Hier hilft die Funktion "GeomUnion(geometry)" weiter. Folgendes SQL-Statement verwende ich für die Umlegungsflächen: 

SELECT max(f.objnr) AS oid, max(f.objnr) AS id, geomunion(f.the_geom) AS the_geom
FROM alb_f_verfahren AS s, alkobj_e_fla AS f, alknflst AS fl
WHERE s.ausfstelle LIKE 'U%' AND s.flurstkennz = fl.flurstkennz AND fl.objnr = f.objnr;

Dieses SQL-Statement erzeugt ein Pseudo-Objekt, das aus mehreren Teilflächen besteht. Das lässt sich natürlich schlecht abfragen. Wenn man mehrere Verfahren hat und Queries erlauben will, muss man die SELECT- und die WHERE-Klausel entsprechend verfeinern. Das Ganze ist auch denkbar, um z.B. die Bodenordnungsverfahren (die ja mit ausführender Stelle und Verfahrensnummer im ALB gespeichert sind) als Flächen darzustellen.

--HolgerR 15:11, 4. Jul 2006 (CEST)
Wenn wirklich nur die Fläche als eine zusammenhängen Fläche dargestellt werden soll, ohne dass sie auch zu einer Fläche vereinigt wird, kann man auch ganz einfach die Farbe für die Außenlinie in der Tabelle 'styles' Spalte 'outlinecolor' mit der Farbe in der Spalte 'color' gleich setzen.
Ein kleiner Nachteil ist vielleicht, das keine Außenlinie für Flächen gleicher Farbfüllung dargestellt wird.

Beispiel einer Map-Datei für die Übersichtskarte in der Druckausgabe

--Markus Hentschel 14:33, 11. Mai 2006 (CEST) 
MAP
 IMAGECOLOR 255 255 255
 INTERLACE TRUE
 SIZE 200 200
 EXTENT 4300000 5800000 4700000 6100000 # Anpassen!
 STATUS ON
 TRANSPARENT TRUE
 NAME "ref_kvwmap"
 SYMBOLSET "/www/kvwmap/kvwmap_dev/symbols/symbole.sym" # Pfad anpassen!
 SHAPEPATH "/www/kvwmap/var/data/" # Pfad anpassen!

 OUTPUTFORMAT
   NAME "jpeg"
   MIMETYPE "image/jpeg"
   DRIVER "GD/JPEG"
   EXTENSION "jpg"
   IMAGEMODE "RGB"
   TRANSPARENT FALSE
 END
  
 OUTPUTFORMAT
   NAME "jpeg_print"
   MIMETYPE "image/jpeg"
   DRIVER "GD/JPEG"
   EXTENSION "jpg"
   IMAGEMODE "RGB"
   TRANSPARENT FALSE
   FORMATOPTION "QUALITY=100"
 END

 PROJECTION
   "init=epsg:2398" # EPSG anpassen!
 END
 
 WEB
   IMAGEPATH "/www/kvwmap/tmp/" # Pfad anpassen!
   IMAGEURL "/tmp/"
 END  

 LAYER # zeichnet die Flurgrenzen
   CONNECTION "user=****** password=****** dbname=******" # Anpassen!
   CONNECTIONTYPE POSTGIS
   DATA "the_geom from (select o.the_geom,o.objnr AS oid
                        FROM alkobj_e_fla AS o,alknflur AS fl
                        WHERE o.folie='002' AND o.objnr=fl.objnr)
         as foo using unique oid using srid=2398" # SRID anpassen!
   METADATA
     "wms_name" "Fluren"
     "ows_srs"	 "2398" # EPSG anpassen!
     "ows_title" "Fluren"
   END
   NAME "Fluren"
   PROJECTION
     "init=epsg:2398" # EPSG anpassen!
   END
   STATUS ON
   TYPE LINE
   MINSCALE 100
   CLASS
     STYLE
       COLOR -1 -1 -1
       OUTLINECOLOR 0 0 0
       SIZE 3
       SYMBOL 'punkt'
     END
   END
 END
 LAYER # zeichnet die Beschriftung: Gemarkung + Flurnummer
   CONNECTION "user=****** password=****** dbname=******"
   CONNECTIONTYPE POSTGIS
   DATA "the_geom from (select o.the_geom,o.objnr AS oid,o.objart,fl.flur,g.gemkgname
                        FROM alkobj_e_fla AS o,alknflur AS fl,alb_v_gemarkungen AS g
                        WHERE o.folie='002' AND o.objnr=fl.objnr AND fl.gemkgschl=g.gemkgschl)
         as foo using unique oid using srid=2398" # SRID anpassen!
   METADATA
     "wms_name" "Bezeichnung"
     "ows_srs"	 "2398" # EPSG anpassen!
     "ows_title" "Bezeichnung"
   END
   NAME "Bezeichnung"
   PROJECTION
     "init=epsg:2398" # EPSG anpassen!
   END
   STATUS ON
   TYPE ANNOTATION
   MINSCALE 100
   LABELMINSCALE 100
   LABELMAXSCALE 6000
   SYMBOLSCALE 2000
   CLASS
     TEXT ([gemkgname], Flur [flur])
     LABEL
       COLOR 0 0 0
       OUTLINECOLOR -1 -1 -1
       FONT arial
       TYPE TRUETYPE
       MINSIZE 12
       MAXSIZE 16
       SIZE 14
       PARTIALS TRUE
     END
   END
 END
 
END

Änderungen in der Tabelle Layer für Version 1.5.8

--Heinz Schmidt 15:15, 30. Mär 2006 (CEST)
Die Angaben in der Spalte pfad der Tabelle Layer sehen bei mir beispielsweise so aus:

Layer Flurstuecke 

SELECT o.objnr as oid,o.objart,o.folie,AsText(o.the_geom) AS umring,f.flurstkennz,f.gemkgschl

FROM alkobj_e_fla AS o,alknflst as f
WHERE o.folie='001' AND o.objnr=f.objnr

Layer Gebaeude 

SELECT o.objnr AS oid,o.objart,o.folie,o.objart,h.gemeinde,
       h.strasse,h.hausnr,h.lfdnr,s.strassenname
 ,g.gemeindename
FROM alb_v_gemeinden AS g,alkobj_e_fla AS o,alknhaus as h,alb_v_strassen AS s
WHERE g.gemeinde=h.gemeinde
 AND o.folie='011' AND o.objnr=h.objnr 
      AND h.strasse=s.strasse AND h.gemeinde=s.gemeinde

Layer Nachweise (Risse) 

SELECT *,AsText(the_geom) AS umringtxt FROM n_nachweise WHERE (1=1)

Shapes in die PostGIS mit shp2pgsql

--Markus Hentschel 12:07, 20. Mär 2006 (CET) Beim Einspielen von Shapes in die PostGIS-DB ist es wichtig, die SRID mit anzugeben. Dazu müssen der Parameter "-s" und die entsprechende SRID im Befehl hinzugefügt werden. Beispiel: 

./shp2pgsql  [option]  shapefile.shp  -s <srid>  tabelle  datenbank  >  file.sql
./shp2pgsql -c bplan.shp -s 2398 gd_lk_bplan kvwmapsp145 > reindamit.sql


Baulasten aus dem ALB

  • --Markus Hentschel 07:59, 24. Feb 2006 (CET) Die Baulasten werden im ALB nachrichtlich geführt (Vorsicht ist allerdings wegen Redundanzen geboten!). Damit lassen Sie sich in kvwmap anzeigen. Wir haben das so realisiert, dass im Flurstück ein Punktsymbol erscheint. Dazu wurde in der PostGIS-DB eine Sicht angelegt, die folgende Definition hat: 
SELECT fl.objnr AS oid, fl.objnr AS id, pointonsurface(fl.the_geom) AS the_geom, ab.flurstkennz, ab.blattnr
FROM alb_f_baulasten ab, alknflst f, alkobj_e_fla fl
WHERE fl.folie::text = '001'::text AND ab.flurstkennz::text = f.flurstkennz::text AND f.objnr::text = fl.objnr::text;
"pointonsurface" erzeugt einen Punktort, der garantiert innerhalb der Fläche liegt. Ungelöstes Problem bisher ist, wenn mehrere Baulasten auf einem Flurstück liegen. Dann erscheint mit diesem Statement nur ein Punktsymbol. Schöner wäre natürlich, wenn es dann entsprechend mehrere, verstzte Symbole sind oder wenn im Symbol selber die Anzahl der Baulasten erschiene o.ä.

Variante wenn die Tabelle alb_flurstuecke Koordinaten enthält 

SELECT f.flurstkennz AS oid,
PointFromText('POINT('||f.koorrw||' '||f.koorhw||')') AS the_geom,
f.flurstkennz,b.blattnr
FROM alb_f_baulasten b, alb_flurstuecke AS f
WHERE f.flurstkennz::text = b.flurstkennz::text

Wer keine Koordinaten in der Tabelle alb_flurstuecke hat, weil im ALB eben keine geführt werden, kann sich diese auch über die ALK-Tabelle alkobj_e_fla ausrechnen lassen. Mit folgendem Statement aktualisiert man die Tabelle alb_flurstuecke: 

update alb_flurstuecke set 
koorrw = X(pointonsurface(alkobj_e_fla.the_geom)),
koorhw = Y(pointonsurface(alkobj_e_fla.the_geom))
from alknflst, alkobj_e_fla
where alb_flurstuecke.flurstkennz = alknflst.flurstkennz
AND alknflst.objnr = alkobj_e_fla.objnr

Flurstücke im Eigentum des Landkreises

  • --Markus Hentschel 08:26, 24. Feb 2006 (CET) Wenn man als Layer die Flurstücke dargestellt haben möchte, die im Eigentum des Landkreises sind, dann ist vorab folgendes zu bedenken (das kann natürlich in anderen Kreisen ganz anders sein):
    • Die Suche nach "Landkreis" alleine reicht nicht aus, denn in NVP haben auch andere Landkreise Eigentum
    • Die Suche nur im ersten Namensfeld reicht nicht aus, manchmal steckt der gesuchte String auch im zweiten Namensfeld
    • Die Schreibweisen sind - historisch durch diverse Kreisgebietsreformen bedingt - sehr uneinheitlich, was zudem noch durch die total veraltete händische ALB-Eingabe mit den entsprechenden Fehlermöglichkeiten unterstützt wird. 
SELECT o.objnr::text || b.bezirk::text AS oid, o.objnr::text || b.bezirk::text AS id,
o.the_geom, n.name1::text || n.name2::text AS name, e.bezirk, e.blatt, b.flurstkennz
FROM alb_g_namen n, alb_g_eigentuemer e, alb_g_buchungen b, alknflst f, alkobj_e_fla o
WHERE (
n.name1::text ~~ '%Landkreis Nordvorpommern%'::text OR n.name2::text ~~ '%Landkreis Nordvorpommern%'::text
OR n.name1::text ~~ '%Landkreis Grimmen%'::text
OR n.name1::text ~~ '%Kreis Grimmen%'::text
OR n.name1::text ~~ '%Kreisverwaltung Grimmen%'::text
OR n.name1::text ~~ '%Landkreis Stralsund%'::text
OR n.name1::text ~~ '%Kreis Stralsund%'::text
OR n.name1::text ~~ '%Kreisverwaltung Stralsund%'::text
OR n.name1::text ~~ '%Landkreis Ribnitz%'::text
OR n.name1::text ~~ '%Kreis Ribnitz%'::text
OR n.name1::text ~~ '%Kreisverwaltung Ribnitz%'::text
OR n.name1::text ~~ '%Rat%'::text AND n.name1::text ~~ '%Kreises%'::text
)
AND n.lfd_nr_name = e.lfd_nr_name
AND e.bezirk = b.bezirk AND e.blatt::text = b.blatt::text
AND b.flurstkennz::text = f.flurstkennz::text AND f.objnr::text = o.objnr::text;
So siehts in Nordvorpommern aus und es kann gut sein, dass damit nicht mal alle Schreibweisen abgedeckt sind. Wie gesagt, wird es in anderen Kreisen ähnlich, aber vermutlich doch auch wieder ein bißchen anders sein. Das kann also nicht ohne Anpassung an die eigenen Daten so übernommen werden.


Darstellung der Straßennamen im extra layer

--Boldt 16:48, 13. Mär 2006 (CET)

Wir hatten das Problem der Abfrage in data für den layer Straßennamen, wenn die Namen und die Geometrie aus den Tabellen alkobj_t_pkt und alkobj_t_line herausgenommen werden sollen. Hilfe erhielten wir von Markus und Herrn Korduan, wobei wir hier die Information von Herrn Korduan mal an Allle weitergeben möchten. Herr Korduan hat ein SQL-Statement geschrieben, welches ermöglicht, in einen Layer die Straßennamen aus zwei unterschiedlichen Geometrietabellen (Punkt und Linie) darzustellen.

Prinzipiell kann MapServer in einem Layer nur eine Art von Geometrie anzeigen. Aber Dank PostGIS können wir da was machen. Hier ein Statement, mit dem aus der Punktgeometrie eine Liniengeometrie gemacht wird. Das Statement haben wir in Data zu unserem layer Straßenname geschrieben. Es entstehen Linien der Länge 10m mit der Richtung von winkel. 

the_geom FROM (SELECT t.objnr AS oid,t.label AS label,t.winkel AS winkel,
                      t.objart AS objart,t.folie AS alkfolie,
                      MakeLine (t.the_geom,SetSRID(MakePoint(X(t.the_geom)+(cos(t.winkel*PI()/180)*10),
                                                             Y(t.the_geom)+(sin(t.winkel*PI()/180)*10)),2398))
                      AS the_geom 
               FROM alkobj_t_pkt AS t
               WHERE t.objart >= 5100 and t.objart <= 5299 AND t.folie = '022'
               UNION SELECT l.objnr AS oid,l.label AS label,
                            '0' AS winkel,l.objart AS objart,l.folie AS alkfolie,
                            l.the_geom AS the_geom FROM alkobj_t_lin AS l 
               WHERE l.objart >= 5100 and l.objart <= 5299 AND l.folie = '022')
                     as foo using unique oid using srid=2398

Wobei man das ganze Where auch weglassen kann und in class packen kann. Je nach dem ob man die Beschriftung der Gebäude und Strassen in einem Layer anzeigen will oder verschiedenen. Das Weglassen der Where Klausel kann aber den Bildaufbau wesentlich verzögern, weil die Abfrage länger dauert.

Zum Ausrichten der Texte muss man nun nicht mehr lableangleitem = winkel verwenden, sondern in der Tabelle labels: angle=AUTO und autoangle=1 einstellen. Das bewirkt die Ausrichtung des Textes an der Linie. Der Layer muss dann auch vom Type Line sein also in tabelle Layer Datentype=1. Passen Sie auch den Style des Layers neu an.

Die Class Expression für den layer Straßenname lautet: 

('[objart]' >= '5100' AND '[objart]' <= '5299' AND '[alkfolie]' eq '022')

Bei uns funktioniert das jetzt wunderbar.

Viele Grüße aus Parchim

--Heinz Schmidt 07:26, 10. Jul 2006 (CEST)
Eine andere Möglichkeit besteht darin in pgAdmin III eine Sicht strassennamen anzulegen und diese als Layer einzubinden. Hierzu in pgAdmin folgendes Statement ausführen: 

CREATE OR REPLACE VIEW strassennamen 
AS SELECT t.objnr AS oid, t.objnr AS id, t.label, t.winkel, t.objart, t.folie AS alkfolie, 
makeline(t.the_geom, setsrid(makepoint(x(t.the_geom) + cos(t.winkel * pi() / 180::double precision) * 10::double  precision,
y(t.the_geom) + sin(t.winkel * pi() / 180::double precision) * 10::double precision), 2398)) 
AS the_geom FROM alkobj_t_pkt t
WHERE t.objart >= 5100 AND t.objart <= 5299 AND t.folie::text = '022'::text
UNION SELECT l.objnr AS oid, l.objnr AS id, ::text || l.label::text AS label, '0' AS winkel, 
l.objart, l.folie AS alkfolie, l.the_geom
FROM alkobj_t_lin l
WHERE l.objart >= 5100 AND l.objart <= 5299 AND l.folie::text = '022'::text;
ALTER TABLE strassennamen OWNER TO kvwmap;

Im Feld data der Layertabelle steht dann nur: 

the_geom from strassennamen as foo using unique oid using srid=2398

Diese Methode hat bei mir gleich geklappt, im Gegensatz zum oben beschriebenen Verfahren.
Vielen Dank an Hendrik Reissland für den Tip :-)

Große WLDGE Dateien einlesen

--Pkorduan 16:57, 21. Apr 2006 (CEST)

Liebe kvwmap-Nutzer,

es gab in der Vergangenheit einige Performanceprobleme beim Einlesen der ALB-Grunddatenbestände in die Postgres-Datenbank. Es gibt zwar Optimierungsmöglichkeiten, die größte dürfte das Schreiben in Textdateien sein und dann das Einlesen nicht über einzelne INSERTS sondern über COPY, das ist aber vom Programmiertechnischen her und vom Aufbau der ALB nur mir großem Aufwand möglich. Das heißt es dauert eben seine Zeit. Problem ist aus meiner Sicht, dass das Ganze dann immer über einen http-Request läuft. Ich schlage daher für alle, bei denen es noch nicht geklapt hat den ALB-Grundbestand einzulesen, vor die Konstante DBWRITE in der config.php auf 0 zu setzen. 

define('DBWRITE',1);  ->  define('DBWRITE',0);

Dann den Einlesevorgang zu starten und nach erfolgter Fertig-Meldung den Dump in die Datenbank einzulesen. Hierbei reduziert sich der Aufwand auf dem Server auf das Schreiben der log-Datei und dieser ist linear, der Zeitverbrauch nimmt also nicht zu je mehr Daten schon in der Datenbank sind, weil ja keine mehr eingelesen werden. 

z.B. WLDGE_Dump_postgresql_20060116165634.sql

Diese Datei kann man dann anschließend vom Terminal aus starten und zwar mit dem Terminal Client psql. Der Aufruf sieht in etwa so aus: 

/usr/local/bin/psql -U kvwmap -f /www/kvwmap/logs/WLDGE_Dump_postgresql_20060116165634.sql kvwmapsp145

Vergewissern Sie sich jedoch vorher ob Ihr Programm psql auch unter /usr/local/bin steht. Bei einigen steht es auch unter /usr/local/pgsql/bin oder so. Hinter –U steht der Benutzer, der in die Datenbank, die ganz hinten steht schreiben darf. Nun, hier könnte also ein Prozess im Hintergrund laufen, der dann auch ein bischen länger dauern darf, ohne, dass der Web-Server warten muss oder ein php-Skript ausgeführt werden muss. Soviel zu Alternativen zum Einlesen großer WLDGE-Dateien. Noch ein Hinweis. Bei allen wo es noch zu Fehlern beim Einlesen in die postgres kommt, bitte prüfen ob die Tabellen alb_flurstuecke und alb_x_flurstuecke identische sind. Auch der Datentyp von koordrw und koordhw.


Automatisierte Fortführung des ALB

ich schlage ich folgenden Weg vor:

1. Es wird ein Cron-Job erstellt, der regelmäßig eine Skriptdatei auf der Komandoebene des Betriebssystems ausführt. Im Beispiel ist ff.wldge die Fortführungsdatei, nach der gesucht werden soll. Die Datei muss mit komplettem absolutem Pfad angegeben werden. 

/DeinBinVerzeichnis/wldge_update /Verzeichnis_in_dem_gesucht_werden_soll/ff.wldge

2. Die Skriptdatei prüft ob in einem gegebenen Verzeichnis eine Datei angekommen ist. Wenn ja, dann wird diese mit dem wldge2sql Konverter eingelesen, wenn nicht passiert garnichts.

3. Das Einlesen kann durch einen URL-Aufruf z.B. mit lynx unter Angabe des Host, des Anwendungsfalles zum Aktualisieren des ALB und des Dateinamens erfolgen,jedoch wäre dann immer der lynx Prozess hinterher wieder abzuschließen. Deshalb ist es wohl besser das Command Line Interface (CLI) von php zu benutzen, um die php-Datei zur ALB-Fortführung auszuführen. Der Vorteil ist, daß die Ausgaben direkt in eine Protokolldatei umgeleitet werden können. Voraussetzung dafür ist, daß php mit CLI Unterstützung kompiliert wurde. Seit PHP 4.3.0 ist die Option --enable-cli standardmäßig auf on gestellt, also sollte es funktionieren. Das php-Binary für CLI Aufrufe liegt im Installationsverzeichnis von php unter sapi/cli. Diese Binary muss man ausführen. Siehe auch www.php.net manual Kapitel 43. Das Skript kann ungefähr so aussehen: 

#! /bin/bash
if ls $1
 then 
  date >alb_update_log
  /phpinstallpath/sapi/cli/php /[wwwroot]/wldge2sql/index.php
  ALB_Aenderung 1 1 $1 >alb_update_log
fi

4. wwwroot ist das Verzeichnis in dem der wldge2sql-Konverter installiert ist. Hinter index.php kommen die Argumente, die an das php Skript übergeben werden sollen. Das sind die Werte, die sonst über das Formular wldgedateiauswahl.php übergeben werden. Damit index.php die Argumente auch auswerten kann ist in der Datei start.php folgende Zuweisung eingefügt worden. 

if ($argc 0) {
  $arg['go']=$argv[1];
  $arg['ist_Fortfuehrung']=$argv[2];
  $arg['WLDGE_lokal']=$argv[3];
  $arg['WLDGE_Datei_lokal']=$argv[4];
  $GUI->formvars=$arg;
}
else {
  $GUI->formvars=$_REQUEST;
}

Wenn index.php also über CLI aufgerufen wird mit Argumenten ist argc größer 0 und die Argumente kommen von $argv, sonst von $_REQUEST;

5. Vor der Ausgabe der eigentlichen HTML-Seite liefert der Konverter Meldungen vom Einlesen der WLDGE-Datei. Danach kommt die Ausgabe der eigentlichen HTML-Seite. Um nur die Vorabausgaben des Konverters in die log-Datei zu übernehmen, muss der entsprechende Befehl zur Ausgabe der Seite auskommentiert werden. In der Datei index.php ist das $GUI->ouput();

Ich habe es getestet. Es funzt.

Gruß Peter

Von „https://kvwmap.de/wiki/index.php?title=HowTo-Liste&oldid=1991“