Inhaltsverzeichnis

1 Übersicht
2 kvwmap mobil
3 Installation
4 Administration
5 Benutzung von kvwmap
6 Weitere Hilfe

Übersicht

kvwmap setzt unter anderem auf Apache, UMN-MapServer, php-Mapscript, MySQL, Postgres mit PostGIS und EDBS2WKT auf und beinhaltet WLDGE2SQL.
Dank an dieser Stelle für die Bereitstellung der genannten Software.

Dieses Manual wurde erstellt unter Mitwirkung von

Peter Korduan, Stefan Rahn, Markus Hentschel, Hauke Christoph, Heinz Schmidt

An der Entwicklung von kvwmap waren und/oder sind bisher beteiligt:

Peter Korduan, Stefan Rahn, Hauke Christoph, Conrad Gühler, Swen Hüner, Markus Hentschel, Holger Riedel, Heinz Schmidt

Vielen Dank auch für die Zuarbeiten und Hinweise aus den Katasterämtern der Landkreise Rostock, Vorpommern-Rügen, Vorpommern-Greifswald, Mecklenburgische Seenplatte, Ludwigslust-Parchim und die Landeshauptstadt Schwerin.

Dienstleistungen zu kvwmap werden angeboten von:

GDI-Service Rostock

Prof. Ralf Bill, Uni Rostock

Status des kvwmap-WIKIs: in Work!!

Die Dokumentation erhebt keinen Anspruch auf Vollständigkeit. Sie wird sowohl von den Entwicklern als auch von den Anwendern aktualisiert und laufend gehalten. Dennoch kann es vorkommen, dass bestimmte Inhalte nicht immer ganz zur aktuellsten Version passen. Als registrierter Teilnehmer dieses WIKIs können Sie Fehler selbst beheben und die Dokumentation auf dem aktuellsten Stand halten. Wenn Sie nicht registriert sind, sind Zuarbeiten, Hinweise und Korrekturvorschläge selbstverständlich genauso herzlich willkommen. Schreiben Sie an die o.g. Personen, die auch in der Teilnehmerliste auftauchen.

Die Dokumentation wird in der jeweils aktuellen Version jedem neuen Versionspaket von kvwmap im Unterordner help hinzugefügt. Für die Richtigkeit und Vollständigkeit der folgenden Angaben wird keine Garantie übernommen.

Hintergründe für die Entwicklung

Kvwmap ist eine auf den UMN-MapServer aufsetzende Entwicklung zur Erfassung, Verarbeitung, Analyse und Präsentation von raumbezogenen Information. Die Entwicklung besteht aus einer Reihe von PHP-Skripten, einem Schema für eine MySQL-Datenbank zur Speicherung von Benutzerdaten und einem Schema für eine PostgreSQL-Datenbank mit PostGIS Aufsatz zur Speicherung von raumbezogenen Daten. Die Anwendung nutzt PHP-MapScript für den Zugriff auf die Funktionen des UMN-MapServers und die pdf class von R&OS zur Erzeugung von PDF-Dokumenten.

Funktionalität im Client

Folgende Funktionalitäten werden von dem Client bereitgestellt:

Navigation

Navigationsleiste des SVG-Clients

Vorheriger Ausschnitt (History-Funktion)

Nächsten Ausschnitt (History-Funktion)

Zoom in (durch Aufziehen einer Box)

Zoom in (durch Klicken i. d. Karte bei wählbarem Zoomfaktor)

Zoom out (durch Klicken i. d. Karte bei wählbarem Zoomfaktor)

Pan (durch Ziehen des Bildschirmausschnittes an eine neue Stelle)

Zentrieren (der zu klickende Punkt wird in Kartenmitte versetzt)

Eingabe eines konkreten Koordinatenpaars ('Koordinatenzoom')

Eingabe eines konkreten Maßstabs
Tool-Tipps einblenden
Mausrad-Zoom
- Rad Richtung Bildschirm drehen zum Reinzoomen
- Rad vom Bildschirm weg drehen zum Rauszoomen

Schnellsprung-Zoom, zum schnellen Zoom auf z.B. Gemeinde, Amt, usw.
- Über die Konstante LAYER_ID_SCHNELLSPRUNG in der config.php kann ein beliebiger Polygonlayer dafür verwendet werden
- Der Layer muss die "oid" der Tabelle abfragen
- Das Attribut "oid" muss im Attributeditor als Auswahlfeld mit z.B. folgendem SQL: "select oid as value, name as output from gemeinden order by name" definiert sein

Legendenfunktionen

Gruppierung der Layer
- Anzeige der Gruppennamen
- Zuordnung der Layer zu den Gruppen
- Auf- und Zuklappen der Legende einzelner Gruppen (| vom Gruppennamen)
- Gleichzeitiges De- oder Aktivieren aller Layer der Gruppe für die Informationsabfrage
- Gleichzeitiges Ein- oder Ausschalten der Sichtbarkeit aller Layer der Gruppe

Layer
- Ein- und Ausschalten des Layers für die Anzeige
- Ein- und Ausschalten des Layers für die Sachdatenabfrage
- Zoom auf die maximale Ausdehnung des Layers ( hinter dem Layernamen, geht derzeit nur für aktuell eingeblendete PostGIS Layer)
- Ein- und Ausschalten der Klassen des Layers (| hinter dem Layernamen)
- Ausschalten aller Layer für die Anzeige und Abfrage (Symbole ganz oben in der Legende). Letzters ist auch möglich über die go-Variablen "go=reset_layers" bzw. "go=reset_querys"

Abfragen

Das Abfrageergebnis wird in einem eigenen Fenster angezeigt. Spaltenbezeichnungen und Layouteinstellungen können in Vorlagen angepasst werden

Auswahl der abfragbaren Layer in Legende
Anklicken eines entsprechenden Objekts
Aufziehen einer Box um betreffende Objekte
Abfrage eines Objektes und aller angrenzenden Objekte
Klick in die Karte und Angabe eines Abfrageradius'
Zeichnen eines Abfragepolygons
Koordinatenabfrage
Abfrage der ALB-Daten beim Flurstückslayer, Ausgabe in PDF im amtlichen Format 20, 25, 30, 35 und 40

Suche

Alle Suchfunktionen funktionieren natürlich nur, wenn die entsprechenden Daten in kvwmap eingebunden sind und auch in der Stelle in der die Suche stattfinden soll verfügbar sind.

Flurstücke (Gemeinde-Gemarkung/Flur/Flurstück)
Adressen (Gemeinde/Strasse/Hausnummer)
Grundbuchblätter (Grundbuchbezirksschlüssel/Grundbuchbezirk-Auswahl/Grundbuchblatt)
Namen (Name, Vorname Geburtsname/Firma/geboren am/Firmenzusatz/Strasse Hausnummer/PLZ Ort/Grundbuchbezirk/Grundbuchblatt/Gemarkung, Gemeinde - Auswahl)
Festpunkte (Kilometerquadrat/Punktkennzeichen)

Zur nicht exakten Suche im Punktkennzeichen geben Sie den Platzhalter % ein. z.B. erhalten Sie alle AP´s aus Kilometerquadrat 45601234 mit der Eingabe 45601234-1-%

Jagdbezirke (laufende Nummer/Name/Art)
Metadaten (Was/Wer/Wann/Wo - Suchfenster in Karte oder mit Koordinaten)

Layer (Layername/zum Layer gehörende Attribute)

Mit der Layersuche lassen sich sowohl PostGIS-Layer als auch WFS-Layer durchsuchen. Die Suchfunktion ist generisch. Das heißt, das Suchfenster wird für die jeweiligen zu durchsuchenden Layer automatisch an Hand der vordefinierten Attribute bereitgestellt. Bei WFS-Layern stehen alle Sachattribute, die der WFS anbietet für die Suche zur Verfügung. Bei PostGIS-Layern können die Attribute durchsucht werden, für die der Nutzer mindestens Leserecht hat.

Messen

Koordinaten bestimmen
Streckenmessungen
Flächenmessungen

Redlining

Freihandpolygon zeichnen
Text hinzufügen
Pfeil hinzufügen

Der Generische Layereditor GLE

Der generische Layereditor (GLE) stellt zur Laufzeit Oberflächen zur Verfügung, die dynamisch ("generisch") aus den rollenbasierten Nutzerrechten und der layerbasierten Definition erzeugt werden. Diese Oberflächen stehen teilweise nur den Administratoren, teilweise aber auch den Nutzern von kvwmap zur Verfügung:

Sachdatensuche (go=Layer-Suche)
Sachdatenanzeige und -bearbeitung
Erfassung neuer Datensätze
Sachdatendruckeditor
Filterverwaltung
Layerattribut-Definition
Layerattribut-Rechteverwaltung

In der Sachdatensuche stellt der GLE die Attribute zusammen, die dem Nutzer in dieser Stelle angezeigt werden. In den Attributen kann dieser dann mit Hilfe von verschiedenen Operatoren umfangreich recherchieren. Die Sachdatensuche kann räumlich eingeschränkt werden, dazu ist der Geometrie-Editor zur Erstellung eines Polygons in die Oberfläche integriert.

In der Sachdatenanzeige (die Ergebnis einer Sachdatensuche oder einer Infoabfrage aus der Karte heraus sein kann) werden die Attribute angezeigt, die dem Nutzer in dieser Stelle per Rechtedefinition zur Verfügung stehen. Hier ist es dem Nutzer möglich, die Attribute von Postgis-Layern zu bearbeiten - wenn er das Recht dazu hat. Ein Link ermöglicht die Bearbeitung der Geometrie im Geometrie-Editor. Um Sach- oder Geometriedaten zu verändern, muß das entsprechende Recht in der Layerattribut-Rechteverwaltung gesetzt sein.

Wie die Sachdatenanzeige aussieht, wird durch das stellenbezogene Feld "Template" bestimmt. Es gibt derzeit 3 verschiedene Varianten:

Standardvariante: Datensätze und Attribute untereinander: Die standardmäßige Darstellungsvariante des GLE (Feld Template ist leer) sieht so aus, dass die Datensätze untereinander und in jedem Datensatz auch die Attribute untereinander angezeigt werden. Diese Variante eignet sich für die meisten Layer, da es durch die Untereinanderanordnung keine Einschränkung in der Attributanzahl gibt.

Listenförmige Variante: Attribute spaltenweise: Hat ein Layer nur wenige Attribute und Abfragen auf diesen Layern liefern aber meist sehr viele Datensätze, eignet sich evt. die listenförmige Darstellung (Feld Template="generic_layer_editor.php"). Hier werden die Attribute spaltenweise nebeneinander und die Datensätze zeilenweise angezeigt.

Rasterförmige Variante: Diese Darstellungsvariante ("Raster" meint eher "Schachbrett") eignet sich besonders für Dokumente (Feld Template="generic_layer_editor_doc_raster.php"). Damit werden die Datensätze rasterförmig neben- und untereinander angezeigt, wobei in jedem Datensatz nur bestimmte Attribute sichtbar sind. Erst wenn man die Maus über einen Datensatz bewegt, werden die restlichen Attribute eingeblendet. Im Attributeditor kann man einstellen, welche Attribute sichtbar sein sollen. Mit dieser Variante lässt sich so z.B. eine schnelle Bildsuche realisieren.

Für die Erfassung von neuen Datensätzen stellt der GLE eine eigene Oberfläche zur Verfügung, in der die Attribute des Layers angezeigt werden, die dem Nutzer in dieser Stelle per Rechtedefinition zur Verfügung stehen. Auch hier kann der Nutzer nur die Attribute bearbeiten, für die er das Recht dazu hat. Der Geometrie-Editor zur Erfassung der Geometrie ist in die Oberfläche integriert.

Damit ein Postgis-Layer mit dem generischen Layereditor bearbeitet werden kann, müssen folgende Voraussetzungen geschaffen sein:

In der sog. "Query" der Layerdefinition muss eine SQL-Abfrage formuliert werden, die die Attribute des Layers sammelt, die in der Fachdatenanzeige eine Rolle spielen sollen.
Die sog. "Haupttabelle" muss oids besitzen (wichtig nur bei einer Layerdefinition über mehrere Tabellen hinweg)
Dem Layer darf in der jeweiligen Stelle kein Template zugeordnet sein

Über den Template-Eintrag lässt sich also steuern, ob für einen Layer der generische Layereditor oder ein Snippet zur Sachdatenanzeige verwendet werden soll.

Es werden sowohl Punkt-, Linien-, als auch Polygon-Layer unterstützt. Bei den Polygon- und Linienlayern ist darauf zu achten, daß das enforce_geotype constraint die Geometrietypen 'POLYGON' und 'MULTIPOLYGON' bzw. 'LINESTRING' und 'MULTILINESTRING' unterstützt. Damit lassen sich sowohl einfache Polygone und Linenzüge, als auch Multipolygone und Multilinienzüge zeichnen und abspeichern.

Bei der Speicherung der Layerdefinition holt der GLE eine Reihe von Datenbankmerkmalen der jeweiligen Attribute aus der Postgis-DB und verwendet diese in den verschiedenen GLE-Oberflächen (z.B. Constraints, NOT NULL, Defaults etc.).

Die Layerattribut-Rechteverwaltung des generischen Layereditors

Mit dem generischen Layereditor (GLE) ist es möglich, die Daten von Postgis-Layern zu verändern. Damit nicht jeder beliebige Nutzer Daten ändert, gibt es ein Rechtesystem, welches jeder Stelle Privilegien zuordnet, die den Zugriff auf die Attribute eines Layers regeln. Die Layerattribut-Rechteverwaltung wird über die go-Variable Layerattribut-Rechteverwaltung aufgerufen. Zunächst wählt man den gewünschten Layer aus. Jeder Layer hat sog. Default-Rechte, die den "Standardzugriff" auf die Attribute definieren. Diese werden links angezeigt und daneben alle Rechte der Stellen, die diesem Layer zugeordet sind.

Die globalen Layerzugriffsrechte bestimmen, ob die Nutzer einer Stelle in einem Layer nur lesen bzw. editieren dürfen, ob sie zusätzlich neue Datensätze erzeugen dürfen oder darüber hinaus Datensätze außer erzeugen auch löschen dürfen. Die Default-Rechte listen alle Attribute des Layers untereinander auf. Diese Liste von Attributen ergibt sich aus dem Query-Statement des Layers. Jedem Attribut ist ein Privileg zugeordnet. Zur Auswahl stehen nicht sichtbar, lesen und editieren. Standardmäßig sind alle Attribute eines Layers nur lesbar. In der jeweiligen Stelle, der der Layer zugeordnet ist, können entweder die Default-Rechte verwendet oder (i.d.R. bei der Stelle des "Datenherrns") individuelle Rechte vergeben werden.

Bearbeitung von Sachdaten

Um die Sachdaten eines Layers mit dem GLE zu bearbeiten, muss der entsprechende Datensatz (oder die Datensätze) ausgewählt werden. Das kann durch eine Sachdatensuche mittels GLE oder durch eine Info-Abfrage auf das Objekt in der Karte erfolgen. Der GLE erzeugt an Hand der im Query-Statement des Layers vorkommenden Attribute und den entsprechenden Rechten dieser Stelle ein Layereditor-Formular. Der Datensatz wird so angezeigt, dass die Attribute zeilenweise untereinander stehen. In den Attributen, für die das Recht 'editieren' gesetzt ist, können die vorhandenen Einträge geändert oder neu eingetragen werden. Je nach Formularelementtyp des Attributs können verschiedene Möglichkeiten zur Verfügung stehen: einzeilige oder mehrzeilige Textfelder, Auswahlfelder, Checkboxen etc. Mit dem Klick auf 'speichern' werden die geänderten Datensätze in die entsprechende(n) Tabelle(n) geschrieben.

Formularelementtypen und Formularelementfestlegungen

Die Formularfelder des Generischen Layereditors können verschiedene Typen haben. Um einem Attribut manuell einen Formlartyp zuzuweisen, gibt es den Attributeditor. Dieser läßt sich im Layer-Editor (nicht mit dem GLE verwechseln) über den Button 'erweiterte Einstellungen' oder über 'go=Attributeditor' aufrufen. Der Attributeditor zeigt alle Attribute des Layers an.

Beim Speichern einer Layerdefinition werden NOT NULL Angaben eines Attributs gespeichert. Im GLE erscheint hinter dem Attributnamen ein Sternchen (*), das dem Nutzer signalisiert, dass hier eine Eingabe oder Auswahl Pflicht ist.

Beim Speichern einer Layerdefinition werden DEFAULT Angaben eines Attributs gespeichert. Im GLE erscheint beim Anlegen eines neuen Datensatzes im Wertfeld ddieser Default. Bei Auswahlfeldern ist die entsprechende Option bereits ausgewählt etc.

Beim Speichern einer Layerdefinition werden CONSTRAINT Angaben eines Attributs gespeichert. Im GLE erscheinen Fehlermeldungen, wenn der Nutzer versucht, etwas anderes einzutragen bzw. auszuwählen.

Beim Speichern einer Layerdefinition werden Angaben zum Datentyp eines Attributs gespeichert. Im GLE erscheinen Fehlermeldungen, wenn der Nutzer etwas einzutragen versucht, was dem Datentyp widerspricht (z.B. Buchstaben in Integer-Attributen).

Folgende Formularelementtypen stehen zur Auswahl:

Text

Im generischen Layereditor erscheint ein einzeiliges Eingabefeld.

Gibt es in einer Postgis-Tabelle zu dem entsprechenden Attribut ein check-Constraint, das die möglichen Eingabewerte einschränkt, wie z.B.

CONSTRAINT art CHECK (art::text = 'gjb'::text OR art::text = 'ejb'::text OR art::text = 'tjb'::text)

so ist das Formularfeld dieses Attributes vom Typ Auswahlfeld. Im GLE erscheint ein Auswahlfeld mit den durch das Constraint vorgegebenen Werten als Auswahlmöglichkeiten.

Es gibt die Möglichkeit den Wert des Textfelds automatisch generieren zu lassen. Im Optionenfeld kann man ein beliebiges SQl definieren, welches auch dynamisch sein kann, indem die Werte der anderen Attribute über $<attributename> einbezogen werden können. Hat ein Textfeld einen Eintrag im Optionenfeld, erscheint neben dem Attribut ein Button "automatisch generieren", der den neuen Wert entsprechend des SQL-Statements berechnet.

Beispiel: Man hat einen Layer Rechnungen und will für das Attribut Rechnungsnummer den Wert generieren lassen. Die Rechnungsnummer hat folgende Form: <Jahr>-<KundenNr>-<laufendeNummer>. Eine neue Rechnungsnummer soll sich also aus dem aktuellen Jahr, der Kundennummer des aktuellen Auftrags und der um 1 erhöhten laufenden Nummer der letzten Rechnungsnummer des Kunden ergeben.

Im Optionenfeld definiert man dazu folgendes SQL:

SELECT substr(EXTRACT(YEAR FROM CURRENT_DATE)::text, 3) ||'-'|| substr(r.rechnungsnummer, 4, 4) || lpad((substr(r.rechnungsnummer, 8, 3)::integer + 1)::text, 3, '0')
FROM buchung.rechnungen as r, buchung.auftraege as a 
WHERE substr(r.rechnungsnummer, 4, 3) = lpad(a.kunde_id::text, 3, '0') 
AND a.auftrag_id = $auftrag_id
ORDER BY rechnungsnummer DESC limit 1

Textfeld

Im generischen Layereditor erscheint ein mehrzeiliges Eingabefeld.

Auswahlfeld

Im generischen Layereditor erscheint ein Auswahlfeld. Die Auswahlmöglichkeiten lassen im Feld Optionen festlegen. Dabei wird dieselbe Syntax verwendet, wie bei Definition einer enum-spalte in MySQL (die Werte dürfen kein Komma enthalten). Also

'Wert1','Wert2','Wert3'

Alternativ kann man die möglichen Werte auch aus einer Tabelle auslesen lassen. Dafür muß man im Optionen-Feld das SQL-Statement angeben. Das Statement hat dabei folgende Form:

select <Ausgabespalte> as output, <Schlüsselspalte> as value from <Tabellenname>

Beispiel: Man hat eine Tabelle "projekte", mit den Spalten "projektnr" und "projektname". Im Auswahlfeld sollen nun die Projektnamen aufgelistet werden. Wählt man einen der Projektnamen aus, soll nach Absenden des Formulars die zugehörige Projektnummer übergeben werden. Dazu muß das SQL-Statement folgendermaßen aussehen:

select projektname as output, projektnr as value from projekte

Um doppelte Nennungen zu vermeiden, verwendet man noch ein "distinct":

 select distinct <Ausgabespalte> as output, <Schlüsselspalte> as value from <Tabellenname>

Eine alphabetische Sortierung der Werte (hier Projektnamen) erhält man durch ein angehängtes ORDER BY output

 select <Ausgabespalte> as output, <Schlüsselspalte> as value from <Tabellenname> ORDER BY output

Man muss auch nicht unbedingt eine Tabelle anlegen. Sollen z.B. als Werte 0 oder 1 gespeichert werden und im Auswahlfeld "nein" oder "ja" angezeigt werden kann man folgendes SQL-Statement verwenden:

select 0 as value, 'nein' as output UNION select 1 as value, 'ja' as output

(Achtung: Hier wird nach value sortiert!)

Verknüpfungen von Layern

Wenn es einen Layer gibt, der den Daten im Auswahlfeld entspricht, hat man die Möglichkeit, beide Layer zu verknüpfen. Dazu werden im Optionenfeld nach dem SQL weitere Optionen angehängt. Diese werden mit einem ";" eingeleitet. Durch die Angabe von "layer_id=???" wird der zweite Layer definiert. Im Beispiel könnte das z.B. so aussehen:

select projektname as output, projektnr as value from projekte;layer_id=12

Im GLE erscheint dadurch, wenn das entsprechende Recht gesetzt ist, hinter dem Auswahlfeld ein Link "neu". Dieser öffnet ein neues Fenster und führt direkt zur Erfassung eines neuen Datensatzes des zweiten Layers (im Beispiel ein neues Projekt). Weiterhin hat man die Möglichkeit, die Erfassung des neuen Datensatzes auch ohne ein neues Fenster zu öffnen direkt im Hauptformular durchzuführen. Dazu fügt man im Optionenfeld die Option "embedded" hinzu (durch ein Leerzeichen getrennt). Im Beispiel also so:

select projektname as output, projektnr as value from projekte;layer_id=12 embedded

Dadurch erscheint mit dem Klick auf "neu" das Formular zur Erfassung des neuen Datensatzes direkt unter dem Auswahlfeld. Man kann nun den neuen Datensatz erzeugen und nach dem Klick auf Speichern schließt sich das eingebettete Formular und der neue Datensatz wird den Auswahlmöglichkeiten des Auswahlfeldes hinzugefügt und selektiert. Diese Variante der Layerverknüpfung entspricht einer n:1 Beziehung und ist eine Alternative zu "SubformFK".

Attributabhängige Auswahllisten

Es ist außerdem möglich attributabhängige Auswahllisten zu definieren. Hier ein Beispiel: Es gibt ein Attribut flur, welches von einem Attribut gemkg abhängig sein soll. Das Feld Optionen des Attributs flur muss z.B. folgendermaßen aussehen:

select flur as value, flur as output from alknflur as f WHERE f.gemkgschl = <requires>gemkg</requires>

Dieses Attribut liefert eine Liste aller Fluren einer bestimmten Gemarkung.

Das Attribut gemkg, welches die Gemarkungen auflistet, hat z.B. folgendes Optionen-Feld:

select gemkgschl as value, gemkgname as output from alb_v_gemarkungen <required by>flur</required by>

Sortierungen mit "ORDER BY" am Ende sind möglich: Bei <requires>...</requires> dahinter, bei <required by>...</required by> davor.

Dabei ist darauf zu achten, dass das abhängige Attribut immer nach dem anderen im Query-Statement aufgezählt wird (hier: flur nach gemkg). Also in der logischen Reihenfolge, in der man auch beide Auswahlfelder im GLE nacheinander auswählen würde. Die Anzahl der abhängigen Attribute ist jedoch nicht auf ein Attribut beschränkt, so dass sich auch mehrere abhängige Attribute, durch Komma getrennt, definieren lassen.

Beispiel:

 select gemkgschl as value, gemkgname as output from alb_v_gemarkungen <required by>flur,gemeinde</required by>

Das abhängige Attribut muss nicht unbedingt ein Auswahlfeld sein. Es kann auch vom Typ Text sein. Dann wird es nur mit dem ersten Datensatz, die die SQL-Abfrage zurückliefert befüllt.

Auch das übergeordnete Attribut muss nicht unbedingt ein Auswahlfeld sein. Es kann ebenfalls vom Typ Text sein (das abhängige muss dann aber zwingend ein Auswahlfeld sein). Es ist nur darauf zu achten, dass im übergeordneten der richtige (richtig geschriebene) Wert drin steht.

--Markus Hentschel 13:24, 5. Mär 2009 (CET) Das "flur" in "...<required by>flur</required by>" ist der Name des Attributs, nicht das "flur" aus "select flur as value..." weiter oben.

SubformPK

Mit diesem Formularelementtyp lassen sich 2 Layer miteinander verknüpfen. Der Benutzer kann in kvwmap über einen Link, der in einem Layer erscheint, direkt in einen zweiten Layer "springen", der Daten enthält, die in Abhängigkeit zum ersten Layer stehen. Das "PK" steht für Primärschlüssel und damit für die Art der Verknüpfung.

Beispiel: Man hat einen ersten Layer 'Verpachtungen' und einen zweiten Layer 'verpachtete Flurstücke'. Beide Layer bilden eine 1:n Beziehung, d.h. eine Verpachtung kann mehrere Flurstücke haben, ein verpachtetes Flurstück ist aber immer genau einer Verpachtung zugeordnet.

Ein eindeutiger Identifikator des ersten Layers, meistens gleichzeitig der Primärschlüssel auf Datenbankebene, wird als sog. "Verknüpfungsattribut" verwendet.

Beispiel: Der Primärschlüssel der Verpachtungen sei hier 'lfdnr'. Im zweiten Layer 'verpachtete Flurstücke' gibt es ebenfalls ein Attribut 'lfdnr', darüber sind beide Layer verknüpft. Weiß man die lfdnr einer Verpachtung, kann man auch alle zugehörigen Flurstücke abfragen.

Um 2 Layer über SubformPK auf diese Weise zu verknüpfen, müssen folgende Voraussetzungen erfüllt sein:

Der erste Layer muss einen eindeutigen Identifikator besitzen),
Der zweite Layer muss ein Attribut besitzen, welches genau so heißt wie der eindeutige Identifikator des ersten Layers,
Außerdem muss in der Query des ersten Layers ein Attribut definiert werden, welches die Verlinkung zum zweiten Layer herstellt. Der Wert dieses Attributs erscheint als Link und dient als "Vorschau" auf die entsprechenden Datensätze des zweiten Layers.

Beispiel: Der zweiten Layer 'verpachtete Flurstücke' enthält ein Attribut "flurstueckskennzeichen", das als Vorschau herangezogen werden kann.

Im Query-Statement des ersten Layers kann für dieses Attribut eine Aggregationsfunktion verwendet werden, um die verknüpften Datensätze zusammenzufassen. Also beispielsweise die Ausgabe der Anzahl der Flurstücke oder die Hintereinanderreihung der Flurstückskennzeichen. Das ist deswegen sinnvoll, damit der Nutzer in der Suche in diesem Verknüpfungsattribut auch suchen kann.

Für den ersten Layer muss im Attributeditor beim Vorschau-Attribut als Typ 'SubformPK' ausgewählt werden. Im Feld Optionen wird die Layer-ID des zweiten Layers eingetragen und, durch Komma getrennt, der eindeutige Identifikator. (Primärschlüsselattribut) des ersten Layers.

Beispiel: "152,lfdnr"

Wenn beide Layer über mehrere Attribute verknüpft sind, muss man die entsprechenden Attribute, mit Kommas getrennt, hinter das Primärschlüsselattribut schreiben.

Beispiel: "152,lfdnr,gemkgschl,flur,flurstkennz"

Weitere Optionen (werden mit einem ";" abgetrennt):

no_new_window - bewirkt, dass der Link zum verknüpften Layer kein neues Fenster öffnet

Bei einer 1:n Beziehung möchte man meistens, dass wenn man im ersten Layer einen Datensatz löscht, dann auch die nachgeordneten Datensätze des zweiten Layers (automatisch) gelöscht werden. Das geht am elegantesten, wenn man auf Datenbankebene einen CONSTRAINT in Form eines FOREIGN KEY in der Tabelle des zweiten Layers eingefügt (hierfür MUSS der eindeutige Identifikator wirklich auch ein Primärschlüssel sein):

ALTER TABLE <Name der Tabelle des zweiten Layers>
ADD CONSTRAINT "<irgendein Constraint-Name>" Foreign KEY (<Tabellen-Attributname des zweiten Layers, das der Verknüpfung dient>)
     REFERENCES <Name der Tabelle des ersten Layers> (<Name des Primärschlüsselattributs>) MATCH SIMPLE
     ON UPDATE NO ACTION ON DELETE CASCADE

Beispiel:

 ALTER TABLE flurstuecke_verpachtet
 ADD CONSTRAINT "fkfstverpachtet" Foreign KEY (lfdnr)
     REFERENCES verpachtungen (lfdnr) MATCH SIMPLE
     ON UPDATE NO ACTION ON DELETE CASCADE

SubformFK

Auch mit diesem Formularelementtyp lassen sich 2 Layer miteinander verknüpfen. Das "FK" steht für Foreign Key (Fremdschlüssel) und damit für die Art der Verknüpfung.

Beispiel: Der erste Layer sei wieder 'Verpachtungen'. Der zweite Layer ist diesmal ein Layer 'Personen'. Verknüpft ist jeweils die Person, die die Pacht bezahlt (Zahler).

In diesem Fall gibt es eine n:1 Beziehung, da eine Verpachtung nur einen Zahler haben kann aber ein Zahler mehrere Verpachtungen. Hier kann also nicht der Primärschlüssel der Verpachtung als Verknüpfungsattribut verwendet werden, da ein Zahler nicht eindeutig einer Verpachtung zugeordnet ist. Stattdessen muss im zweiten Layer ein eindeutiger Identifikator vorhanden sein, der für die Verknüpfung verwendet werden kann. Dieser muss als Attribut auch im ersten Layer vorhanden sein.

Beispiel: Im zweiten Layer existiert ein Primärschlüsselattribut 'personennr'. Im Layer 'Verpachtungen' gibt es auch ein entsprechendes Attribut 'personennr' und darüber sind beide Layer verknüpft. Weiß man die personennr einer Verpachtung kann man den entsprechenden Datensatz im Layer 'Personen' abfragen.

Um 2 Layer auf diese Weise zu verknüpfen, müssen folgende Voraussetzungen erfüllt sein:

Der zweite Layer muss einen eindeutigen Identifikator besitzen,
Der erste Layer muss ein entsprechendes Attribut besitzen, welches genauso heißen muss,
Außerdem muss es ein Attribut geben, welches im ersten Layer einen Bezug zum zweiten Layer herstellt. Dieses Attribut dient als eine Art Vorschau auf den entsprechenden Datensatz des zweiten Layers.

Beispiel: Im Layer 'Personen' gibt es ein Attribut 'Zahler'.

Im Query-Statement können für dieses Attribut auch einige Spalten des zweiten Layers zusammengefasst abgefragt werden, um zu einer sprechenden Vorschau-Anzeige zu kommen.

Für den ersten Layer muss im Attributeditor beim Vorschau-Attribut als Typ 'SubformFK' ausgewählt werden.
Im Feld Optionen wird die Layer-ID des zweiten Layers eingetragen und, durch Komma getrennt, der eindeutige Identifikator des ersten Layers.

Beispiel: "137,personennr"

Wenn beide Layer über mehrere Attribute verknüpft sind, muss man die entsprechenden Attribute, mit Kommas getrennt, hinter das Primärschlüsselattribut schreiben.

Beispiel: "481,bezirk,blatt,bvnr"

Weitere Optionen (werden mit einem ";" abgetrennt):

no_new_window - bewirkt, dass der Link im gleichen Browser-Fenster bzw. Browser-Tab angezeigt wird.

In kvwmap muss ein Layer nicht notwendigerweise eine Geometrie haben. Wie im oben genannten Beispiel kann es z.B. einen Layer 'Personen' geben, dessen Datensätze dann nur über die Layer-Suche oder über Verknüpfungen mit anderen Layern erreichbar sind. Für einen solchen Layer setzt man minscale und maxscale einfach auf "-1", damit erscheinen diese dann auch nicht in der Legende.

Das folgende Bild zeigt, wie der GLE für die 3 verschiedenen Beispiel-Layer aussieht. Hinter den beiden Vorschauattributen 'Flurstücke' und 'Zahler' gibt es 2 Links 'bearbeiten' und 'neu', über die man die entsprechenden Datensätze der beiden verknüpften Layer aufrufen, bzw. neue erzeugen kann.

SubformEmbeddedPK

Dieser Formularelementtyp kann anstelle des SubfromPK-Typs verwendet werden, wenn die Datensätze des verknüpften Layers nicht in einer extra Sachdatenanzeige dargestellt werden sollen, sondern in Listenform eingebettet innerhalb des Hauptformulars.

Es wird eine Liste der verknüpften Datensätze angezeigt, wobei hier ein Attribut des zweiten Layers als Vorschau verwendet wird. Dieses Attribut ist gleichzeitig ein Link, der zur normalen Sachdatenanzeige des entsprechenden Datensatzes des zweiten Layers führt.

Die Einstellungen im Attribut-Editor sind die gleichen, wie bei SubformPK, nur dass hier noch der Name des Vorschau-Attributes im Optionen-Feld angehangen wird: <Layer-ID>,<primarykey>,<Name Vorschau-Attribut>

Beispiel: "152,vorhaben_id,vorgaenge"

Weitere Optionen (werden mit einem ";" abgetrennt):

no_new_window - bewirkt, dass der Link zum verknüpften Layer kein neues Fenster öffnet
embedded - bewirkt, dass die Formulare des verknüpften Layers direkt im Hauptformular erscheinen

Beispiel: "152,vorhaben_id,vorgaenge;embedded"

Das Attribut, das der Verknüpfung dient (im obigen Beispiel "Vorgänge"), ist nicht Bestandteil des ersten Layers, sondern wird in der Query eingefügt. Das heißt, der (scheinbare) Inhalt des Attributs (die "Vorschau") erscheint weder im CSV-Export noch in der Fachdatensuche. Damit im CSV-Export trotzdem der angezeigte Vorschau-Inhalt als Feld-Inhalt erscheint bzw. damit man in der Fachdatensuche trotzdem auch in diesem Attribut nach Inhalten suchen kann, muss ein sog. "Array" für dieses Feld definiert werden. Im Query-Statement steht sowas wie

SELECT vorhaben_id, ..., '' as vorgaenge, ..., FROM bauvorhaben WHERE 1=1

Statt der beiden Hochkommas wird nun ein Array erzeugt und als Text ausgegeben:

SELECT vorhaben_id, ..., 
array2string(array(select vorgangsart from bauantraege as a where a.vorhaben_id=v.vorhaben_id)) as vorgaenge,
..., FROM bauvorhaben AS v WHERE 1=1

array2string ist eine Funktion, die PostgreSQL nicht kennt. Sie muss angelegt werden:

CREATE OR REPLACE FUNCTION array2string(text[])
 RETURNS text AS
$BODY$SELECT array_to_string($1,cast(', ' as text))$BODY$
 LANGUAGE sql IMMUTABLE STRICT
 COST 100;

Wenn man 2 Layer über SubformEmbeddedPK verknüpft hat und beide Layer eine Geometrie haben, dann wird beim Klick auf "neu" zum Erfassen eines neuen Datensatzes im untergeordneten Layer auf das Objekt des übergeordneten Datensatzes gezoomt.

Beispiel: Man hat einen Layer 'Strassen' und einen verknüpften Layer 'Verkehrsschilder'. Beide haben Geometrien. Jetzt sucht man über die Layersuche nach einer Strasse und bekommt die Sachdatenanzeige dieser Strasse. Wenn man jetzt zu dieser Strasse ein neues Verkehrsschild erfassen möchte und auf "neu" klickt, wird automatisch auf das Strassenobjekt gezoomt.

Ist das Vorschau-Attribut im verknüpften Layer vom Typ "Dokument", so werden die Vorschau-Bilder der jeweiligen Dokumente untereinander in Listenform angezeigt:

Time

Hier kann nichts eingegeben werden, stattdessen wird die aktuelle Zeit in dem Attribut gespeichert. Neben dem Attributnamen erscheint im GLE sowohl in der Suche als auch in der Sachdatenanzeige ein Kalendersymbol, das - wenn angeklickt - einen Kalender zur einfachen Auswahl des Datums öffnet. Es ist nicht möglich, den Formularelementtyp Time editierbar zu machen. Soll das der Fall sein, muss das Attribut als Typ Text definiert werden, auf Datenbankebene aber date oder time sein.

Dokument

Hier kann eine beliebige Datei hochgeladen werden. Die Dateien werden im Ordner 'CUSTOM_IMAGE_PATH' bzw. in dem Dokumentenordner des Layers abgelegt. Je nach Dateityp erscheint in der Sachdatenanzeige ein passendes Vorschaubild mit einem Link auf das Original.

Die Dateien werden auf dem Server nicht mit ihren ursprünglichen Dateinamen abgelegt, sondern bekommen einen Namen, der sich aus dem Zeitstempel und einer Zufallszahl zusammensetzt. Dadurch werden die Dateien nicht überschrieben, wenn gleichnamige Dateien hochgeladen werden. Bei der Anzeige bzw. dem Download der Dateien in kvwmap erscheint wieder der ursprüngliche Dateiname.

Neben dieser standardmäßigen Variante der Dateiablage auf dem Server lassen sich die Dateinamen und auch die Verzeichnisstruktur unterhalb des Dokumentenordners für jeden Layer frei definieren. Dazu besteht die Möglichkeit im Attributeditor im Optionenfeld des Dokumenten-Attributs eine beliebige SQL-Abfrage zu definieren. Die Abfrage muss als Ergebnis die Ordnerstruktur unterhalb des Dokumentenordners inklusive des Dateinamens aber ohne Dateiendung liefern. Damit diese Struktur variabel ist, können die Werte der Attribute dieses Layers über "$<attributname>" in die Abfrage einbezogen werden.

Beispiel: Man hat einen Dokumentenlayer mit einem fortlaufenden Attribut "doc_id". In diesem Layer gibt es sehr viele Dokumente und da diese nicht alle einzeln im Dokumentenordner des Layers liegen sollen, möchte man weitere Unterordner dazwischen einfügen. Es sollen maximal 100 Dateien in jedem Unterordner abgelegt werden. Dazu definiert man im Optionenfeld folgende SQL-Abfrage:

select doc_id/100 || '/' || doc_id from (select CASE WHEN '$doc_id' = '' THEN nextval(('dokumente_doc_id_seq'::text)::regclass) ELSE ('$doc_id'||0)::integer / 10 END as doc_id) as foo

Auf Basis der fortlaufenden Nummer "doc_id" wird ein Pfad generiert, welcher z.B. für die doc_id "3456" folgendermaßen aussieht: "34/3456". Die Datei bekommt also den Namen der doc_id "3456" und wird in einem Unterordner "34" abgelegt. Die Unterabfrage mit der CASE-Bedingung dient dazu, die beiden Fälle Änderung und Neuerfassung zu unterscheiden. Bei einer Änderung eines bestehenden Datensatzes soll die vorhandene doc_id genommen werden und bei Erfassung eines neuen Datensatzes die nächsthöhere Nummer aus der entsprechenden Sequenz.

Link

Hier kann eine URL angegeben werden. Sie erscheint als Link über dem Eingabefeld. Bei nur Leserecht erscheint nur der Link. Im Optionenfeld kann ein Linktext eingegeben werden, wird nichts eingegeben, wird der letzte Teil der Linkadresse als Linktext angezeigt.

dynamischer Link

Der dynamische Link ermöglicht es, eine URL aufzurufen, die von bestimmten Attributen des Layers abhängig ist. D.h. die URL besteht zum einen aus festen Teilen, die immer gleich sind und aus variablen Teilen, welche sich aus den Attributwerten des jeweiligen Datensatzes ergeben. Der dynamische Link wird im Unterschied zum normalen Link-Typ nicht in einer PostGIS-Datenbanktabelle gespeichert, d.h. hier wird keine Tabellenspalte benötigt, stattdessen wird ein Pseudo-Attribut in das Query-Statement aufgenommen. Die dynamische URL zu diesem Attribut wird im Attributeditor im Optionenfeld definiert. Die variablen Teile der URL, die dann später durch die Attributwerte ersetzt werden, werden in der Form $<attributname> in die URL aufgenommen. Wichtig dabei ist, dass nur die Attributnamen als Variablen verwendet werden können, die das Layer-Recht lesen oder editieren haben und auch das Pseudo-Attribut auf lesen gesetzt sein muss.

Ein Beispiel: Man hat einen Layer Schulen. Dieser besitzt u.a. zwei Attribute lat und long, für die geografische Breite und Höhe. Es gibt außerdem eine externe Webanwendung, die eine Bushaltestellensuche über einen URL-Aufruf anbietet. Man kann nun der Sachdatenanzeige des Layers Schulen einen dynamischen Link hinzufügen, welcher alle Bushaltestellen in der Umgebung der Schule sucht. Dazu erweitert man das Query-Statement des Layers Schulen um ein Pseudo-Attribut bushaltestellen. Also z.b. so

SELECT *, '' as bushaltestellen FROM schulen WHERE 1=1

Im Attributeditor kann man nun für das Attribut bushaltestellen den Formularelementtyp "dynamischer Link" auswählen. Im Optionenfeld trägt man nun folgendes ein:

http://www.bushaltestellensuche.de?latitude=$lat&longitude=$long&umkreis=10

Dadurch erhält man in der Sachdatenanzeige für jede Schule einen Link, der die Bushaltestellen in der Umgebung sucht.

Weitere Optionen (werden mit einem ";" abgetrennt):

<Linktext> - nach der URL kann ein Linktext angegeben werden, der dann anstatt der kompletten URL angezeigt wird
no_new_window - bewirkt, dass der Link zum verknüpften Layer kein neues Fenster öffnet
embedded - bewirkt, dass der Link nicht auf eine neue Seite verweist, sondern den Inhalt der aufgerufenen Seite direkt im Hauptformular anzeigt

Es ist möglich, den "<Linktext>" mit einer der beiden Optionen "no_new_window" oder "embedded" zu kombinieren, es muss jeweils ein Semikolon gesetzt werden.

Der dynamische Link ist auch eine Alternative der Verknüpfung von zwei Layern, insbesondere wenn es sich um eine 1:1-Verknüpfung handelt. Da auf denselben Server verwiesen wird, kann dieser Teil der URL entfallen, Beispiel:

index.php?go=Layer-Suche_Suchen&selected_layer_id=38&value_fundplatzid=$fundplatzid&operator_fundplatzid==;anzeigen;no_new_window

MailTo

Dieser Formularelementtyp kann für Email-Adressen verwendet werden. Sie werden damit als mailto-Link dargestellt und mit dem Email-Programm geöffnet.

User

Hier kann nichts eingegeben werden, stattdessen wird der aktuelle Nutzer gespeichert.

UserID

Hier kann nichts eingegeben werden, stattdessen wird die aktuelle Nutzer-ID gespeichert.

Stelle

Hier kann nichts eingegeben werden, stattdessen wird die aktuelle Stelle des Nutzers gespeichert.

Fläche

Hier kann nichts eingegeben werden, stattdessen wird die Fläche der Polygon-Geometrie gespeichert.

Länge

Hier kann nichts eingegeben werden, stattdessen wird die Länge der Linien-Geometrie gespeichert.

Checkbox

Erzeugt eine Checkbox, welche angehakt werden kann. Dieser Typ ist für Attribute vom Datentyp "boolean" gedacht. Auf Datenbankebene sollten diese Attribute nicht als NOT NULL definiert werden, weil für den Nutzer sonst der irrige Eindruck entsteht, er MUSS einen Haken setzen.

Erläuterungen zu Attributen

Um Attribute in der Sachdatenanzeige näher beschreiben zu können, kann ein Erläuterungstext eingegeben werden. Dadurch erscheint neben dem Attribut ein kleines Hinweissymbol, welches den Text als Tooltip anzeigt, wenn man die Maus darüber hält.

Gruppierung von Attributen

Damit die Attribute in der Sachdatenanzeige gruppiert angezeigt werden, kann man ihnen im Attributeditor Gruppennamen zuordnen. Alle Attribute mit dem selben Gruppennamen werden zu einer Gruppe zusammengefasst, wobei die Attribute schon in der richtigen Reihenfolge sein müssen. Die Gruppen lassen sich im GLE auf- und zuklappen. Hängt man an den Gruppennamen noch ";collapsed" an, ist diese Gruppe schon zu Beginn zugeklappt.

Bearbeitung von Geometrien - Geometrie-Editor

Um die Geometrie eines abgefragten Datensatzes zu bearbeiten, klickt man im generischen Layereditor in der Sachdatenanzeige auf den Link 'Geometrie bearbeiten'. Beim Neuanlegen eines Datensatzes ist der Geometrieeditor bereits integriert. Eine bereits vorhandene Geometrie erscheint blau hervorgehoben und kann bearbeitet werden. Nach Klick auf 'Speichern' wird die veränderte Geometrie in die Postgis-Tabelle eingetragen. Dabei wird nach dem Speichern wieder auf die gesamte Ausdehnung der Geometrie gezoomt. Dies kann gerade bei der Erfassung größerer Geometrien hinderlich sein, wenn man auf einen bestimmten Teil der Geometrie gezoomt hat und zwischendurch speichern möchte. Dafür gibt es den Button 'Zwischenspeichern'. Hier wird die Geometrie auch gespeichert, nur wird der Kartenausschnitt danach nicht verändert.

Je nach Geometrietyp des jeweiligen Layers bietet der Editor verschiedene Werkzeuge und Funktionen zum Bearbeiten an.

Um die Geometrie eines Polygon-Layers zu bearbeiten, gibt es folgende Werkzeuge:

Polygon hinzufügen
Polygon entfernen
Geometrie eines Layers selektieren und hinzufügen
Geometrie eines Layers selektieren und entfernen
die aktuelle Geometrie um eine definierte Breite vergrößern oder verkleinern (negatives Vorzeichen)
gepufferte Linie hinzufügen
paralleles Polygon hinzufügen
Geometrie verschieben
Eckpunkte bearbeiten
Koordinate eingeben

Um die Geometrie eines Linien-Layers zu bearbeiten, gibt es folgende Werkzeuge:

Linien hinzufügen
Linien durch Zeichnen eines Polygons entfernen
Geometrie eines Layers selektieren und hinzufügen
Geometrie eines Layers selektieren und entfernen
Linienzug aufsplitten
Geometrie verschieben
Eckpunkte bearbeiten
Koordinate eingeben

Um die Geometrie eines Punkt-Layers zu bearbeiten, gibt es 2 Werkzeuge:

Punkt setzen
Koordinate eingeben

Die Darstellung der Geometrien erfolgt mit SVG und die geometrischen Operationen werden mit AJAX und Postgis realisiert.

In der Eckpunktbearbeitung ist es möglich, Punkte zu löschen (Doppelklick) oder Punkte an beliebiger Stelle in eine Kante (eines Linien- oder Polygonlayers) einzufügen. Bei Linienlayern können außerdem neue Punkte vor den Anfang bzw. hinter das Ende des Linienzuges gesetzt werden.

Zur Bearbeitung von Eckpunkten existiert weiterhin ein Punktfang. Wird dieser eingeschaltet (unter der Kartengrafik), erscheinen alle Eckpunkte der Geometrien aller aktuell aktiven PostGIS-Layer, die in dem aktuellen Kartenausschnitt zu sehen sind. Wenn man nun einen neuen Eckpunkt auf einen solchen Punkt setzt oder einen Punkt der gerade editierten Geometrie auf einen solchen Punkt zieht, wird dieser gefangen und die exakten Koordinaten übernommen.

Im Geometrie-Editor gibt es eine Checkbox "weiterzeichnen". Damit kann rollenbezogen eingestellt werden, ob nach dem Navigieren wieder in den Zeichenmodus gewechselt wird oder nicht.

Layer-Suche

Neben der Abfragemöglichkeit über die Karte kann man auch über eine Suchmaske nach Postgis-Layern suchen und die Sachdaten im generischen Layereditor anzeigen und bearbeiten. Die go-Variable dazu heißt Layer-Suche. Hier stehen alle Layer zur Auswahl, die der aktuellen Stelle zugeordnet sind und die abfragbar sind. Nach Auswahl eines Layers kann man als Suchparameter die Layerattribute verwenden, für die man mindestens Leserecht hat. Es stehen folgende Suchoperatoren zur Verfügung:

=	gleich
!=	ungleich
<	kleiner als
>	größer als
ähnlich	(SQL: LIKE) hier kann man "_" bzw. "%" als Platzhalter verwenden
nicht ähnlich	(SQL: NOT LIKE) hier kann man "_" bzw. "%" als Platzhalter verwenden
ist leer	(SQL: IS NULL)
ist nicht leer	(SQL: IS NOT NULL)
befindet sich in	(SQL: IN) hier können mehrere mögliche Werte durch ein "\|" getrennt angegeben werden
zwischen	(SQL: BETWEEN) hier kann ein Anfangs- und Endwert angeben werden

Das Ergebnis der Suche erscheint dann im generischen Layer-Editor bzw., falls dem Layer ein Template zugeordnet ist, das entsprechende Template.

Sachdaten-Druck

Die Sachdaten von PostGIS-Layern lassen sich neben der Anzeige im GLE auch als PDF ausgeben. Im Sachdatendruck-Layouteditor (go=sachdaten_druck_editor) lassen sich für jeden Layer verschiedene Layouts erstellen, die anschliessend den gewünschten Stellen zugewiesen werden können.

Das Prinzip der Layoutdefinition ist ähnlich dem der Druckrahmen für den PDF-Kartendruck. Jedes Attribut kann über einen x- und y-Wert auf der PDF-Seite positioniert und mit einer bestimmten Schriftgröße und -Art ausgegeben werden. In der Vorschau des Layouts im Layouteditor werden die Attributnamen verwendet, beim späteren Druck eines Datensatzes die Attributwerte. Auch das Geometrieattribut kann dem Layout zugeordnet werden. An dieser Stelle erscheint dann ein quadratisches Kartenbild des entsprechenden Objekts in der angegebenen Breite. Auch hier können beliebig viele Freitexte und ein Hintergrundbild im Layout angeordnet werden.

In Freitexten können auch die Attributwerte verwendet werden. Dazu muss man einfach das Schlüsselwort $<attributname> in den Text einbauen, welches dann später durch den jeweiligen Attributwert ersetzt wird.

Wenn man in einem Drucklayout Attribute ausgeben möchte, die Text über mehrere Zeilen enthalten und dieser Text unterschiedlich lang sein kann, ist die Positionierung der nachfolgenden Attribute und Freitexte schwierig. In diesem Fall kann man die y-Position der nachfolgenden Elemente relativ zu den vorhergehen Attributen angeben. Dazu wählt man für alle nachfolgenden Elemente im Auswahlfeld "unterhalb von" das Attribut aus, auf das sich die relative Position beziehen soll und gibt als y-Wert den Abstand zu diesem Attribut an.

Es gibt 3 verschiedene Layouttypen:

Typ 1: pro Datensatz eine Seite
Typ 2: Datensätze untereinander
Typ 3: eingebettet

Ein Layout vom Typ 1 erzeugt ein PDF, in dem jeder Datensatz eines zu druckenden Abfrageergebnisses einer neuen Seite im PDF entspricht.

Beim Layouttyp 2 werden die Datensätze untereinander im PDF angeordnet, so dass eine Listenform entsteht. Die Positionsangaben die man für ein solches Layout macht, gelten also für den ersten Datensatz, die folgenden Datensätze werden fortlaufend darunter angeordnet. Für Freitexte kann man bei diesem Layouttyp angeben, ob sie fixiert sein sollen, wie z.B. für Überschriften, oder auch mit jedem Datensatz untereinander angeordnet werden sollen, wie z.B. für Attributbeschriftungen.

Der Typ 3 entspricht von der Darstellung dem Typ 2, d.h. auch hier werden die Datensätze untereinander angeordnet. Allerdings wird dieser Layouttyp für eingebettete Drucklayouts verwendet.

Mit eingebetteten Layouts lassen sich die 1:n Beziehungen, die in der Sachdatenanzeige über verknüpfte Layer (SubFormPK, SubFormEmbeddedPK) abgebildet werden, auch in die Sachdaten-Drucklayouts integrieren. Das Prinzip ist, dass man für jeden der beiden Layer ein Layout definiert, wobei das für den abhängigen Layer vom Typ 3 "eingebettet" ist. Das eingebettete Layout enthält auch keinen Druckkopf oder ähnliches, sondern nur die gewünschten Attribute und Freitexte, die dann in Listenform dargestellt werden. Im Layout für den übergeordneten Layer kann man über das Pseudo-Attribut, welches vom Formularelementtyp "SubFormPK" bzw. "SubFormEmbeddedPK" ist, das andere Drucklayout einbetten. Hier erscheint eine Auswahlliste mit allen verfügbaren Layouts des verknüpften Layers, welche den Typ 3 "eingebettet" haben. Über die x-y-Werte lässt sich das gesamte eingebettete Layout positionieren.

+ =

Ist für einen Layer ein Sachdaten-Drucklayout vorhanden und der entsprechenden Stelle zugewiesen, so erscheint in der Sachdatenanzeige des GLE ein Link "ausgewählte Datensätze: drucken". Wenn es mehrere Layouts gibt, muss der Nutzer noch das gewünschte Layout auswählen, ansonsten erscheint beim Klick darauf eine Druckvorschau der ersten Seite des PDFs. Ein Klick auf "Drucken" erzeugt schliesslich das PDF.

Style- und Labeleditor

Mit dem Style- und Labeleditor lassen sich die Styles der Geometrie und der Beschriftung der Klassen von Layern editieren.

Der Editor (go=Style_Label_Editor) wird entweder aus dem Menü Layerverwaltung oder dem Formular zum Ändern von Layereigenschaften aufgerufen. Im Editor wählt man zunächst links oben den Layer aus. Nach Aufruf aus dem Layereditor ist der Layer schon voreingestellt. Anschließend wählt man die Klasse aus, für die man den Style anpassen will. Daraufhin erscheinen ein Feld mit den zugeordneten Styles und Labels. Ein Klick auf den Style oder das Label öffnet das dazugehörige Formular mit den entsprechenden Parametern des Mapserver-STYLE- bzw. LABEL-Objekts.

Im rechten Bereich befinden sich oben Hilfsmittel zur Auswahl von Farben und Fonts und unten eine Vorschau der Layer. Wenn der Style eines Layers geändert wird, sollte dieser auch eingeschaltet sein. Änderungen von Styles werder erst sichtbar, wenn man unter dem Formular auf Speichern geklickt hat und danach die Karte aktualisiert. Es können mehr als ein Style pro Klasse erzeugt werden oder wieder gelöscht werden. Style- und Labeleinstellungen gelten derzeit stellenübergreifend. Das heißt ein Layer sieht in allen Stellen gleich aus. Sollen Layer in verschiedenen Stellen unterschiedlich aussehen, kann man die Layer einfach kopieren und anpassen.

Es ist möglich, einen Style zu kopieren (bei den Labels geht das nicht). Man trägt in einem neuen oder vorhandenen Style einfach die Nummer eines bereits existierenden Sytels ein und speichert.

Style- und Labeleditor

Import/Export-Funktionen

Shape-Export

Mit dem Shape-Export lassen sich PostGIS-Layer in eine Shape-Datei exportieren. Der Shape-Export wird über die go-Variable "SHP_Export" aufgerufen. In einer Liste werden nun alle PostGIS-Layer angezeigt, die in der aktuellen Stelle abfragbar sind. Wenn man den zu exportierenden Layer auswählt, wird das Data-Statement des Layers geladen. Diese "SELECT"-Abfrage wird für den Export verwendet. Bei Bedarf kann man dieses Statement anpassen um z.B. zusätzliche Attribute abzufragen oder bestimmte Attribute wegzulassen.

Es ist außerdem möglich, nicht den gesamten Datenbestand des Layers zu exportieren, sondern durch räumliche Auswahl den Export auf bestimmte Datensätze zu beschränken. Dazu hat man die Möglichkeit ein Polygon zu zeichnen und so bestimmte Datensätze zu selektieren. Anschliessend wird durch Klick auf "über Polygon einschränken" die "SELECT"-Abfrage um die räumliche Einschränkung erweitert.

Nach Klick auf "Shape-Datei erzeugen" wird der Shape-Export gestartet. Der Export liefert 3 Dateien, welche in ein zip-Archiv gepackt werden, das man dann herunterladen kann. Damit das Zippen funktioniert, muss die Konstante "ZIP_PATH" richtig gesetzt sein. Sie verweist auf ein Zip-Programm, welches von der Kommandozeile gestartet werden kann. Bei Linux-Servern reicht in der Regel "zip". Bei Windows-Servern z.B. "c:/programme/Zip/bin/zip.exe".

Shape-Import

Mit dem Shape-Import lassen sich Shape-Dateien in die PostGIS-DB einlesen. Der Shape-Import wird auf Linux-Servern über die go-Variable "SHP_Import" aufgerufen. Auf Windows-Servern muss eine vereinfachte Version des Shape-Imports verwendet werden. Hier heißt die go-Variable "simple_SHP_Import". Um die Shape-Datei einzulesen müssen die 3 Dateien vom Typ dbf, shp und shx in eine Zip-Datei gepackt werden. Diese Zip-Datei lässt sich dann auf den Server hochladen.

Auf dem Server wird die Zip-Datei ausgepackt und die dbf-Datei gelesen. Auf einem Linux-Server geschieht das Entpacken mit dem Programm "unzip". Auf einem Windows-Server wird die PHP-Funktion "zip_open" verwendet. Dafür ist es erforderlich, dass die PHP-Extension "php_zip.dll" geladen wird. Standardmäßig ist diese in der php.ini auskommentiert.

Kartenausschnitt speichern/laden

Unter dem Kartenfenster befinden sich die Links: Ausschnitt speichern | Ausschnitt laden. Sie dienen dem Speichern von Einstellungen des aktuellen Kartenfensters und dem Abrufen gespeicherter Einstellungen von Kartenfenstern.

Speichern:

Um einen bestimmen Kartenauschnitt zu speichern, passen sie das Kartenfenster und die entsprechenden Layern an.
Zum Speichern des aktuellen Kartenfenstern wählen Sie den Link "Ausschnitt speichern".
Sie gelangen auf die Oberfläche, in der der gewählte Kartenauschnitt gezeigt wird. Darüber befindet sich ein Eingabefeld, in dem es möglich ist ein Kommentar zum entsprechenden Kartenausschnitt hinzuzufügen. Der Kommentar ist in sofern wichtig, dass nach dem Zeitstempel nur so eine eindeutige Identifikation des gespeicherten Kartenausschnittes möglich ist.
Durch das betätigen des "Speichern"-Button werden die Einstellungen des Kartenausschnittes und der dazugehörige Kommmentar gespeichert.
Mit Hilfe des "Zurücksetzen"-Button können Sie die Eingabe im Kommentarfeld löschen. Es wird dabei nur das Kommentarfeld zurücksgesetzt, ohne den Kartenausschnitt zu speichern.
Mit betätigen des "Abbrechen"-Button beenden sie den Vorgang ohne den Kartenausschnitt zu speichern.

Wählen:

Wenn ein gespeicherter Kartenausschnitt geladen werden soll, betätigen Sie dazu den Link "Ausschnitt laden".
Es folgt eine Liste aller gespeicherten Kartenausschnitte des jeweiligen Nutzers.
Durch betätigen des entsprechenden Zeitstempels gelangen Sie auf die Oberfläche, mit angepassten Kartenfenster, zurück.

Drucken

Drucken eines frei wählbaren Kartenausschnittes unter Angabe des Maßstabes und der Drehung des Druckbereiches, siehe Drucken in PDF.

Weitere Funktionalitäten

Kartengröße wahlweise einstellbar
Kartenausschnitt als Rasterbild abspeicherbar
Bildschirm-Ansichten drucken (Browserfunktionalität)
Druck-Voransicht (Browserfunktionalität)
Layer wahlweise ein-/ausschaltbar
Hilfe-Funktion

Funktionen auf dem Server

Speicherung und Verwaltung der Karteneinstellungen

In der MySQL-Datenbank werden die Informationen vorgehalten, die für eine Kartenausgabe erforderlich sind. Es handelt sich im Wesentlichen um die Daten, die sonst in der Map-Datei für den UMN-MapServer enthalten sind, nur dass sie in der Datenbank für verschiedene Karten nicht redundant abgespeichert werden.
Speicherung und Verwaltung von Benutzerdaten

In der MySQL-Datenbank werden Daten zu den Benutzern, zu den Stellen und zu den Rollen, die die Benutzer in den Stellen einnehmen können gespeichert. Folgende Informationen können zu den Nutzern gespeichert werden.
- login-Name, Passwort, Name, Tel., E-Mail, Funktion, letzte besuchte Stelle des Benutzers
- Bezeichnung, Gültigkeitsdauer, maximale Kartenausdehnung, Referenzkarte, Wappen, Datenbankverbindung, OWS-Metadaten
- aktuelle Kartenausdehnung, Fenstergröße, Zoomfaktor, Referenzsystem, letztes gewähltes Werkzeug, Layoutgestaltung der GUI (Skin) können für jeden Benutzer innerhalb der Stelle gespeichert werden.

Einlesen von ALB-Daten im WLDGE-Format in eine PostgreSQL-Datenbank

Freie Gestaltung von Menüpunkten und Zusammenfassung von Menüunterpunkten zu Obermenüs.

Fachschalen

Zu kvwmap gehört eine Reihe von Funktionen, die in Fachschalen zusammengefasst wurden. Eine Fachschale beinhaltet thematisch zusammengehörende Funktionen zur Erfüllung fachspezifischer Aufgaben. Die anderen Funktionen stehen parallel dazu immer zur Verfügung. Die benötigten Funktionen können über das frei konfigurierbare Menü thematisch zu einer Fachschale und über zugriffsrechtlich über die Rolle eines Benutzers in einer Stelle zugeordnet werden.

Änderung der Eigentümeradressen

Die in der Sachdatenanzeige der Flurstücke angezeigten Eigentümeradressen können von authorisierten Nutzern geändert werden. Die Änderungen werden in einer separaten Tabelle alb_g_namen_temp gespeichert und können in das ESAF64-Format exportiert werden, um damit das ALB zu aktualisieren.

Um diese Funktionen nutzen zu können, müssen folgende Voraussetzungen erfüllt sein:

In der PostgreSQL-DB muß die Tabelle alb_g_namen_temp vorhanden sein (siehe postgis_update.sql).

In der MySQL-DB muß der folgende Layer angelegt werden:

 INSERT INTO `layer` VALUES (layer_id???, 'Adressaenderungen', 5, group_id???, 'SELECT * FROM 
 alb_g_namen_temp WHERE 1=1', '', '', '', '', '', 50000, 0, '', 'user=kvwmap 
 password=??? dbname=???', 6, 'lfd_nr', '', 3, 'pixels', '2398', 
 NULL, '0', 'EPSG:2398', '', '1.1.0', 'image/png', 60, NULL);

In der config.php muss LAYER_ID_ADRESSAENDERUNGEN die ID des neuen Layers bekommen.

In der MySQL müssen in u_funktionen die Funktionen Adressaenderungen und export_ESAF64 eingetragen werden. Die Funktion Adressaenderungen kann den Stellen zugewiesen werden, die Adressänderungen vornehmen dürfen. Die Funktion export_ESAF64 sollte der Stelle zugewiesen werden, die die gespeicherten Änderungen in die ESAF64-Datei exportieren darf (im Normalfall der Administrator).
In der Rechteverwaltung muß den gewünschten Stellen für den Layer Adressaenderungen das Recht zum Erzeugen von Datensätzen gegeben werden. Die Attribute user_id, datum, name1, name2, name3 und name4 sollten nur lesbar sein und die Attribute neu_name3 und neu_name4 editierbar. Das Löschen von Einträgen ist dem Nutzer nicht möglich, er muss in diesem Fall die ursprüngliche Adresse wieder eintragen.
Im Attribut-Editor ist für die Attribute neu_name3, neu_name4, user_id, name1, name2, name3 und name4 das Formularelement Text einzustellen. Das Attribut datum muß auf den Typ Time gesetzt werden.

Hat ein Nutzer in einer Stelle das Recht Adressänderungen vorzunehmen, so erscheint in der Sachdatenanzeige der Flurstücke neben jeder Eigentümeradresse ein Link Adresse aktualisieren. Der Link öffnet ein zweites Fenster mit einem Formular zur Eingabe der neuen Adresse. Zusätzlich zur Adresse wird die User-ID, das Datum und als Schluessel die alten Felder name1 - name4 des Eigentümers gespeichert. Wurde die Adresse eines Eigentümers bereits geändert, erscheint bei Abfrage des entsprechenden Flurstücks unter der alten Adresse die neue Adresse mit Angabe des Datums und des Nutzers, welcher die Änderung vorgenommen hat. Daneben erscheint ein Link Aktualisierte Adresse ändern, um die neue Adresse zu bearbeiten.

Um die neuen Adressen in das ESAF64-Format zu exportieren, ruft man die go-Variable export_ESAF64 auf. Hier kann man nun die Exportdatei erzeugen und sie anschließend herunterladen. Es werden nur Adressen ausgegeben, die sich auf nicht historische Grundbuchblätter (aktualitaetsnr='hist') beziehen.

Hat man die Exportdatei erzeugt, das ALB damit aktualisiert und die neuen ALB-Daten in kvwmap eingespielt, kann man die Tabelle alb_g_namen_temp bereinigen. Dazu gibt es auf der ESAF-Export-Seite (go-Variable export_ESAF64) einen Button Tabelle bereinigen, der die alten Adressänderungen löscht.

Bauleitplanungsänderung

Bei der Veränderung von B-Pläne etc. soll den Gemeinden, als Träger der Bauleitplanung, die Möglichkeit gegeben werden, um die zu verändernden Stellen ein Polygon zu zeichnen und somit die betroffenen Stellen unkenntlich zu machen. Damit soll gewährleistet werden, dass die betroffenen Teile der Pläne als nicht aktuell gekennzeichnet werden und somit seitens der Kreisverwaltung keine Falschaussagen getroffen werden.

Um die Fachschale Bauleitplanungsänderung aufrufen zu können, muss es einen entsprechenden Menüpunkt mit der go-Variable 'bauleitplanung' geben (Tabelle: u_menues). Außderdem muss dieser Menüpunkt der Stelle (Tabelle: u_menue2stelle) und dem Nutzer dieser Stelle (Tabelle: u_menue2rolle) zugeordnet werden. In der Fachschale ist es möglich ein Polygon zu zeichnen, um so das betroffene Gebiet innerhalb eines B-Planes zu markieren. Desweiteren muss eine E-Mail-Adresse angegeben werden, an die eine Mail mit der Änderungsbenachrichtigung geschickt wird. Zu dieser Benachrichtung gehört die Nummer des bearbeiteten B-Planes und eine Bemerkung zur Änderung. Nach dem Absenden des Formulars wird das Polygon gespeichert, und die Mail wird automatisch versandt.

Damit die geänderten Bereiche in den B-Plänen nicht mehr zu sehen, bzw. markiert sind, muss es einen Layer geben, der über dem Layer der B-Pläne liegt. Dieser Layer könnte beispielsweise so aussehen:

INSERT INTO layer VALUES (106, 'Bauleitaenderungen', 2, 4, "", 'the_geom from (select the_geom,id
from bp_aenderungen where loeschdatum is null) as foo using unique id using
srid=2398', "", "", "", "", 50000, 0, "", 'user=kvwmap password=kvwmap dbname=kvwmapsp',
6, "", "", 3, 'pixels', 0, '2398', 'EPSG:2398', "", '1.1.0', 'image/png', 60, NULL);

Für die Darstellung des Layers wird dann natürlich noch eine entsprechende Klasse und ein Style benötigt. Damit gewährleistet ist, dass dieser Layer stets aktiv ist, wenn der Layer B-Pläne aktiv ist, wird in das Feld requires in der Tabelle used_layer folgende Bedingung eingetragen:

([B-Plaene]=1)

Dadurch ist der Layer Bauleitaenderungen vom Layer B-Pläne abhängig, immer aktiv wenn dieser aktiv ist und sein Name nicht in der Legende zu sehen. Gibt man der Klasse des Layers Bauleitaenderungen keinen Namen, so erscheint auch die Klasse des Layers nicht in der Legende.

Um den die gespeicherten Polygone der Bauleitänderung trotzdem abfragen zu können, wird ein zweiter Layer angelegt. Dieser sieht z.B. so aus:

INSERT INTO layer VALUES (112, 'B-Plan Änderungen', 2, 4, 'SELECT id,
username,hinweis,bemerkung,the_geom,datum FROM bp_aenderungen WHERE 1=1', 'the_geom from (select
the_geom,id from bp_aenderungen where loeschdatum is null) as foo using unique id using srid=2398', "",
"", "", "", 50000, 0, "", 'user=kvwmap password=kvwmap dbname=kvwmapsp', 6, "", "", 3, 'pixels', 0,
'2398', 'EPSG:2398', "", '1.1.0', 'image/png', 60, NULL);

Dieser Layer ist dann nach Zuweisung von Klasse und Style in der Legende zu sehen und kann auch ausgeschaltet werden.

Die Polygone, die man in der Fachschale erstellt hat, lassen sich auch wieder löschen, jedoch werden sie nicht wirklich gelöscht, sondern nur als gelöscht markiert. Um Polygone löschen zu können, muss es in u_funktionen eine Funktion "BplanAenderungLoeschen" geben und diese muss der gewünschten Stelle zugeordnet werden. Nach einer Sachdatenabfrage auf den Layer "B-Plan Änderungen" lassen sich nun die aufgeführten Polygone löschen.

Notizen

Mit der Funktion Notizen können Textnotizen an jede beliebige Position innerhalb des Kartenbereichs einer Stelle gesetzt werden .

Voraussetzungen:

Der Stelle muss das Menü Notizen zugewiesen worden sein. (Tabelle: u_menue2stelle)
Dem Nutzer muss die Zuordnung der Stelle zum Menü Notizen zugewiesen sein. (Tabelle: u_menue2rolle)
Es muss ein Layer Notizen eingetragen worden sein.
Der Stelle muss der Layer Notizen zugewiesen sein.
Der Layer muss dem Nutzer zugewiesen worden sein.
Ebenso müssen Class und Label sowie die Zuordnung zur Klasse und Layer eingetragen sein. Nutzen Sie für all diese Eintragungen den Abschnitt Notizen aus mysql_install_help.php aus dem Verzeichnis layouts/sql_dumps
Es muss eine Datenquelle in der postgis Datenbank vorhanden sein. Das heißt die Tabelle für Notizen muss existieren. Wenn nicht kann diese mit dem SQL-Statement aus postgres_install.sql angelegt werden. (in layouts/sql_dumps)

Erst wenn diese Voraussetzungen erfüllt sind, erscheint das Menü zum Anlegen neuer Notizen.

Klicken Sie auf Notizen und legen eine neue Notiz an. Diese erscheint nach dem Absenden und dem aktiv schalten im Kartenfenster. Die zu definierende Textposition zeigt auf die Spitze des Bezugspfeils.

Wenn man Text in mehreren Zeilen haben möchte, muss man im Textfeld mit der Enter-Taste feste Zeilenumbrüche eingeben.

Wenn man eine Notiz ändern möchte macht man die Abfrageoption des Layers Notizen aktiv, wählt den Infoknopf und selektiert in der Karte die Notiz, die man ändern möchte. Dort kann man dann auf ändern klicken und kommt wieder in das Formular, welches zum anlegen neuer Notizen dient.

Kataster

Darstellung der ALK und ALB-Daten. Suche nach Flurstücken und Adressen aus der ALK und ALB. Automatisierte Fortführung des ALB-Bestandes über das einlesen von WLDGE-Dateien mit WLDGE2SQL-Konverter. Aktualisierung von ALK-Daten über EDBS2WKT-Konverter.

Nachweisverwaltung

Mit der Nachweisverwaltung können Dokumente des Liegenschaftskatasters mit Metadaten beschrieben, in einem Rissarchiv gespeichert, recherchiert, angezeigt, bestellt und heruntergeladen werden. Die Beschreibung erfolgt sowohl mit einigen ausgewählten Sachdaten, wie Dokumentenart, Rissnummer und Vermessungsstelle als auch mit einem Multipolygon. Die Suche über den Raumbezug, ermöglicht das Auffinden von Dokumenten ohne die Angabe von Flurstücksnummern.

Allgemeine Beschreibung der Nachweisverwaltung

Die Nachweisverwaltung dient der digitalen Fortführung des Liegenschaftskatasters. Mit dieser Anwendung können alle Dokumente, die als Nachweis im Liegenschaftskataster geführt werden, zusammen mit Ihren beschreibenden Daten eingeflegt und danach recherchiert werden. Zu allen Dokumenten, die als Bilddatei vorliegen, wird neben dem Metadaten auch der Raumbezug abgespeichert. Der Raumbezug, wird in Form eines Polygons realisiert, das auf der Grundlage der ALK zuvor festgelegt und zusammen mit den Metadaten in die Datenbank eingepflegt wird. Mit Hilfe der Metadaten und des Raumbezugs, können dann die Dokumente recherchiert und ausgegeben werden.

Vorraussetzung für die Nutzung

Um die Nachweisverwaltung von kvwmap nutzen zu können müssen folgende Voraussetzungen gegeben sein.

Es muss eine Stelle eingerichtet worden sein, in der die Funktionen der Nachweisverwaltung genutzt werden können. Als praktisch erweist es sich, wenn eine Stelle für die Auskunft eingerichtet wird und eine für die Einpflege von Dokumenten, bzw. die Änderungsfunktion.
Es müssen Menüpunkte (Tabelle: u_menues) für die Funktionen der Nachweisverwaltung eingerichtet sein. Dazu kann man die entsprechenden SQL-Statements zu „Einträge der Menüpunkte“ in mysql_install.sql im Verzeichnis layouts/sql_dumps nutzen. Die ID´s für id und obermenue sowie die menueebene müssen natürlich an die eigenen Menüpunkte angepasst sein, die man vielleicht schon eingerichtet hat.
Die Menüpunkte müssen zu den entsprechenden Stellen zugeordnet sein.
Die Nutzer, die die Nachweisverwaltung nutzen können sollen müssen zu den entsprechenden Stellen zugeordnet sein.
Es muss eine PostgreSQL-Datenbank mit PostGIS Aufsatz installiert sein.
Die Tabellen für die Nachweisverwaltung müssen mit den entsprechenden Rechten in der PostGIS-Datenbank eingerichtet sein. Dazu nutzt man am besten die SQL-Vorlagen für die Nachweisverwaltung in der Datei postgres_install.sql im Verzeichnis layouts/sql_dumps

Auswählen der Stelle Nachweisverwaltung

Wenn Sie die Nachweisverwaltung nutzen möchten, müssen Sie sich unter der richtigen Arbeitsstelle im Menü "Stelle wählen" anmelden.

Dazu öffnen Sie die Startseite des Kartenserver und klicken auf den Link "Menü auswählen" im rechten oberen Teil des Browserfensters.

Es öffnet sich ein Fenster mit der Auswahl der Arbeitsstellen. Markieren Sie hier bitte die Arbeitsstelle "Nachweisverwaltung" und klicken Sie auf den Button "Abschicken" der sich unter dem Auswahlfeld der Arbeitsstellen befindet.

Mit dem Button "Abbrechen" gelangen Sie wieder auf die Startseite des Kartenservers.

Nach der Auswahl der Arbeitsstelle "Nachweisverwaltung" und dem betätigen des Button "Abschicken" gelangen Sie auf die Oberfläche der Nachweisverwaltung. Im linken Teil des Browser-Fensters hat sich des Menu Ihrer Fachschale angepasst und im Kopf des Browser-Fensters steht nun "Nachweisverwaltung".

Schritt: Stelle wählen
Schritt: Arbeitsstelle markieren und abschicken
Schritt: Oberfläche der Nachweisverwaltung

Hinzufügen von Dokumenten

Um diese Funktion nutzen zu können, müssen Sie sich zuvor unter Nachweisverwaltung einwählen. Näheres finden Sie im Abschnitt "Einrichten der Stelle" beschrieben.

Als nächstes muss der Bereich für das einzupflegende Dokument eingerichtet werden. Dazu muss mir Hilfe der Navigationsellemente, im Grafikfenster, oder über den Menü-Punkt "Flurstücksuche" der ALK-Ausschnitt so einrichtet werden, das später das Polygon für den Raumbezug festgelegt werden kann.

Wenn Sie den ALK-Ausschnitt richtig festgelegt haben, finden Sie auf der rechten Seite des Browser-Fensters eine Menü Leiste mit der Rubrik Nachweisverwaltung. Kicken Sie den Menü-Punkt "Dokumente hinzufügen" unter der Rubrik Nachweisverwaltung an.

Jetzt erscheint die Oberfläche der Dokumenteingabe. Der ALK-Auschnitt muss bei diesem Schritt übernommen worden sein. In den übernommenen Ausschnitt sollte als erstes das Polygon mit den entsprechenden Werkzeugen im Grafikfenster festgelegt werden.

Danach folgt die Eingabe der beschreibenden Daten und die Wahl der Bilddatei für das einzupflegende Dokument. Hierbei ist zu beachten, das alle Eingaben getätigt und die hochzuladende Datei ausgewählt werden muss. Erst dann kann man den Datensatz mit dem Button "Senden" in die Datenbank einpflegen. Ist eine Eingabe fehlerhaft oder gar nicht angegeben worden, ändert sich die Hintergrundfarbe und es erscheint eine Fehlermeldung

Der Eintrag der Daten erfolgt in die Tabelle "n_nachweise", der jeweiligen Datenbank.

Sollte ein Nachweis mit einer Fehleingabe in die Datenbank eingepflegt worden sein, können Sie, wie unter "Ändern von Nachweisen" beschrieben, den Datensatz ändern.

Recherchieren von Nachweisen

Um diese Funktion nutzen zu können, müssen Sie sich zuvor unter Nachweisverwaltung einwählen. Näheres finden Sie im Abschnitt "Einrichten der Stelle" beschrieben.

Sind die erfolgreich unter der Arbeitsstelle Nachweisverwaltung angemeldet, erscheint im linken Teil des Browser-Fenster, unter Kategorie Nachweisverwaltung, der Menü-Punkt "Dokumentenrecherche".

Bevor Sie den Menü-Punkt anwählen, müssen Sie entscheiden, ob sie mit Hilfe eines Polygon (Box) recherchieren wollen. Ist das der Fall, müssen Sie zuvor den Kartenauschnitt mit Hilfe der "Flurstückssuche" oder der Graphikelemente im Grafikfenster zu dem entsprechenden Flurstück navigieren.

Wählen Sie jetzt den Menü-Punkt an und es öffnet sich die Oberfläche für die Dokumentenrecherche. Im Kopf steht "Dokumentenabfrage".

Zunächst, müssen Sie die Art der Nachweise auswählen, nach dem Sie recherchieren wollen wählen.

Als nächstes müssen Sie die Art der Recherche festlegen. Standardmäßig ist die Recherche mit Hilfe des Polygon (Box) eingestellt. Beachten Sie, das der Kartenausschnitt jetzt nicht mehr angepasst werden kann. Reicht der Kartenausschnitt für die Recherche nicht aus, müssen Sie erneut ins Menü "Nachweisverwaltung" wechseln und den Kartenausschnitt definieren.

Bei den weiteren Recherchemethoden kann entweder nach der individuellen Nummer eines einzelnen Nachweis gesucht werden oder nach den Nachweisen, die unter einer bestimmten Auftragnummer recherchiert wurden.

Nach dem das Polygon festgelegt ist und die Dokumnentenart ausgewählt wurde, kann man mit dem Button "Senden" die Recherche-Anfrage an die Datenbank senden.

Das Rechercheergebnis könnte wie folgt aussehen:

Mit dem Auswahl-Feld "markieren" oder "einblenden" unter dem Rechercheergebnis, können Sie durch Massenbearbeitung die Dokumentenarten im Rechercheergebnis entsprechend markieren/Markierung aufheben oder einblende/ausblenden. Mit dem Auswahl-Feld "markierte" können Sie die markeirten Nachweise entweder zu einer Auftragsnummer hinzufügen oder entfernen. Die Auftragsnummer muss zuvor über dem Rechercheergebnis ausgewählt werden.

Achtung: Beim hinzufügen von Nachweisen zu einem Auftrag, versichern Sie sich, das die Auftragsnummer über dem Rechercheergebnis richtig ausgewählt worden ist!!!

Für die Übersichtlichkeit können Sie die Spaltennamen des Rechercheergebnis anklicken und entsprechend das Recherchergebnis neu sortieren lassen.

Ändern von Nachweisen

Um Dokumente zu ändern muss eine recherche voraus gehen.

Recherchieren Sie den Nachweis, das einer Änderung unterzogen werden soll, wie zuvor unter "Recherchieren von Nachweisen" beschrieben.

In Ihrem Rechercheergebnis finden Sie das zuändernde Dokument, in diesen Zeile sich rechts außen drei Ikons für "Ansicht-()", "bearbeiten-()" und "löchen-()" befinden. Bewegen Sie den Maus-Cursor einfach auf eines der Ikons und kurz danach wird mittels ToolTip die Funktion des Ikons angezeigt.

Um ein Nachweis zu ändern, klicken Sie auf das Ikon "bearbeiten" in der Zeile des zu ändernden Nachweis der Rechercheergebnise. Sie gelangen zur Oberfläche der Dokumenteneingabe, wo die beschreibenden Daten zusammen mit den Raumbezug (Polygon) zu dem Nachweis angezeigt wird.

Die beschreibenden Daten und das Polygon können hier entsprechend, wie unter "Hinzufügen von Dokumenten" beschrieben, geändert werden. Um die Änderung zum Nachweis einzupflegen, betätigen Sie den Button "Senden". Wenn die korregierten Angaben richtig eingegeben sind, werden die Daten somit neu in die Datenbank eingepflegt. Kontrollieren Sie nach dem bearbeiten eines Nachweis Ihre Änderung!

Bodenrichtwerterfassung

Mit der Fachschale Bodenrichtwerte lassen sich flächenhafte Bodenrichtwertzonen nach dem BORIS-MV Datenmodell erfassen. Zum Datenmodell gehört eine Tabelle bw_zonen, in der die Datensätze gespeichert werden und einen View bw_boris_view, der zum Austausch der Bodenrichtwerte dient. Die entsprechenden SQL-Befehle zum Anlegen der Tabelle und des Views finden sich in /layouts/sql_dumps/postgis_install.sql bzw. /postgis_update.sql. Außerdem gehören zur Fachschale zwei Layer BORIS und BORIS_T. BORIS ist ein Polygonlayer, der die Bodenrichtwertzonen darstellt und BORIS_T ist ein Punktlayer, der nur für die Beschriftung der Bodenrichtwerte verwendet wird. Der Beschriftungsankerpunkt wird nämlich auch in der Fachschale erfasst. Die SQL-Skripte zum Erstellen der beiden Layer finden sich in der Datei /layouts/sql_dumps/mysql_install_help_boris.sql. Die Layer können auch anders heißen, wichtig ist nur, dass die Konstante LAYERNAME_BODENRICHTWERTE, auf den Namen des Flächenlayers der Bodenrichtwerte gesetzt ist.

Flächenversiegelung

Erfassung und Darstellung von Versiegelungsflächen auf der Grundlage von Luftbildern

Aufbau des PHP-Skript

Die Anwendung ist so programmiert, dass alle Aufrufe über die Datei index.php erfolgen. Die Seiten, die der Benutzer im Browser angezeigt bekommt, werden zur Laufzeit durch den Server zusammengesetzt.

index.php

Die Datei index.php startet mit dem Einbinden einer Konfigurationsdatei config.php und einer Startdatei start.php, unterscheidet und verzweigt in Anwendungsfälle mit einer switch-Anweisung und endet mit einer Enddatei end.php. Zur Unterscheidung der Anwendungsfälle nutzt das Skript den Parameter $go und $go_plus. Wenn $go_plus einen Wert enthält, wird dieser an $go angehängt. Wenn $go leer ist, wird ein Standardfall ausgeführt. In den jeweiligen Anwendungsfällen (cases), werden die entsprechenden Funktionen der Benutzeroberfläche als Methoden der Klasse GUI der Klassenbibliothek kvwmap.php aufgerufen.

config.php

Die Konfigurationsdatei enthält verschiedene Voreinstellungen zur Konfiguration der Anwendung, die in den PHP-Dateien verwendet werden. Die Voreinstellungen werden über das Setzen von Konstanten realisiert. Die Konstanten sind thematisch in Gruppen zusammengefasst und umfassen z.B. Einstellungen zu Dateipfaden, Layout und WMS-Capabilities Metadaten. Des Weiteren wird in der Konfigurationsdatei eingestellt, welche Klassenbibliotheken geladen werden sollen und diese eingebunden. Dazu gehört auch die Bibliothek php_mapscript.so bzw. dll. Außerdem wird ein Debugdatei-Objekt $debug aus der Klasse debugfile der Klassenbibliothek kvwmap.php mit einem vorgegebenen Debuglevel eingestellt, und Datenbankobjekte für den Zugriff auf die Benutzer-, Karten- und Geometriedaten initialisiert.

start.php

In der Startdatei wird zunächst das Objekt für die Benutzeroberfläche initialisiert. Die Klasse GUI für die Benutzeroberfläche ist in der Klassenbibliothek kvwmap.php enthalten. Anschließend werden alle an das Skript übergebenen Variablen aus der PHP-Systemvariable $_REQUEST an das Objekt $GUI in das Array $formvars übergeben. Wird die PHP-Anwendung über CLI aufgerufen, werden die Argumente aus der Kommandozeile an $formvars übergeben. In start.php kann eingestellt werden, das wievielte Argument an welches Element von $formvars übergeben werden soll. In weiteren Schritten werden die Datenbankobjekte an $GUI übergeben und geöffnet. Zur Identifizierung des zugreifenden Benutzers wird die vom Web-Server bereitgestellte PHP-Konstante REDIRECT_REMOTE_USER verwendet. An Hand von $login_name werden aus der Benutzerdatenbank alle Benutzerdaten ausgelesen und dem Objekt $user aus der Klassenbibliothek user.php zugewiesen, incl. der von ihm zuletzt genutzten Stelle. Soll beim aktuellen Aufruf keine neue Stelle eingestellt werden, wird diese Stelle für den Benutzer verwendet, ansonsten neu gesetzt. Vor dem Erzeugen des Stellenobjektes wird geprüft, ob der Nutzer auf die Stelle zugreifen darf. Abschließend wird für den Benutzer die Stelle als Rolle gesetzt, ein Menü-Objekt in $GUI->Menue initiiert und das Menü für die Stelle geladen. Je nach Einstellungen erfolgen zwischendurch Ausgaben in die Debug-Datei.

end.php

In der Datei end.php werden die offenen Datenbankverbindungen und die Debug-Datei geschlossen.

kvwmap.php

In der Klasse GUI sollten alle Funktionen enthalten sein, die die Interaktion des Benutzers mit dem Programm betreffen. Einige allgemeine Funktionen, wie das Lesen der Karteninformationen aus der Datenbank übernimmt die Klasse GUI, andere fachspezifische Aufgaben werden durch separate Objekte übernommen. Das gilt vor allem für die Funktionen der Fachschalen.

kvwmap mobil

Überblick

Mit kvwmap ist es möglich, auf einem mobilen Gerät, z.B. einem Tablet-PC oder Laptop, GPS-gestützt Daten zu erfassen. Diese Daten können dann anschließend auf den kvwmap-Hauptserver gespielt und mit den dort schon vorhandenen Daten synchronisiert werden. Auf dem mobilen Gerät wird ein eigener kvwmap-Server aufgesetzt, damit man komplett offline arbeiten kann und von keiner Internetverbindung abhängig ist. Um das mobile Gerät und den Server zu verbinden und die Daten zu synchronisieren, haben beide Maschinen eine gegenseitige PostgreSQL-Datenbankverbindung und können so Daten austauschen. Dokumente, wie z.B. Fotos werden über http ausgetauscht.

Voraussetzungen für die GPS-gestützte Erfassung

Um auf dem mobilen Gerät das GPS nutzen zu können, muss es entweder über einen eingebauten GPS-Empfänger verfügen oder es muss ein GPS-Empfänger per USB angeschlossen werden. Ist das GPS-Gerät installiert, ist es unter Windows über einen COM-Port (z.B. COM7) verfügbar. Damit kvwmap auf die Daten des GPS-Gerätes zugreifen kann, wird ein Programm benötigt, das die empfangenen GPS-Daten in eine Datei schreibt. Im Internet finden sich dazu diverse Programme. Am einfachsten ist es aber, das Abgreifen des Datenstroms über eine Batch-Datei mit folgendem Inhalt zu machen:

MODE COM7: baud=9600 parity=N data=8 stop=1
TYPE COM7 > "c:\PFAD\gpslog.txt"

Dieser Dateipfad im zweiten Befehl ist die Datei, in die die Daten geschrieben werden. Der Pfad muss in die config.php als Konstante „GPSPATH“ eingetragen werden. Damit das Loggen der GPS-Daten automatisch mit dem Systemstart beginnt, empfiehlt es sich, die Batch-Datei als Task einzurichten. In der config.php muss außerdem die Konstante „MOBILE“ auf „true“ gesetzt werden, damit man beim Einloggen die Möglichkeit hat, die GPS-Unterstützung auszuwählen.

Voraussetzungen für die Datenübertragung

Netzwerk, Firewall

Damit beide Rechner Daten austauschen können, muss jeder Rechner eine feste IP-Adresse besitzen und die Firewalls müssen entsprechende Ausnahmen für den Datenbank-Port 5432 (Eingang u. Ausgang) haben. Schliesst man das mobile Gerät an das Netzwerk, in dem sich auch der Server befindet an, sollten sich beide Maschinen gegenseitig sehen können.

Datenbankkonfiguration

Sowohl das mobile Gerät, als auch der kvwmap-Hauptserver müssen auf die PostgreSQL-DB des jeweils anderen zugreifen können. Dazu muss in der Datei „pg_hba.conf“ ein entsprechender Eintrag mit der IP-Adresse der anderen Maschine und der Authentifizierungsart „trust“ hinzugefügt werden. Auch der Zugriff auf die eigene Datenbank muss auf „trust“ gesetzt werden.

Beispiel:

local   all         all                               	        trust
# IPv4 local connections:
host    all         all         127.0.0.1/32          	        trust
host    all         all         andereIP/32             	trust
# IPv6 local connections:
host    all         all         ::1/128                   	trust

config.php

Auf jeder der beiden Maschinen muss es ein Synchronisationsverzeichnis geben, welches in der config.php durch die Konstante „SYNC_PATH“ definiert wird. Außerdem muss der Pfad zum bin-Verzeichnis von PostgreSQL gesetzt sein (POSTGRESBINPATH).

Layer und Tabellen

Um auf dem mobilen Gerät Geodaten erfassen zu können und diese dann mit den auf dem Server vorhandenen Daten zu synchronisieren, müssen die zu erfassenden Layer auf beiden kvwmap-Systemen vorhandenen und komplett identisch sein. Die von den Layern verwendeten Tabellen müssen identisch sein und auch die Schemata der Tabellen müssen gleich heißen. Um die Datenbankverbindung zwischen beiden Systemen herstellen zu können, gibt es zusätzlich zu den Layern, die auf die jeweils eigene PostgreSQL-DB zugreifen auch noch Layer, die auf die Datenbank der jeweils anderen Maschine zugreifen. Abbildung 1 stellt dieses Konzept an Hand des Beispiellayers „Baumkataster“ schematisch dar.

Abbildung 1: Konzept des gegenseitigen Datenbankzugriffs über Layer in kvwmap

Damit die Datensätze, die vom Hauptserver auf das mobile Gerät gespielt werden, für die weitere Bearbeitung gesperrt werden können, muss es in jeder Tabelle eine Spalte „lock“ vom Typ character varying(50) geben. Hier wird beim Auspielen der Daten vom Hauptserver eine Lock-ID gespeichert, die einerseits den Datensatz sperrt und es außerdem möglich macht, beim Einspielen der Daten vom mobilen Gerät, die geänderten Datensätze den vorhandenen zuzuordnen. Werden auch auf dem Hauptserver Daten erfasst, müssen die Tabellen außerdem noch eine Spalte „client_id“ vom Typ character varying(10) besitzen, die als Standardwert den Namen des kvwmap-Servers speichern. Also bspw. „server“ oder „mobil1“. Der Primärschlüssel einer solchen Tabelle ergibt sich in diesem Fall aus einer fortlaufenden Spalte, z.B. „id“ und aus der Spalte „client_id“. Dadurch ist gewährleistet, dass bei gleichzeitiger Erfassung auf beiden kvwmap-Servern, es beim Zusammenspielen der Daten zu keinem Konflikt durch gleiche „id“ Werte kommt. Wenn es Verknüpfungen (subformPK,…) zwischen Layern gibt, müssen hier als Verknüpfungsattribute auch beide Spalten (id, client_id) verwendet werden. Das Datenmodell der Tabelle für den Layer Baumkataster sieht z.B. folgendermaßen aus:

CREATE TABLE grunddaten_baum(
  baumid serial,
  baumnummer integer NOT NULL,
  status character varying(10) NOT NULL,
  baumart character varying(255),
  kontrollintervall character varying(50) NOT NULL,
  "lock" character varying(50),
  client_id character varying(10) NOT NULL DEFAULT 'server',
  the_geom geometry,
  CONSTRAINT baumid_client_id PRIMARY KEY (baumid, client_id),
  CONSTRAINT enforce_dims_the_geom CHECK (ndims(the_geom) = 2),
  CONSTRAINT enforce_srid_the_geom CHECK (srid(the_geom) = 25833)
)
WITH (OIDS=TRUE);

Enthält ein Layer Attribute vom Typ „Dokument“, um z.B. mit dem mobilen Gerät Fotos erfassen zu können, müssen diese auch beim Synchronisieren übertragen werden. Dazu muss auf jedem der beiden kvwmap-Systeme im Attributeditor für den jeweils fremden Layer im Optionenfeld des Dokumentattributes die Url der fremden Maschine mit folgendem Anwendungsfall eingetragen werden:

http://SERVER/kvwmap/index.php?go=sendeDokument&dokument=

Die Layer-Rechte werden so eingestellt, dass auf beiden Systemen Schreibrecht auf den eigenen Layern besteht. Die jeweils fremden Layer müssen nur Leserecht haben. Wichtig ist, dass auch die Spalte „lock“ auf lesend gesetzt wird und bei Layerverknüpfungen auch die Spalte „client_id“.

Aufspielen von Primärdaten auf den mobilen Client

Um bereits erfasste Daten vom Hauptserver auf das mobile Gerät zu spielen, gibt es den Anwendungsfall „go=export_layer“. Dieser sollte auf dem mobilen Gerät als Menüpunkt eingerichtet werden. Hat das mobile Gerät eine Netzwerkverbindung kann man den Menüpunkt aufrufen. Daraufhin erhält man ein Kartenbild und eine Legende mit allen externen Layern und allen gerade aktiven nicht-PostGIS-Layer (Abbildung 2). Man kann nun die Layer auswählen, von denen man Datensätze exportieren möchte. Wenn man auf „Neu Laden“ klickt, sollten die externen Layer in der Karte zu sehen sein. Ist dies nicht der Fall, funktioniert der Datenbankzugriff mobiles Gerät  Server möglicherweise nicht (siehe Abschnitt 3). Um die Datensätze räumlich einzugrenzen, wird ein Polygon gezeichnet. Zusätzlich kann man noch auswählen, ob die Tabellen auf dem mobilen Gerät geleert werden sollen, was zu empfehlen ist. Um auch Dokumente zu übertragen, muss man die Anmeldedaten für den Login am mobilen Gerät eingeben, da diese für die http-Übertragung der Dokumente benötigt werden. Ist alles richtig eingestellt, kann man auf „einlesen“ klicken.

Abbildung 2: Anwendungsfall Primärdaten auf das mobile Gerät einlesen

Die Datensätze der ausgewählten Layer, die sich innerhalb des Polygons befinden, werden dadurch auf das mobile Gerät übertragen. Gleichzeitig werden die Datensätze auf dem Hauptserver gesperrt, was zum einen bewirkt, dass sie nicht noch einmal übertragen und außerdem nicht mehr editiert werden können. Die Sperrung bleibt solange erhalten, bis die Datensätze wieder vom mobilen Gerät auf den Hauptserver zurückgespielt werden.

Datenerfassung mit dem mobilen Client

Um für die Geodaten-Erfassung mit dem mobilen Gerät GPS-Unterstützung zu erhalten, muss im Anmeldefenster von kvwmap die Option „mobil“ ausgewählt werden. Nach der Anmeldung sollte im Kartenfenster ein zusätzlicher Button „GPS“ erscheinen. Mit diesem Button kann man die GPS-Verfolgung ein- oder ausschalten. GPS-Verfolgung heißt, dass, sobald sich die GPS-Position aus dem Kartenausschnitt bewegt, der Kartenausschnitt wieder auf die GPS-Position verschoben wird. Ist in der Karte keine GPS-Position als rotes Fadenkreuz zu erkennen, kann die GPS-Verfolgung aktiviert werden und es sollte dann auf die GPS-Position gezoomt werden. Ist dies nicht der Fall, werden möglicherlicherweise keine gültigen GPS-Positionsdaten in die GPS-Logdatei geschrieben (siehe Abschnitt 2). Im Geometrie-Editor gibt es 2 neue Buttons. Der erste ist der schon bekannte „GPS-Verfolgsmodus“. Der zweite „GPS“-Button dient dazu, die aktuelle Position als Koordinate für die Digitalisierung zu verwenden. Dadurch kann man z.B. die Grenzen eines zu erfassenden Gebietes ablaufen und nacheinander die Positionen als Stützpunkte des Polygons übernehmen (Abbildung 3). Alle anderen Funktionalitäten bei der Datenerfassung können in der gleichen Weise wie beim normalen kvwmap auch verwendet werden.

Abbildung 3: GPS-gestützte Erfassung einer Fläche

Synchronisation der erfassten Daten mit dem Server

Nach der mobilen Datenerfassung können die Daten wieder vom mobilen Gerät auf den kvwmap Hauptserver gespielt werden. Dazu wird das mobile Gerät an das Netzwerk angeschlossen und auf dem Hauptserver wird der Anwendungsfall „go=import_layer“ aufgerufen. Dadurch erhält man eine ähnliche Maske wie beim Auslesen der Daten (Abbildung 4). Hier kann man wieder die externen Layer, die nun auf das mobile Gerät zugreifen, auswählen und die Verbindung in der Karte überprüfen. Außerdem kann die Dokumentenübertragung wieder optional aktiviert werden. Nach dem Klick auf „importieren“ werden die Daten vom mobilen Gerät auf den Hauptserver übertragen. Dabei werden zum einen die neu erfassten Daten als neue Datensätze auf dem Server angelegt. Die zuvor vom Hauptserver auf das mobile Gerät überspielten und dort möglicherweise editierten Daten werden auch auf den Hauptserver übertragen und dort aktualisiert. Dabei werden die Sperrungen der Datensätze entfernt. Wurden Datensätze auf dem mobilen Gerät gelöscht, werden diese auch auf dem Hauptserver gelöscht.

Abbildung 4: Zurückspielen der erfassten Daten auf den Server

Installation

Die Installation einer lauffähigen Umgebung kann auf einem Linux- oder einem Windows-Server erfolgen. Für Windows-Server steht das ms4w-Paket zur Verfügung. Bei Linux-Servern kann die Installation der Komponenten einzeln erfolgen (hoher Zeitaufwand, aber bestmögliche Anpassung) oder über das FGS-Paket (geringer Zeitaufwand, ausreichende Anpassungsmöglichkeiten).

Voraussetzungen

In diesem Abschnitt wird eine Übersicht darüber gegeben, was alles für kvwmap installiert werden sollte bzw. aus welchen Komponenten die Anwendung besteht.

Folgende Komponenten werden für die Nutzung dieses Internet-GIS vorausgesetzt:

Serverseite

Apache - Es ist eine Version >= 2.0.48 eingesetzt werden, damit die Umgebungsvariable REDIRECT_REMOTE_USER genutzt werden kann. Diese wird zur Identifizierung des Nutzers verwendet. (siehe auch Apache bug-report)

Session sollte z.Z. noch aktiv geschaltet werden, aber die Anwendung wird umgestellt, so dass sie ohne Session läuft und alle relevanten Parameter der Benutzer in der Datenbank zwischengespeichert werden.
PHP - Die Entwicklung von kvwmap läuft derzeit auf der Version 4.3.7

Zur Konfiguration von php wurden in unserem Beispiel folgende Parameter gesetzt.

./configure --enable-force-cgi-redirect --with-config-file-path=/opt/lampp/etc --with-regex=system *:--with-gd=/usr/local/gd --with-freetype-dir=/usr/local/freetype --enable-gd-native-ttf *:--with-png-dir=/usr/local/libpng --with-jpeg-dir=/usr/local/libjpeg --with-zlib --with-zlib-dir=/usr/local/zlib *:--enable-dbase –with-pgsql=/usr/local/pgsql

Diese Parameter müssen Sie an Ihr System anpassen oder ggf. ergänzen.

Ob PHP richtig kompiliert wurde erkennen Sie durch die Ausgabe eines phpinfo() Befehls. Erzeugen Sie dazu eine Datei mit folgendem Inhalt in einem Verzeichnis unterhalb von wwwroot.

     <?php
       phpinfo();
     ?>

oder fügen Sie dieses Programmschnipselchen in eine andere php Datei ein.

Das sollte dann eine Ausschrift erzeugen, die folgendes beinhaltet:

PHP Version 4.3.10

System	Linux berg 2.6.5-7.97-smp #1 SMP Fri Jul 2 14:21:59 UTC 2004 x86_64
Build Date	Jul 20 2005 18:31:02
Configure Command	'./configure' '--enable-force-cgi-redirect' '--with-regex=system' '--enable-dbase' '--with-pgsql=/usr/local/pgsql' '--with-gd=/usr/local/gd'
Server API	CGI

In Configure Command sollte --with-pgsql=… stehen und weiter unten:

GD Support	enabled
GD Version	2.0 or higher
GIF Read Support	enabled
GIF Create Support	enabled
JPG Support	enabled
PNG Support	enabled
WBMP Support	enabled

mysql

MySQL Support	enabled
Active Persistent Links	0
Active Links	0
Client API version	3.23.49
MYSQL_MODULE_TYPE	builtin
MYSQL_SOCKET	/tmp/mysql.sock
MYSQL_INCLUDE	no value
MYSQL_LIBS	no value

pgsql

PostgreSQL Support	enabled
PostgreSQL(libpq) Version	8.0.1
Multibyte character support	enabled
SSL support	enabled
Active Persistent Links	0
Active Links	0

Directive	Local Value	Master Value
pgsql.allow_persistent	On	On
pgsql.auto_reset_persistent	Off	Off
pgsql.ignore_notice	Off	Off
pgsql.log_notice	Off	Off
pgsql.max_links	Unlimited	Unlimited
pgsql.max_persistent	Unlimited	Unlimited

Darin erkennt man ob MySQL, GD und PostgreSQL wirklich unterstützt werden und z.B. welche PostgresSQL-Version unterstützt wird.

Wenn die Angaben z.B. zu pgsql nicht zu finden sind, sollte man php mit --with-pgsql=/pgsql-install-pfad neu kompilieren und wieder die entstandene PHP aus /usr/local/php/sapi/cgi ins cgi-bin Verzeichnis vom Webserver kopieren und neu testen.

Wenn das auch nichts bringt, greift das Lampp vielleicht auf eine ganz andere php zu, z.B. auf eine dynamisch geladene Bibliothek (libphp4.so). Testen durch das umbenennen von php in cgi-bin in php-bla. Danach sollte die Fehlermeldung vom Apache kommen, dass er die php-Datei nicht ausführen kann, oder der Quellcode gesendet werden, was dem gleich kommt. Dann suchen nach dem wahren Ort wo lampp php ausführt.

Informationen darüber findet man in den Anleitungen zum Ausführen von php in

Apache. In der httpd.conf steht zum Beispiel:

LoadModule php4_module modules/libphp4.so Um pgsql in libphp4.so nutzen zu können müsste man die pgsql Unterstützung eben da hinein kompilieren. Alternativ dazu steht die Variante php als cgi-Version einzurichten mit den entsprechenden Optionen in der httpd.conf:

Action php-script /cgi-bin/php

AddHandler cgi-script .cgi

AddHandler php-script .php .php3

Dann könnte man also php als CGI-Version kompilieren mit:

--with-regex=system

Dazu zur Sicherheit gibt man an:

--enable-force-cgi-redirect

Um anzugeben, wo die Konfigurationsdateien zu finden sind: --with-config-file-path=/opt/lampp/etc

Nach dem Kompilieren von PHP gegebenenfalls php.ini anpassen:

short_open_tag = On            - erlaubt den verkürzten Tag für php 
session.auto_start = 1          - für Authentifizierung über PHP notwendig
session.gc_maxlifetime = xxxx  - Länge der php-Session in Sekunden

gd - wenn die Druckrotation funktionieren soll, gd nicht selbst kompilieren, sondern PHP kompilieren mit --with-gd
MapServer - Version ab 5.x wird empfohlen

Zur Konfiguration von MapServer und damit auch phpMapScript wurden folgende Parameter gesetzt:

OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP SUPPORTS=PROJ SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT INPUT=EPPL7 INPUT=POSTGIS INPUT=GDAL INPUT=SHAPEFILE

Welche Optionen für configure wirklich notwendig sind, hängt davon ab welche Datenarten und welche Services der MapServer unterstützten soll.
phpMapScript - ist in der Version: 1.194.2.3

phpMapScript wird mit installiert, wenn die Option –with-php angegeben wird.
PDFClass – installieren in www-root Verzeichnis

Quelle: http://www.ros.co.nz/pdf/
Imagemagick und Ghostscript - zur Druckvorschau und Bildkonvertierung, siehe Installation von ImageMagick mit JPEG-, PNG- und TIF-Unterstützung
MySQL – irgendeine aktuelle Version, verwende noch Tabellentyp MyISAM, wer Transaktionen machen will braucht eine Version die InnoDB unterstützt.
phpMyAdmin

Zur Administration der MySQL Datenbank kann phpMyAdmin installiert werden. Jedes andere DB-Frontend mit ODBC-Treiber für MySQL ist natürlich auch möglich. Ich benutze z.B. auch MS-Access mit MySQL-ODBC.
PostgreSQL - Version 8.x. Ab 8.3 ist die Typgleichheit bei Vergleichen zu beachten.

Clientseite

Browser
- Firefox ab Version 4.0 (empfohlen)
- oder Internet Explorer ab Version 7 plus SVG-Plugin [SVG Viewer download]
- oder Chrome
- Erfahrungen mit anderen Browsern sind willkommen
- im Browser muss JavaScript eingeschaltet sein und man muss die Änderung des Textes in Stauszeile durch JavaScript in FireFox zulassen.

pgAdmin III

Zur Administration von PostgreSQL würde ich pgAdminIII empfehlen, aber es geht natürlich auch pgMyAdmin oder andere DB-Frontends mit ODBC für MySQL, z.B. MS-Access

Quelle: http://www.pgadmin.org
ODBC-Treiber für PostgreSQL

Für den Zugang zum Server von einem lokalen Recher aus, muss der ODBC-Treiber für PostgreSQL installiert werden.

Quelle: http://www.postgresql.org/ftp/odbc/versions
PostGIS – aktuellste Version mit der modifizierten shp2pgsql aus dem Ordner kvwmap/tools
EDBS2WKT

Konverter zum Einlesen von ALK-Daten in die postgresql Datenbank.

Quelle: http://62.153.231.87/alk/edbs2wkt

Vor dem Einlesen von ALK-Daten in die PostGIS-Datenbank sollte eben PostgreSQL mit PostGIS unterstützung installiert sein.

UMN-MapServer

Hinweise zur Installation des UMN-MapServers finden Sie unter: http://mapserver.gis.umn.edu/docs

Siehe auch: http://wiki.osgeo.org/index.php/Installation_von_MapServer%2C_Apache_und_PostgreSQL/PostGIS_auf_Debian_4.0 http://en.giswiki.org/wiki/UMN_MapServer_Installationsanleitung_von_Kai_Behncke http://freegis.org/pipermail/mapserver-de/2005-July/001408.html

UMN MapServer für Linux ist im Packet FGS und für Windows im Packet ms4w enthalten. Siehe dazu unter: http://www.maptools.org/fgs bzw. http://www.maptools.org/ms4w/

PostgreSQL mit PostGIS Erweiterung

PostgreSQL

Laden Sie sich PostgreSQL von http://www.postgresql.org

Zur Installation von PostgreSQL lesen Sie die INSTALL-Anweisung im Installationsverzeichnis von postgresql. Führen Sie aber zur Nutzung von Geos den configure Befehl folgendermaßen durch:

> LDFLAGS=-lstdc++ ./configure

an Stelle von einfach nur

> ./configure

Danach

> make

> make install

Zum Einrichten der Datenbank für kvwmap

> adduser postgres

Oft ist schon ein postgres user im system vorhanden, dann lassen.

Datenverzeichnis anlegen

> mkdir /usr/local/pgsql/data

Verzeichnis dem user postgres zuweisen

> chown postgres /usr/local/pgsql/data

Wechseln zum user postgres (als postgres anmelden)

> su – postgres

Datenbank initialisieren

> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data

Postmaster starten. (Diese Zeile in Startskript von Rechner aufnehmen, sonst immer nach Neustart von Server neu starten)

> /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1 &

Kvwmap Datenbank anlegen.

> /usr/local/pgsql/bin/createdb <Datenbankname>

Als Datenbankname geben Sie den Namen an, den Sie in der config.php im kvwmap-Verzeichnis an die Variable $pgdbname übergeben haben. Z.B. kvwmapsp1-4-2

Zum Testen in Datenbank einloggen.

> /usr/local/pgsql/bin/psql kvwmapsp1-4-2

Alle Programme für postgres befinden sich in /usr/local/pgsql/bin.

Am besten den Pfad anpassen.

> export PATH=$PATH:/usr/local/pgsql/bin

Konfiguration:

Der Datenbankserver von PostgreSQL wird über die Datei postgres.conf konfiguriert. Diese Datei befindet sich im mit „initdb –D Verzeichnis“ angelegten data-Verzeichnis, z.B. in /usr/local/pgsql/data. Wenn was nicht funktioniert, kann man mal dort nachschauen, ob alles korrekt eingestellt ist. z.B. wenn der Zugang zur pgsql Datenbank von einem entfernten Rechner aus mit pgAminIII nicht funktioniert liegt das entweder daran, dass die Firewall den Port 5432 nicht frei gibt, oder die Verbindungen nur vom localhost erlaubt sind. Das kann man mit dem Parameter listen_addresses einstellen in der postgres.conf. Für den Zugriff von entfernten Rechner muss für Postgres der Port 5432 offen sein (entsprechend /etc/services). In /etc/hosts sollte der Rechner eingetragen sein, der zugreifen will. In /etc/hosts.allowed können auch Zugangsbeschränkungen eingetragen werden.

Projektdatenbank: Zur Einbindung von ALK-Daten in eine PostGIS-Datenbank sollte mit EDBS2WKT zunächst eine Datenbank neu erstellt werden, die die Tabellen für die ALK-Objekte enthält. Damit man diese Postgres-Datenbank dann mit kvwmap zusammen nutzen kann, muss man das Skript postgis_install.sql aus dem Verzeichnis /layouts/sql_dump von kvwmap in postgres ausführen. Danach sollten alle relevanten Tabellen in der Datenbank enthalten sein.

PROJ

Wenn Sie PROJ noch nicht für UMN-MapServer installiert haben, laden Sie sich PROJ von http://www.remotesensing.org:16080/proj

Entpacken von proj-version.tar.gz nach /usr/local

Erzeugen eines symbolischen Links:

ln –s proj-version proj

Installieren mit:

./configure

make

make install

GEOS

Laden Sie sich GEOS von http://geos.refractions.net

Entpachen von geos-version.tar.gz nach /usr/local

Erzeugen eines symbolischen Links:

ln –s geos-version geos

Installieren mit

./configure

make

make install

PostGIS

Man muss den PostgreSQL Source haben und PostgreSQL installiert haben.

Laden Sie sich PostGIS von http://postgis.refractions.net

Folgen Sie der Installationsanleitung in README.postgis

Zur Aktivierung der PROJ und GEOS Unterstützung in Makefile.config USE_PROJ und USE_GEOS auf 1 setzen und als Pfade /usr/local angeben.

Installieren mit: make -> make install

Zur Einrichtung der PostGIS Erweiterung für die kvwmap Datenbank:

createlang plpgsql <Datenbankname>

psql -f lwpostgis.sql -d <Datenbankname>

Als Datenbankname geben Sie den Namen an, den Sie in der config.php im kvwmap-Verzeichnis an die Variable $pgdbname übergeben haben. Z.B. kvwmapsp1-4-2

Anlegen der Tabellen für die Koordinatensysteme

pgsql –f spatial_ref_sys.sql

Es muss auch ein Benutzer angelegt sein, mit dem Sie von kvwmap aus auf die Datenbank zugreifen. Nutzer hinzufügen:

createuser –P <Benutzername>

<Benutzername> ist der Name unter dem Sie auf die Datenbank von kvwmap aus zugreifen, z.B. kvwmap Anschließend werden Sie nach einem Passwort <Passwort> für den Nutzer gefragt. Der hier angegebene Name bzw. Passwort wird dann in der config.php im kvwmap Verzeichnis auf die Variable $PostGISdb->user=’<Benutzername’ bzw. $PostGISdb->passwd='<Passwort>' gesetzt. 2.3.5 Datenbank Sichern und Wiederherstellen

Eine PostGIS Datenbank lässt sich mit dem pg_dump Befehl sichern. Dabei wird eine sql-Datei erzeugt, die später zur Wiederherstellung eines alten Standes verwendet werden kann. Um die Sicherung ausführen zu können melden Sie sich am Besten auf Ihrer Konsole als postgres an.

su postgres

Anschließend wechseln Sie in ein Verzeichnis, in dem postges Schreibrechte hat, z.B.

cd /usr/local/pgsql/data

Dort führen sie den dump Befehl aus.

../bin/pg_dump -f <dateinamedersicherung.sql> <datenbankname>

Zum wiederherstellen müssen Sie die alte Datenbank löschen.

dropdb <datenbankname>

Anschließend legt man die Datenbank wieder an, fügt den PostGIS Support und die Referenzsystem hinzu und läd dann die Sicherung ein.

createdb <datenbankname>

createlang plpgsql <datenbankname>

psql -f postgis.sql -d <datenbankname>

psql –f spatial_ref_sys.sql –d <datenbankname>

psql -f <dateinamedersicherung.sql> -d <datenbankname>

vacuumdb -z <datenbankname>

Die Dateien postgis.sql und spatial_ref_sys.sql befinden sich in dem share Verzeichnis des pgsql Verzeichnisses. Die letzte Zeile dient dem Auffrischen der Tabellen und der Neuorganisation der Indizee und des Speicherplatzes.

MySQL

Installieren Sie auf Ihrem System einen MySQL Server. Folgen Sie den Installationsanleitungen unter: http://dev.mysql.com/doc/index.html Führen Sie zum einrichten der der kvwmap-Tabellen die Datei mysql_install.sql aus dem Verzeichnis /layouts/sql_dump

Schritte zur Installation von kvwmap

Um kvwmap nutzen zu können müssen die oben beschriebenen Komponenten installiert sein.

Nachfolgend werden die Schritte beschrieben, die absolviert werden sollten, damit man im Client eine Karte sehen kann. Dazu gehören einige Einstellung die den Server betreffen. Diese werden in der Datei config.php vorgenommen. Die meißten Einstellungen werden über Konstanten vorgenommen. Wenn noch Einstellungen vorgenommen werden müssen, die irgentwo anders im Quellcode fest verankert sind lassen Sie es mich wissen, dann baue ich das auch als Konstane in die config.php ein.

Und es sind eine Reihe von Eintragungen in der MySQL-Datenbank vorzunehmen, z.B. das Anlegen einer Steller, Benutzer, Layer, Menüpunkte etc.

Verzeichnisse

Entpachen sie das Packet kvwmap_Version in das www-root
In www-root (z.B. /usr/local/httpd/htdocs) sollten folgende zusätzlichen Verzeichnisse angelegt werden:
/tmp – für die dynamisch generierten Bilder vom MapServer. Dies ist der Pfad der in der MapDatei für IMAGEPATH steht.
Auf der gleichen Ebene wie www-root (z.B. /usr/local/httpd) sollten folgende Verzeichnisse angelegt werden.
/logs – Log- und Debugdateien lässt sich in config.php ändern
/var – Datenverzeichnis, lässt sich auch in config.php anpassen.
Unter dem Verzeichniss var legen sie standardmäßig /data an und darunter die Verzeichnisse für Ihre Daten

config.php

Eine Reihe von Einstellungen für das Programm kann über die Werte von Konstanten in einer zentralen Konfigurationsdatei der config.php in der Wurzel des Programmverzeichnisses erfolgen. Im folgenden werden die definierten Konstanten und ihre aktuell eingestellten Werte angezeigt. Die Standardwerte stehen in Klammern dahinter. Einige Werte setzen sich aus anderen zusammen. Die Konstanten und Werte sind mit Punkt getrennt. Die Punkte gehören nicht zum Wert.

INSTALLPATH = /opt/lampp/ (/opt/lampp/)
WWWROOT = /opt/lampp/htdocs/ (INSTALLPATH.htdocs/)
URL = 139.30.110.27/ (localhost)
LOGPATH = /opt/lampp/logs/ (INSTALLPATH.logs)
LAYOUTPATH = /opt/lampp/htdocs/kvwmap_1.4.0/layouts/ (WWWROOT.APPLVERSION.'layouts/)
SNIPPETS = /opt/lampp/htdocs/kvwmap_1.4.0/layouts/snippets/ (LAYOUTPATH.snippets/)
diese Liste ist unvollständig

Datenbankeinträge für die Anzeige im Client

Um in der Benutzeroberfläche des kvwmap-Clients überhaupt etwas sehen zu können, müssen mindestens eine Stelle und ein Benutzer eingetragen werden und ein Layer angelegt sein. Eine Beschreibung zur Verwaltung von Benutzerdaten und Karteninformationen finden Sie unter Abschnitt 5.

Installation mit ms4w

Hier wird die Installation von kvwmap unter MapServer für Windows (ms4w) beschrieben.

Voraussetzung ist das aktuelle Packet von ms4w, download unter: http://www.maptools.org/ms4w/

Installation mit fgs

Hier wird die Installation von kvwmap in der Free OpenSource GIS Suite (fgs) beschrieben.

Voraussetzung ist das aktuelle Packet von fgs, download unter: http://dl.maptools.org/dl/fgs/releases/1.0/1.0.0/self-installers/

--Markus Hentschel 16:53, 25. Jul 2007 (CEST)

Vorteil FGS: sehr leichte Installation, leichte Nachinstallation von weiteren Komponenten.

Nachteil FGS: einige Funktionalitäten gehen nicht, weil alle Komponenten vorkompiliert sind und nicht geändert werden können. Beispiel: Druck rotieren geht nicht. Bei Mapserver < 5.0: Mapserver ist mit den Standardeinstellungen der map.h und mapsymbol.h kompiliert, z.B. MS_MAXIMAGESIZE_DEFAULT=2048 oder MS_MAXSYMBOLS=64 (In der neuesten FGS-Version 1.0 nicht mehr nötig).

--Pkorduan 14:09, 28. Okt 2007 (CET)

Weiterer Nachteil bei Version 0.2: Das Modul postgis-lib:1.0.6 ist ohne proj Unterstützung kompiliert. Selbst von das proj-lib Modul für fgs installiert ist, kann postgis trotzdem keine transformationen rechnen. Der SQL Befehl transform() funktioniert nicht und somit auch keine Koordinatentransformationen mit PostGIS on-the-fly. (Hat nichts mit MapServer zu tun. Der transformiert fleißig mit Proj) Wenn man kvwmap mit Layern in unterschiedlichen EPSG-Codes verwenden möchte, dann muss PostGIS transformieren können. Der Parameter USE_PROJ=1 muss für postgis gesetzt sein. Man muss also in dem Fall postgis für fgs neu kompilieren (In der neuesten FGS-Version 1.0 nicht mehr nötig).

Zum Installieren von FGS bzw. von Modulen innerhalb der FGS-Umgebung siehe auch drei HowTo's:

FGS installieren

Mapserver in der fgs-dev Umgebung kompilieren

PostGIS in der fgs-dev Umgebung kompilieren

Administration

Stelle

Stelle anlegen

Zum Anlegen einer neuen Stelle kann der Menüpunkt „Stelle Anlegen“ aus der Menügruppe „Stellenverwaltung“ verwendet werden.

Zu einer Stelle können neue Menügruppen, Layer und Benutzer hinzugefügt werden.

z.Z. können nur ganze Gruppen von Menüs hinzugefügt werden. Wenn einzelne Menüpunkte hinzugefügt werden sollen, am besten den Menüpunkt in der Tabelle

u_menues anlegen und einer Gruppe zuordnen, Reihenfolge beachten. Anschließend diese Gruppe aus der Stelle löschen und wieder neu hinzufügen. Dann werden

alle Untermenüs auch zu der Stelle übernommen.

Die Rechte der Nutzer in den Stellen werden allgemein durch die Zuordnung der Layer und Menüpunkte geregelt. Die Rechte an extra in der Tabelle

u_funktionen eingetragenen Funktionen müssen extra in die Tabelle u_funktionen2stelle eingetragen werden.

Stellen anzeigen

Über den Menüpunkt „Stellen anzeigen“ der Menügruppe Stellenverwaltung können Stellen angezeigt werden, gelöscht und geändert werden.

Stellen ändern

Zur Änderung von Stellen siehe „Stelle anlegen“.

Maximale Ausdehnung des Kartenfensters für eine Stelle ändern

Die Koordinaten für die maximale Ausdehnung des Kartenfensters einer Stelle läßt sich über die Angaben zu minxmax, minymax, maxxmax, maxymax in der

Tabelle stelle in der Zeile der entsprechenden Stelle ändern.

Neben der maximalen Ausdehnung kann über das Setzen von Filtern (siehe Tabelle 'used_layer' -> Filter) der Inhalt von Layern, dessen Objekte in der

PostgreSQL-Datenbank gehalten werden, stellenbezogen weiter eingeschränkt werden.

Einschränkung der Stellen bezüglich Inhalt des Kartenfensters und entsprechender räumlicher Anfragen, die mittels Raumbezug (Polygon) zuvor festgelegt

werden können, befindet sich z.Z. in der Entwicklung und wird in der nächsten Version zur Verfügung stehen!

Filterverwaltung

Die Filterverwaltung ermöglicht nicht nur das stellenbezogene räumliche bzw. inhaltliche Einzuschränken von Layern, sondern auch deren Sachdaten.

Dazu wählt man den Menüpunkt „Filterverwaltung“ (go-Variable: "Filterverwaltung"). Hier wird als nächsten Schritt die entsprechende Stelle und dann der betroffene Layer mit Hilfe der Auswahllisten gewählt. Damit wird eine Liste von Attributen geladen, über die der Layer eingeschränkt werden kann.

Zu jedem Attribut kann jetzt ein Wert festegelegt werden, um den der Layer eingeschränkt werden soll. Mit den Operatoren lassen sich die Einschränkungen noch flexibler gestallten, wie in den folgenden Beispielen gezeigt wird:

1. In diesem Beispiel werden nur Informationen vom Layer ausgegeben, die den Wert „132100“ im Attribut „gemkgschl“ aufweisen.

2. Wie in diesem Beispiel können den Werten auch Platzhalter hinzugefügt werden. Hier werden all Layerinformationen ausgegeben, die im Attribut „gemkgschl“ mit dem Wert „1321“ beginnen. Platzhalter lässt sich beliebig verschieben.

Ist einem Layer eine Geometrie zugeordnet, wird in der Liste der Attribute „the_geom“ geladen. In dem Fall ist es möglich die Einschränkung zum Layer räumlich durch ein Polygon festzulegen. Dazu wählt man als Wert „Polygon“ ( ) an und legt im Anschluss das Polygon im Kartenfenster fest. Als Operator kann man zwischen „Intersects“ oder „Within“ wählen. „Intersects“ schränkt die Objekte des Layers räumlich so ein, dass alle Objekte die vom Polygon geschnitten oder innerhalb des Polygons liegen abfragbar sind und dargestellt werden. Der „Within“-Operator stellt dabei nur die Objekte dar, die zu 100% innerhalb des Polygons liegen.

Als letzter Schritt müssen die Einstellungen noch mit dem „Speichern“-Button gesendet bzw. gespeichert werden.

Um die Einschränkungen eines Layer zu ändern, löscht man die entsprechenden Werte zu den Attributen oder ersetzt diese durch neue Werte. Im Falle einer räumlichen Einschränkung durch ein Polygon reicht es, wenn der Wert „Polygon“ zum Attribut „the_geom“ deaktiviert und die Änderung gespeichert wird. Um ein Polygon neu zu übernehmen, aktiviert man den Wert „Polygon“, löscht das geladene Polygon und legt ein neues Polygon fest, dass dann wieder gespeichert wird.

Die Attribute, die geladen werden entsprechen den Attributen, die in dem select-Statement der Tabelle „layer“ in der Spalte „data“ zu einem Layer eingetragen sind. Soll ein Layer durch zusätzliche Attribute eingeschränkt werden, muss das select-Statement um diese Attribute erweitert werden.

Statt einem festen Wert lässt sich auch die Varibale $userid verwenden, welche bei Anwendung des Filters durch die jeweilige Nutzer-ID ersetzt wird. In Kombination mit dem Formularelementtyp UserID wird es dadurch möglich, einen Fiter zu definieren, durch den jeder Nutzer nur seine eigenen Datensätze sehen, abfragen und bearbeiten darf.

Stellen ohne Authentifizierung

In kvwmap können mehrere Stellen eingerichtet werden, die jeder Benutzer ohne vorherige Authentifizierung aufrufen kann. Diese werden im Folgenden Gast-Stellen genannt. Zur Einrichtung sind folgende Einstellungen notwendig:

In der Konfigurationsdatei config.php ist für die Konstante GAST_STELLE ein Array mit ID's einzutragen, die als Gast-Stellen fungieren sollen. z.B. für die Stellen mit der id 1 und 35:

$gast_stellen = array(1, 35);

In der stellenbezogenen Layereinstellung kann festgelegt werden welche Layer eingeschaltet sein sollen, wenn sich ein Nutzer die Stelle als Gast aufruft. Dazu "Stellen anzeigen" dann "Layer" der entsprechenden Stelle auswählen und auf "Ändern" in der Spalte "Eigenschaften stellenbezogen" klicken. Für aktiv bei Gast kann dann ja oder nein ausgewählt werden, siehe Abbildung.

Man kann sich aus einer Gast-Stelle wieder ausloggen über den passenden im Menü befindlichen Menüpunkt oder über den Parameter go=logout. Nach dem ausloggen landet der Nutzer auf der Anmeldeseite von kvwmap.

Ist ein Gast-Stelle eingerichtet, kann diese wie folgt genutzt werden:

Aufruf der URL von kvwmap mit dem zusätzlichen Parameter gast. Als Wert für den Parameter gibt man die ID der Stelle an, die man als Gast benutzen möchte. z.B.: http://www.gdi-service.de/kvwmap/index.php?gast=35
Der Kartenausschnitt der aufgerufenen Stelle stellt sich beim Aufrufen der Seite auf die maximale Ausdehnung der Stelle ein.
Es sind alle Layer aktiv, die in den stellenbezogenen Layereigenschaften der Gaststelle unter "aktiv bei Gast" auf "ja" gesetzt wurden.
Es sind alle Layergruppen geöffnet, in denen sich aktive Layer befinden.
Ruft ein neuer Gastnutzer kvwmap auf, wird für diesen in der Tabelle user ein neuer Nutzer mit dem Attribut Funktion="gast" angelegt. Dieser Nutzer wird solange genutzt, wie die Session im Browser gilt. Meldet sich der Nutzer aktiv ab oder schaltet den Browser aus, wird beim nächsten Aufruf der Gaststelle wieder ein neuer Gastnutzer angelegt.
Da die Anzahl der Nutzer in der Tabelle user durch Gastnutzer schnell ansteigen kann, sollte die Tabelle regelmäßig, möglicherweise auch durch ein Cron-Job von den Gast-Nutzern bereinigt werden. Dazu kann folgendes SQL-Statement verwendet werden:

DELETE FROM `user` WHERE `Funktion`='gast'

Nutzerverwaltung

Authentifizierung über PHP

Seit der Version 1.6.5 erfolgt die Authentifizierung über PHP und die für die Nutzereinstellungen verwendete MySQL Datenbank. Das PHP Skript prüft ob ein Benutzer sich bereits authentifiziert hat, wenn nicht, erscheint ein Dialog zur Eingabe von Benutzername und Passwort. Nach absenden diese Formulares wird in der MySQL Datenbank von kvwmap nachgesehen ob der Benutzername zum Passwort passt.

Wenn ja, wird der Benutzername in einer Sessionvariable gespeichert und für die Session immer mitgeführt. Damit die Sessionfunktion für PHP auch funktioniert, muss in der php.ini die Variable session.auto_start=1; gesetzt sein. Danach erfolgen die weiteren Prüfungen, die aber dann genauso wie die Prüfung der Authentifizierung immer wieder ausgeführt werden. Erst wenn man sich eine bestimmte Zeit nicht beim Server gemeldet hat, wird die Session gelöscht und man muss sich wieder neu anmelden. Die Dauer der Gültigkeit der Session ist standardmäßig bei 24 Minuten (1440 Sekunden). Möchte man das ändern, kann man das über den Parameter session.gc_maxlifetime in der php.ini Datei. Nach der Änderung Apache neu starten oder graceful. Die Authentifizierung erfolgt in der Datei login.php in snippets. Dort kann man auch das Layout des Anmeldefensters anpassen. Wenn man seine eigene Datei bei update schützen möchte, lege man diese in snippets/custum ab und ändere den Pfad auf die Datei login.php in index.php in der Zeile:

  include(LAYOUTPATH.'snippets/login.php');

PHP Authentifizierung bedeutet also für alle, die kvwmap von vorherigen Versionen kennen, dass die Authentifizierung über den Web-Server wegfallen kann. Die in der Apache Konfiguration vorgenommenen Einschränkungen bezüglich der Authentifizierung können also herausgenommen werden, jedoch sollte man überlegen die Restriktionen der IP´s oder IP Bereiche weiterhin aufrecht zu erhalten. Also z.B.

 Order deny,allow
 Deny from all
 Allow from 139.30.110.0/255.255.255.0 # Ein ganzes Netz freigeben
 Allow from 62.159.207.22 # Einen Einzelnen Rechner freigeben

Dies ist unabhängig von der Persönlichen Authentifizierung.

Authentifizierung über den Web-Server

Nutzer von kvwmap müssen sich authentifizieren, damit die Anwendung weiß wen sie vor sich hat. Alle benutzerseitigen Einstellungen werden über den Benutzernamen gesteuert, die der Web-Server liefert, wenn die Authentifizierung anerkannt wurde.

Es gibt mehrere Möglichkeiten der Authentifizierung mit Apache siehe Dokumentation: http://httpd.apache.org/docs/2.0/howto/auth.html

Neben der Authentifizierung über das Standardmodul mod_auth kann auch mod_auth_mysql verwendet werden. Wir der Name schon sagt erfolgt dabei die Authentifizierung über eine MySQL-Datenbank und ist das sinnvollerweise die kvwmap-Datenbank, wenn man nicht schon eine andere Datenbank mit den Benutzern hat.

Authentifizierung mit Apache und MySQL

mod_auth_mysql.so sollte im Ordner modules vom apache Verzeichnis zu finden sein. Wenn nicht downloaden und compilieren nach Installanweisungen.

--HolgerR 10:54, 9. Aug 2006 (CEST)

Unter SuSE Version > 9 müssen apache2-devel und mysql-devel installiert sein, damit einerseits apxs2 auf dem System vorhanden ist und andererseits die Bibliotheken von mysql zur Verfügung stehen

Man muss zunächst in der httpd.conf das Modul mod_auth_mysql einbinden

Also das Komentarzeichen von folgender Zeile wegnehmen:

LoadModule mysql_auth_module modules/mod_auth_mysql.so

Dadurch wird in der Zeile:

<IfModule mod_auth_mysql.c>
   Include conf/mod_auth_mysql.conf
</IfModule>

Ebendieses Konfigurationsdatei geladen. Der entscheidende Teil für kvwmap sieht folgendermassen aus und muss für die eigene Version, das eigene Verzeichnis angepasst werden. Hier ist kvwmap_1.5.7 das zu schützende Verzeichnis

<Location /kvwmap-1.5.7>
 AuthName "MySQL Secured Place"
 AuthType Basic
 require valid-user
 AuthMySQLHost localhost
 # Der Name der Datenbank wo die Nutzer drin stehen.
 AuthMySQLDB kvwmap
 # Der Name des Nutzers, der sich da anmelden soll bei der Datenbank zum   nachsehen.
 AuthMySQLUser apachedemon
 AuthMySQLPassword # Das Passwort von apachedemon wenn es eins hat.
 AuthMySQLUserTable user # Die Tabelle wo die Nutzer drin stehen.
 AuthMySQLNameField login_name # Die Spalte wo die loginnamen drin stehen.
 AuthMySQLPasswordField passwort # Die Spalte wo die Passwörter drin stehen.
 # Setzen von Bedingungen, z.B. Einschraenkung des Zugriffs auf die Funktion --HolgerR 18:02, 3. Aug 2006 (CEST)
 AuthMySQLUserCondition "Funktion = 'user'" # Mehrere Bedingungen in Klammern setzen; Verknüpfungen mit 'and' 'or' moeglich
 ## AuthMySQLGroupTable user_grp (here do not modify this for the simple test!)
 ## AuthMySQLGroupField group (here do not modify this for the simple test!)
 AuthMySQLPwEncryption none # Hier kann man einschalten, das verschlüsselte
 #Passwörter erkannt werden. (z.B. md5 oder crypt)
</Location>

Infos unter http://modauthmysql.sourceforge.net/CONFIGURE

Nutzer anlegen

Zum Anlegen eines neuen Nutzers wählt man den Menüpunkt „Nutzer anlegen“ im Obermenü Nutzerverwaltung. Es erscheint der Benuterdaten Editor wie in Abbildung dargestellt. Man trägt mindestens die Werte mit * ein und sendet das Formular mit „Als neuen Nutzer eintragen“ ab. Der eingetragene Nutzer hat anschließend sofort zugriff auf die Stellen, die im Feld „Berechtigte Stellen“ zugewiesen wurden.

Nur beim erstmaligen anlegen muss man das Password festlegen. Die Rechte des Nutzers werden über die Zuordnung der Rechte zu den Stellen definiert.

Nutzer ändern

Um Nutzerdaten zu ändern wählen Sie erst „Nuter anzeigen“ und dann „ändern“ oder „löschen“.

Layer

Layer in kvwmap setzen üblicherweise auf einer PostGIS-Tabelle auf oder binden einen Dienst (WMS oder WFS) ein. Außerdem können Layer auch auf Shapes basieren oder Rasterbilder enthalten.

PostGIS-Tabelle anlegen und füllen

Prinzipiell gibt esw zwei verschiedene Möglichkeiten, PostGIS-Tabellen anzulegen und Daten in diese Tabellen zu spielen.

Wenn eine Shape-Datei vorliegt, kann diese mitsamt Geometrie, Index und Inhalt über das in PostGIS mitgelieferte Skript shp2pgsql als Datenbanktabelle angelegt werden (Beschreibung siehe z.B. hier). Prinzipiell:

shp2pgsql <shapedateiname> public.<tabellenname> | psql -d <datenbankname>

Wer die Tabelle selbst definieren will (z.B. weil noch gar keine Daten vorliegen), kann die Tabellendefinition über einen SQL-Datenbank Client erledigen. Hier ein Beispiel für eine Tabelle zur Aufnahme von Jagdbezirken:

CREATE TABLE public.jagdbezirke
(
 id character varying(10),
 art character varying(15),
 flaeche numeric,
 name character varying(50),
 concode character varying(5),
 conname character varying(40),
 jb_zuordnung character varying(10),
 status boolean,
 verzicht boolean NOT NULL DEFAULT false
)
WITH (OIDS=TRUE);

Die Tabelle muß die Systemspalte oid besitzen um von MapServer gelesen werden zu können. Anschließend wird die Geometrie-Spalte angelegt (separat, weil hier Funktionen von PostGIS verwendet werden). Im Beispiel eine für die Jagdbezirksflächen mit EPSG-Code 2398 (Gauß/Krüger-Krassowski 3° 4. Streifen)

SELECT AddGeometryColumn('public', 'jagdbezirke','the_geom',2398,'POLYGON', 2)

Es wird ein Eintrag in der Tabelle geometry_columns angelegt, der für den Mapserver wichtig ist, welcher für kvwmap das Erzeugen des Kartenbildes übernimmt. Die Syntax ist in der PostGIS Dokumentation beschrieben.

Im nächsten Schritt werden Geometrieindizes über die Tabellen gelegt, um die spätere räumliche Abfrage auf die Geometrien zu beschleunigen.

CREATE INDEX jagdbezirke_gist ON jagdbezirke USING GIST ( the_geom GIST_GEOMETRY_OPS );

Eine Anleitung dazu findet man unter GIST-Indexes in der PostGIS-Doku.

In der Postgres-Datenbank können auch Sichten (sog. "Views") angelegt werden. Das sind gespeicherte SQL-Abfragen, die im Prinzip wieder genau wie eine Tabelle abgefragt werden können. Möchte man eine Sicht für kvwmap verwenden, muss dafür gesorgt werden, dass die Geometriespalte, die in der Sicht angegeben wird, auch in der Tabelle geometry_colums aufgeführt ist, sonst kann die srid nicht zugeordnet werden.

Neuen Layer anlegen

Neue Layer können direkt in der MySQL-Datenbank in der Tabelle layers angelegt werden oder - eigentlich der übliche Weg - in kvwmap mit dem Layereditor (go=Layereditor).

Shape Vektor Layer in MySQL

Dateien des Layers in das Datenverzeichnis data (siehe config.php) des Servers kopieren. Wenn es sich um eine neue Datenkategorie handelt, z.B. Daten zur Bebauungsplanung sollte aus Gründen der Übersichtlichkeit ein extra Ordner angelegt werden. Die Hinweise zur Vergabe von Datei- und Verzeichnisnamen sollten beachtet werden.
Neuen Layer in der Tabelle layer anlegen
- Layer_ID wird von der Datenbank selbst vergeben.
- Name ist der Name der dann auch in der Legende erscheint
- Datentyp
  - 0 wenn es ein Punktlayer ist
  - 1 wenn es ein Linienlayer ist
  - 2 wenn es ein Polygonlayer ist
- In Gruppe wird die Zugehörigkeit zur Datenkategorie gekennzeichnet. (Rote Bezeichnung in der Legende)
- Query kann erstmal frei bleiben. Später kann hier ein SQL-Statement eingetragen werden um zu definieren welche Sachdaten abfragbar sein sollen.
- In Data wird der Dateiname des Shapes eingetragen ohne Dateiendung. Wenn die Datei in einem Unterverzeichnis liegt, dieses mit angeben, z.B. Umwelt/biotope
- In document_path kann der Speicherort für hochgeladene Dateien angegeben, die zu dem Layer gehören. Das Verzeichnis muss absolut angegeben sein und überschreibt, falls angegeben, das default-Verzeichnis in der Konstante UPLOADPATH aus config.php. Diese Angabe kann zusätzlich noch individuell für jedes Attribut vom Typ Dokument im Attributeditor überschrieben werden.
- tileindex und tileitem entfällt für Vektorlayer
- In der Spalte labelitem steht der Name der Spalte aus der später mal Angaben für die Beschriftung des Layers entnommen werden sollen.
- In der Spalte labelmaxscale gibt man an, ab welcher Maßstabszahl der Layer frühestens gezeichnet werden soll.
Klasse für Layer definieren
Layer zur Stelle hinzufügen

PostGIS Vektor Layer in MySQL

Die Verfahrensweise ist exakt dieselbe wie oben für den Shape beschrieben. Im Feld Data muss allerdings nun für den Mapserver eingetragen werden, welche Tabelle er für die Darstellung des Layers in der Karte heranziehen muss. Im Fall, dass die Abfrage auf genau eine Tabelle gemacht wird, kann der Eintrag so aussehen:

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

Vektor Layer mit kvwmap

Die Verfahrensweise ist exakt dieselbe wie oben für den Eintrag direkt in MySQL beschrieben.

kvwmap bietet allerdings einige Bequemlichkeiten, die das Anlegen eines Layers einfacher machen. Insbesondere können in kvwmap auch schon defaults für die Zuordnung eines Layers zu einer Stelle und Klassen für die klassifizierte Darstellung eines Layers in der Karte festgelegt werden. Sind Klassen definiert, bietet kvwmap weiterhin den Style- und Labeleditor an, mit dem das Aussehen des Layers definiert werden kann (go=Style_Label_Editor). Ein zusätzlicher Vorteil der Layerdefinition über kvwmap ist, dass der Eintrag in der Query beim Speichern geprüft wird. Im Folgenden wird weiterhin darauf abgestellt, dass die Einträge in die MySQL erfolgen. Da in kvwmap dieselben Felder gefüllt werden (nur eben über die kvwmap-eigene Oberfläche), wird auf eine separate Beschreibung verzichtet.

Raster-Layer

Rasterdateien in das Datenverzeichnis des Web-Servers kopieren.
Wenn es sich um eine neue Datenkategorie handelt, z.B. Daten zur Bebauungsplanung sollte aus Gründen der Übersichtlichkeit ein extra Ordner angelegt werden. Die Hinweise zur Vergabe von Datei- und Verzeichnisnamen sollten beachtet werden.
Wenn die Rasterdaten in einer gekachelten Darstellung angezeigt werden sollen (TILE) muss auch eine Shape-Datei mit den Verweisen zu den Rasterkarten in das Datenverzeichnis kopiert werden. Die Hinweise zum Anlegen eines TILEINDEX sind zu beachten.
Die Verfahrensweise beim Anlegen des Layers ist exakt dieselbe wie oben für den Shape beschrieben. Als Datentyp ist hier "3" einzugeben. Query und Data bleiben leer.

Layer mit Rasterkacheln (Tile Index)

Hinweise zum Anlegen eines TILEINDEX für Rasterdaten

Die TILEINDEX Datei ist eine Shape-Datei, die die äußeren Umringe von mehren Rasterdateien enthält und Verweise auf dessen Speicherort. Dies ermöglicht die gekachelte Darstellung von flächendeckenden Rasterdaten und verringert die Zeit für die Darstellung des Rasterlayers. Man fasst damit auch mehrere Rasterdateien in einem Layer zusammen.
TILEINDEX erzeugen
Legen Sie in ArcView einen neuen Polygonlayer an.
Digitalisieren Sie die Rechtecke, die die darzustellenden Grafiken umschließen
erzeugen Sie eine neue Spalte vom Typ string mit der am Dateinamen orientierten Länge, z.B. 50 oder besser 100 Zeichen.
Die Bezeichnung der Spalte, in der die Verweise auf die Rasterdateien stehen, wird für den Parameter TILEITEM in der Map-Datei verwendet.

Anlegen eines TILEINDEX mit „gdaltindex“

Voraussetzung:

Es liegen georeferenzierte Rasterdaten z.B. Luftbildkacheln vor. Die Georeferenzierung erfolgt bei TIFF-Daten über tfw-Dateien und bei JPEG-Daten über jgw-Dateien.

Der Inhalt der tfw- und jgw-Dateien ist identisch. Tiff-Daten lassen sich somit in JPEG umwandeln, was Speicherplatz spart und kürzere Ladezeiten ermöglicht. Die tfw- und tif-Dateien bzw. die jpg- und die jgw-Dateien sind sinnvollerweise in einem Verzeichnis unterhalb des Datenpfades z.B. /opt/lampp/var/data abzulegen.
Erzeugung des Index:

Infos über die Befehlssyntax von „gdaltindex“ erhält man durch Eingabe des Kommandos „gdaltindex“ ohne Parameter auf der Linux-Konsole.

Der Tileindex lässt sich einfach im Datenverzeichnis z.B. mit dem Kommando: „gdaltindex luftbilder luftbilder/*.jpg“ erzeugen. Hierbei ist der Verzeichnisname mit den Daten „luftbilder“ und das erzeugte shape-file mit dem Index heißt „luftbilder“. Es werden 3 Dateien erzeugt. In diesem Beispiel luftbilder.shp, luftbilder.shx und luftbilder.dbf.
Einbindung als Raster-Layer:

Es ist ein Rasterlayer in der Tabelle layer MySQL-Datenbank anzulegen. Der Tileindex muss jetzt lediglich in der Spalte „tileindex“ der Tabelle eingetragen werden. In diesem Beispiel ist der Eintrag „luftbilder.shp“ vorzunehmen.
Mögliche Probleme:

Wenns nicht gleich funktioniert sind zunächst die Rechte der Daten zu überprüfen und ggfs. mit „chmod“ z.B. auf 755 zu setzen.

Die Erzeugung eines Index über grössere Datenbestände kann schon mal etwas dauern. Das Kommando sollte dann aber ohne Fehlermeldungen durchlaufen.

Die Verwendung von Umlauten, Leerzeichen, Schrägstrichen oder sonstigen Sonderzeichen in Verzeichnissen und Dateinamen sollte vermieden werden.

Beschriftung (Labels) für Layer anlegen

Eintragen des Spaltennamens, welche den Text für die Beschriftung enthält, in die Tabelle layer in das Feld labelitem.
Eintragen der maximalen Maßstabszahl in der die Beschriftung noch angezeigt werden soll in das Feld labelmaxscale.
Eintragen des Styles (Label_ID) für die Beschriftung in der Tabelle classes für die entsprechende Klasses des Layers, die Beschriftet werden soll in der Spalte Label_ID.
Entweder eine vorhandene Label_ID aus der Tabelle labels übernehmen oder eine neue Labeldefinition anlegen.

Neue Klasse für Layer anlegen

Eintragen der neuen Klasse in die Tabelle classes.
Die Class_ID wird automatisch vergeben.
Der Name ist der Name unter der die Klasse in der Legende aufgeführt ist.
Bei Layer_ID geben Sie die Nummer des Layers ein, zu dem die Klasse gehören soll.
Für Style_ID geben Sie eine Nummer die das Aussehen der Zeichnungselemente der Klasse definiert. Styles sind in der Tabelle Styles vorgegeben. Siehe neuen Style anlegen.
In der Spalte Expression wird der logische Ausdruck ausgegeben, der die Klasse hinsichtlich seiner Sachdaten definiert. z.B. werden mit "([Objart] = 1000)" nur die Features angezeigt, die in der Spalte der DBF-Datei eine 1000 stehen haben.

Beispiele Schreibweise für textliche Vergleiche:

('[textattribut]' = 'text')
('[textattribut]' eq 'text')
('[textattribut]' != 'text')

Beispiele Schreibweise für numerische Vergleiche:

([numerisches attribut] = 1234)
([numerisches attribut] > 1234)
([numerisches attribut] > 1234 and [numerisches attribut] < 2345)

Schreibweise für boolsche Vergleiche:

('[boolean attribut]' eq 't')
('[boolean attribut]' eq 'f')

Mehr Informationen zu den Möglichkeiten der EXPRESSION siehe mapserver.org.

Die Spalte Label_ID ist für die Beschriftung der Klasse. siehe Neuen Beschriftungstyp einrichten

Layer zu einer Stelle hinzufügen

Nachschlagen der Stellen_ID in Tabelle stelle, von der Stelle, zu der ein Layer hinzugefügt werden soll.

Wenn die Stelle noch nicht vorhanden ist, siehe neue Stelle anlegen.
Nachschlagen der Layer_ID in Tabelle layer vom Layer, der zur Stelle hinzugefügt werden soll.

Wenn der Layer noch nicht vorhanden ist, siehe neuen Layer anlegen.
Eintragen der Zugehörigkeit des Layers zur Stelle in der Tabelle used_layer
- used_layer_id = wird automatisch vergeben (Autowert, Inkrementell)
- Stelle_ID = nachgeschlagene Nummer für Stelle
- Layer_ID = nachgeschlagene Nummer für Layer
- Status = 0
- aktivStatus = 1 wenn der Layer gleich sichtbar sein soll, sonst 0
- drawingorder = hängt davon ab an welcher Stelle der Reihenfolge der Layer gezeichnet werden soll. Schlagen sie die schon eingetragenen Nummern für die anderen Layer der Stelle in der Tabelle used_layer nach. Kleinere Nummern werden zuerst gezeichnet, größere später und überzeichnen vorherige. Rasterdaten sollten zuerst gezeichnet werden, da sie sonst andere Layer überdecken. siehe auch Zeichnungsreihenfolge von Layern Ändern
- Die anderen Felder können Sie erstmal so lassen
- Klicken Sie im Browser auf "neu Laden" aktivieren Sie den Layer und klicken noch mal "neu Laden". Ändern Sie ggf. nach Wunsch die Reihenfolge der Layer.

Zeichnungsreihenfolge von Layern Ändern

Öffnen Sie kvwmap
Wählen Sie unter dem Menüpunkt Stellenverwaltung den Eintrag "Stellen anzeigen".
Klicken Sie bei der gewünschten Stelle auf den Link "Layer".
Hier werden jetzt alle dieser Stelle zugeordneten Layer aufgelistet und man kann die Zeichenreihenfolge anpassen (größere Zahl = Layer oberhalb).
Die Angaben werden in MySQL in der Tabelle used_layer, Spalte drawingorder abgelegt (Stelle_ID und Layer_ID können in den Tabellen stelle und layer nachgeschlagen werden)

WMS-Layer anlegen

Zum Anlegen eines WMS-Layers muss man mindestens den getCapabilities Request des WMS kennen. Beispiel für einen WMS, den das LUNG zur Verfügung stellt (Umbrüche nur für die bessere Lesbarkeit):

http://www.umweltkarten.mv-regierung.de/script/lung_wms_wms.php? //
VERSION=1.1.1&SERVICE=WMS&REQUEST=GetCapabilities&LAYERS=t7_versalzung&FORMAT=image/png&STYLE=default

(Merkwürdigerweise steht dort in der OnlineResource "request=GetLegendGraphic", was uns aber zeigt, dass der Dienst auch eine Legende liefern kann). Ein GetMap-Aufruf könnte also beispielsweise so aussehen:

http://www.umweltkarten.mv-regierung.de/script/lung_wms_wms.php? //
VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=t7_versalzung& //
WIDTH=600&HEIGHT=500&BBOX=348800,5999707,374749,6021620& //
FORMAT=image/png&STYLE=default&SRS=EPSG:25833

Beim Koordinatenreferenzsystem (SRS) ist darauf zu achten, dass eins ausgewählt wird, das der Dienst im getCapabilities auch unterstützt. Der hier beispielhaft aufgeführte WMS unterstützt z.B. nicht den EPSG:2398. Im kvwmap-WMS-Layer bleiben die Felder Query und Data leer. Im Feld Connection wird der statische Teil des GetMap-Requests eingetragen, also alle Parameter, die sich beim Dienst-Aufruf nicht ändern. Im Beispiel also:

http://www.umweltkarten.mv-regierung.de/script/lung_wms_wms.php? //
VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&SRS=EPSG:25833&LAYERS=t7_versalzung&FORMAT=image/png&STYLE=default

Der ConnectionType ist "MS_WMS" (7) und als Datentyp wird "MS_Layer_Raster" (3) gewählt. Alle anderen Einstellungen erfolgen wie bei einem normalen Rasterlayer. Queryable kann auf "ja" gestellt werden, wenn eine Sachdatenabfrage auf den Dienst sinnvoll erscheint und im getCapabilities zu sehen ist, dass der WMS auch überhaupt abfragbar ist ("<Layer queryable = '1' ... >"). In dem Fall muss im Feld Template "getfeatureinfo.php" als Anzeigetemplate eingetragen werden.

Wenn in der kvwmap-Legende der WMS-Layer mit Legende erscheinen soll, ist im Layer eine Klasse anzulegen. Die Klasse muss einen Namen bekommen - welcher spielt keine Rolle, weil er nicht angezeigt wird.

Wenn der WMS Transparenz unterstützt, zeichnet ihn kvwmap auch transparent. Es ist also in den stellenabhängigen Eigenschaften keine Transparenz anzugeben, lediglich die Drawingorder muss berücksichtigt werden. Ob der WMS-Layer transparent gezeichnet werden kann, kann man im GetCapabilities-Dokument erkennen ("<Layer opaque = '0' ... >").

SQL-Skriptunterstützung zum Anlegen eines neuen Layers

Insbesondere für neue Fachschalen ist es nützlich, wenn das Anlegen von Layern für eine Vielzahl von Stellen automatisiert werden kann. Dazu wurden eine Reihe von SQL-Befehlen in die Datei mysql_install.sql gepackt.

Im oberen Teil befinden sich SQL-Statements für die Aktualisierung des Datenbankmodells und Konstanen, z.B. für den Benutzernamen und den Namen der Datenbank zum Zugriff auf PostGIS Layer.

Die SQL-Statements für Aktualisierungen des Datenbankmodells sind mit einem Datum versehen, so dass man selber abchecken kann ob sein Datenbankmodell noch aktuell ist. Insbesondere können solche Änderungen über Versionswechsel hinweg erfolgen. Meistens sind es zusätzliche Attribute, neue Tabellen für n-m Verknüpfungen oder die Änderung von Datentypen.

Die weiteren Statements sind zusammengefasst für die Fachschalen. Die einzelnen Statements sind kommentiert. Wer z.B. erstmalig einen Layer für die Bodenrichtwertzonen anlegt führt kopiert sich die Konstantendefinition in ein SQL-Fenster (z.B. in phpMyAdmin) und anschließend den Teil unter Bodenrichtwertzonen. Nach dem Ausführen sollte in der entsprechenden Stelle der Layer sofort verfügbar sein. Dazu sind aber auch einige Ersetzungen im Skript vorzunehmen. Gekennzeichnet sind diese Ersetzungsmöglichkeiten z.B. durch # Achtung Stelle_ID anpassen.

Metadatenlayer

Um einen Layer einzurichten, der die räumlichen Ausdehnungen der durch die Metadaten beschriebenen Daten und Dienste darstellt, sind folgende Angaben für Query und Data des Layers zu verwenden:

Query: SELECT oid,*,AsText(the_geom) AS umringtxt FROM md_metadata WHERE (1=1)

Data: the_geom from md_metadata

Menüverwaltung

Die auf der linken Seite angezeigten Menüpunkte sind immer einer Stelle zugewiesen. Welche Menüpunkte zu welchen Stellen gehören, kann in der Stellenverwaltung eingestellt werden. Menüs sind in Ober- und Untermenüs aufteilbar. In der Stellenverwatlung können derzeit nur Obermenüpunkte der Stelle zugeordnet werden.

Neuen Menüpunkt anlegen

Wenn der Obermenüpunkt schon existiert, muss nur noch der Unterpunkt angelegt werden, ansonsten beide, jedoch erst der Obermenüpunkt. Für das Anlegen eines neuen Menüpunktes sind die nachfolgend beschriebenen Arbeiten auszuführen.

Eintragen des Menüpunktes in die Tabelle u_menues.
- id ist eine fortlaufende Nummer
- die Angabe in der Spalte name ist der Text, der als Menüpunkt in der GUI erscheint. Hier können auch deutsche Umlaute enkodiert werden, z.B. &auml für ä
- links enthält die Angabe des Anwendungsfalles, der aufgerufen werden soll. Wenn es ein Obermenüpunkt sein soll, ist hier index.php?go=changemenue einzutragen.
- bei obermenue ist die ID des Obermenüpunktes anzugeben, in dem das Menü enthalten sein soll. Ist es selbst ein Obermenü, kommt hier eine 0 rein
- In menueebene kommt eine 1, wenn es ein Obermenü ist sonst eine 2 für Untermenü
- In target kann optional gewählt werden, ob die Seite hinter dem Menüpunkt in einem neuen Fenster aufgehen soll oder im aktuellen, in dem das Menü ist. _blank öffent den Menüpunkt in einem neuen Fenster. Das reservierte Wort confirm sorgt dafür, dass die Ausführung des Punkte noch einmal vorab bestätigt werden muss und ggf. abgebrochen werden kann.

Beispiel: Eintragen des Übermenüpunktes in u_menues

INSERT INTO `u_menues` ( `id` , `name` , `links` , `obermenue` , `menueebene` , `target` )
VALUES (NULL , 'Drucken', 'index.php?go=changemenue', '0', '1', NULL);

Fragen Sie anschließend die dabei erzeugte id in der Tabelle u_menues ab. z.B. 51

Beispiel: Eintragen des Untermenüpunktes zur Druckvorschau

INSERT INTO `u_menues` ( `id` , `name` , `links` , `obermenue` , `menueebene` , `target` )
VALUES (NULL , 'Druckvorschau', 'index.php?go=Druckausschnittswahl', '<id für Obermenü>', '2', NULL);

Zuordnen des Menüs zur Stelle

Die Zuordnung kann direkt in der Tabelle u_menue2stelle erfolgen. In diesem Fall müssen aber neben dem Obermenüpunkt auch alle Unterpunkte extra zugeordnet werden. Zusätzlich ist auch die Tabelle u_menue2rolle zu bestücken.

Besser ist es den Obermenüpunkt über die Stellenverwaltung der Stelle zuzuordnen.

Ändern der Zuordnung von Menüpunkten zu Obermenüs

Wenn ein Untermenü aus einem Obermenü entfernt werden soll, ist am besten zunächst in der Stellenverwaltung das ganze Menü zu entfernen.

Anschließend ändert man die Nummer in der Spalte obermenue in der Tabelle u_menues in die ID des neuen Obermenüpunktes. Wenn der noch nicht existiert, legt man diesen vorher an. Danach kann der Menüpunkt wieder hinzugefügt werden.

Druckrahmenverwaltung

Der Nutzer hat die Möglichkeit einen Kartenausschnitt in ein PDF zu exportieren. Das Layout des PDF-Dokuments kann mit Hilfe von verschiedenen, voher definierten Druckrahmen festgelegt werden. Im folgenden wird beschrieben, wie die Erstellung eines solchen Druckrahmens erfolgt.

Die Erstellung eines Druckrahmens erfolgt in der Druckrahmenverwaltung. Um diese aufrufen zu können, muss es einen entsprechenden Menüpunkt mit der go-Variable 'Druckrahmen' geben (Tabelle: u_menues). Außderdem muss dieser Menüpunkt der Stelle (Tabelle: u_menue2stelle) und dem Nutzer dieser Stelle (Tabelle: u_menue2rolle) zugeordnet werden. In der Druckrahmenverwaltung werden unter 'Druckrahmenauswahl' alle in der MySQL-Tabelle 'Druckrahmen' gespeicherten Rahmen in einer Auswahlliste angezeigt (1). Wählt man einen der Druckrahmen aus, werden die Parameter des Rahmens unter 'Druckrahmendaten' in einem Formular angezeigt. Ist noch kein Datensatz in der Tabelle 'Druckrahmen' vorhanden, sind sowohl die Auswahlliste als auch die Formularfelder leer.

--Markus Hentschel 12:55, 24. Apr 2007 (CEST) Damit sowohl in der Druckrahmenverwaltung als auch in der späteren Druckvorschau die textlichen Elemente angezeigt werden, müssen ImageMagick und Ghostscript auf dem Server installiert sein. Ist das der Fall, ist in der config.php der Parameter IMAGEMAGICK = 'true' zu setzen. Ghostscript ist zumindest bei SuSE schon installiert. Die Installation von ImageMagick mit JPEG-, PNG- und TIF-Unterstützung wird bei den HowTos erklärt.

Ein Druckrahmen besteht aus mehreren Elementen und hat mehrere Parameter. Als erstes sollte man festlegen, welches Format der Druckrahmen haben soll. Das Formularfeld 'Format' bietet hier 4 verschiedene Auswahlmöglichkeiten (2). Nachdem das Format festgelegt wurde, kann man einen Druckkopf für das Dokument definieren. Der Druckkopf dient in erster Linie als Kopf für das PDF-Dokument, kann aber auch als Hintergrund für das gesamte Dokument benutzt werden. Im Druckkopf sollten alle Informationen enthalten sein, die statisch, d.h. bei jedem PDF-Export konstant sind. Um einen Druckkopf in den Druckrahmen einzubinden, wählt man unter 'Druckkopf: wählen:' eine entsprechende Bilddatei aus (3). Wichtig ist, das diese Datei im Format 'jpg' vorliegt. --HolgerR 13:17, 22. Aug 2006 (CEST) Damit der Druckrahmen auf dem Server abgespeichert werden kann, muss der in der config.php festgelegte 'DRUCKRAHMEN_PATH' physisch auf dem Server vorhanden sein. Um die Datei hochzuladen und ihre Abmessungen einzulesen, sollte man den Druckrahmen an dieser Stelle schon einmal speichern. Zuvor sollte man jedoch noch einen Namen vergeben, damit der Druckrahmen identifiziert werden kann. Dies erfolgt über das Formularfeld 'Name' (4). Jetzt klickt man auf 'Als neuen Rahmen speichern' (5) und der Datensatz wird in die Tabelle 'Druckrahmen' geschrieben. Der Druckrahmen sollte sich nun auch in der Auswahlliste der Druckrahmen befinden.

Die Position und Größe des Druckkopfes kann nun über die entsprechenden Formularfelder x,y (6) und Breite, Höhe (7) festgelegt werden. Die Felder x und y bestimmen dabei den Abstand des Druckkopfes vom linken bzw. oberen Rand des PDF-Dokuments. Die Maßeinheit ist bei allen Positions- und Größenangaben 1 Pixel im PDF. Neben dem Formularfeld 'Format' ist die Auflösung des PDF-Dokuments in Pixeln angegeben (8). Nachdem die Position und Größe des Druckkopfes definiert wurde, klickt man auf 'Änderungen speichern' (9). In der Vorschau (10) sollte nun der Druckrahmen zu sehen sein. Sollte die Position bzw. Skalierung des Druckkopfes noch nicht zufriedenstellend sein, kann diese verändert werden und nach erfolgter Speicherung in der Vorschau überprüft werden.

Als nächsten Schritt sollte man die Position und Größe der Karte festlegen. Dies geschieht analog zum Druckkopf mit den Formularfeldern x und y (11) und Breite und Höhe (12). Nach Speicherung der Änderungen ist die Position der Karte in der Druckrahmenvorschau zu sehen und kann bei Bedarf korrigiert werden. Mit der Karte und dem Dokumentenkopf sind die beiden Hauptelemente des Druckrahmens, die zur korrekten Funktion benötigt werden, definiert worden.

Neben der Karte und dem Druckkopf lassen sich weitere Elemente zum Druckrahmen hinzufügen. Dazu gehören u.a. ein Freitext (13), der Maßstab (14), das aktuelle Datum (15), die Gemarkung (16), die Flur (17) sowie die Angabe eines ursprünglichen Maßstabes der analogen Flurkarte (18) (hier ist die Datenquelle jedoch noch nicht integriert). Außer dem Freitext sind alle diese Elemente dynamisch, d.h. sie werden vom System automatisch gesetzt. Im Druckrahmenformular lässt sich die Position und die Schriftgröße jedes Elementes definieren. Werden die Änderungen am Druckrahmen gespeichert, so erscheinen auch diese Elemente in der Vorschau und können bei Bedarf angepasst werden.

Zusätzlich zu der normalen Karte lässt sich bei Bedarf auch eine Referenzkarte zum Druckrahmen hinzufügen. Um dies tun zu können, sind mehrere Vorraussetzungen nötig. Zum einen muss ein Rahmen bzw. Hintergrund für die Referenzkarte festgelegt werden. Dieser Hintergrund liegt über der normalen Karte und unter der Referenzkarte. Dazu lässt sich analog zum Druckkopf über 'Ref.hintergrund: wählen:' (19) eine entsprechende jpg-Datei auswählen und durch Klick auf 'Änderungen speichern' hochladen. Die Position und Größe dieses Referenzkartenhintergrunds lässt sich dann über die entsprechenden Felder anpassen (20). Nach der Festlegung des Referenzkartenhintergrunds kann man die Position und Skalierung der Referenzkarte definieren (21). Für die Referenzkarte muss man außerdem noch den Zoomfaktor einstellen, der festlegt, umwieviel diese Karte den Ausschnitt der normalen Karte vergrößert. Ein Zoomfaktor von -2 bewirkt hier beispielsweise, dass die Referenzkarte einen 2mal so großen Kartenausschnitt zeigt. Um festlegen zu können, welche Layer die Referenzkarte zeigen soll, wird für die Darstellung dieser Karte eine separates Mapfile verwendet. Der Pfad zu diesem Mapfile wird in der config.php über die Konstante 'REFMAPFILE' festgelegt. So ist es z.B. möglich, mittels der Referenzkarte eine Flurübersicht zu erzeugen, wie sie in ALK-Auszügen verwendet wird.

Um einen Kartenausschnitt unter Benutzung eines zuvor definierten Druckrahmens in ein PDF zu exportieren, muss es einen entsprechenden Menüpunkt mit der go-Variablen 'Druckausschnittswahl' geben (Tabelle: u_menues). Außderdem muss dieser Menüpunkt der Stelle (Tabelle: u_menue2stelle) und dem Nutzer dieser Stelle (Tabelle: u_menue2rolle) zugeordnet werden.

Wie mit Hilfe der in der Stelle zugeordneten Druckrahmen gedruckt werden kann ist unter dem Punkt Benutzung von kvwmap beschrieben, siehe (Drucken in PDF).

Datenbankadministration

Datensicherung MySQL

Die Datenbank kann auf zwei verschiede Art und Weise gesichert werden.

Kopieren des gesamten Verzeichnisses einer Datenbank, Datenbank muss dazu gestoppt sein, oder es ist sicher, dass keiner mehr zugreift.
Erzeugen und Sichern eines Datenbankdumps, geht aus dem laufendem Betrieb heraus.

Zu einer Datenbank gehört immer das gleichnamige Verzeichnis unter dem Datenverzeichnis von mysql. Das ist meißtens unter /var/lib/mysql kann aber auch unter /usr/local/mysql/var o.ä. sein. Das Verzeichnis der Datenbank einfach einpacken und später dahin wieder auspacken zur Wiederherstellung.

Beispiel für die Sicherung eines Datenbankverzeichnisses.
$cd /usr/local/mysql/var
$tar cvfz kvwmapdb160-2006-09-09.tar.gz kvwmapdb160
$tar xvfz kvwmapdb160-2006-09-09.tar.gz -C /usr/local/mysql/var

Für die andere Variante führt man zunächst einen Dump von der laufenden Datenbank aus über die Dumpfunktion von phpMyAdmin oder das Programm mysqldump unter /usr/local/bin Es ist vorteilhaft den Pfad /usr/local/bin in die PATH Variable zu schreiben:

$export PATH=$PATH:/usr/local/bin

Optionen und Nutzung von mysqldump werden ausgegeben mit

$./mysqldump --help

Eine einzelne DB wird z.B. gesichert mit:

$./mysqldump -u root -p kvwmapdb160 > kvwmapdb160-dump_2006-09-09.sql

Zum wiederherstellen der Datenbank muss eine neue Datenbank angelegt werden.

$./mysql -u root -p 
mysql$ create database kvwmapdb160;
mysql$ exit

Einlesen des Dump mit:

$./mysql -u root -p kvwmapdb160 < kvwmapdb160-dump_2006-09-09.sql

Datensicherung PostgreSQL/PostGIS

Die Datenbank kann auf zwei verschiede Art und Weise gesichert werden.

Kopieren des gesamten Verzeichnisses einer Datenbank, Datenbank muss dazu gestoppt sein. Das wiedereinsetzen der Dateien funktioniert normalerweise nur, wenn die neue Datenbank von der selben Version ist wie die ursprüngliche.
Erzeugen und Sichern eines Datenbankdumps, geht aus dem laufendem Betrieb heraus.

Die Datenbank liegt bei Suse-Servern üblicherweise in /usr/local/pgsql/data, bei Nutzung des FGS-Pakets findet man sie in $FGS_HOME/apps/pgsql/data.

Die Sicherung der Datenbank im laufenden Betrieb funktioniert über pg_dump und pg_restore und kann cron-gesteuert erfolgen. pg_dump und pg_restore finden sich im bin-Verzeichnis von pgsql bzw. bei Nutzung des FGS-Pakets in $FGS_HOME/bin.

Bei einer Neuinstallation der Datenbank muss PostgreSQL mit initdb initialisiert werden. Alle Konfigurationsdateien, in denen manuelle Änderungen vorgenommen wurden, müssen wiederhergestellt sein.

Die Datensicherung erfolgt zweckmäßigerweise zweigleisig, indem zum einen das Schema, zum anderen die Daten jeweils extra gesichert werden:

# Schemasicherung
./pg_dump -U kvwmap -f /var/.si/dumps/pg_kvwmapsp_daily_schema.sql -s -F c kvwmapsp
# Datensicherung
./pg_dump -U kvwmap -f /var/.si/dumps/pg_kvwmapsp_daily_data.sql -a -F c kvwmapsp

Für das Wiederherstellen der Datenbank wird zunächst über den SQL-Befehl CREATE DATABASE oder dem Hilfsprogramm createdb eine neue, leere Datenbank angelegt. Dann wird das Datenbankschema angelegt:

./pg_restore -U kvwmap -d kvwmapsp_neu /var/.si/dumps/pg_kvwmapsp_daily_schema.sql

Möglicherweise kann das Schema nicht angelegt werden, weil Abhängigkeiten der Tabellen untereinander bestehen, die verlangen, dass diese Tabellen in einer bestimmten Reihenfolge angelegt werden. Dann wird aus der Schema-SQL-Datei zunächst eine Listendatei erstellt (siehe PostgreSQL-Handbuch):

pg_restore -l /var/.si/dumps/pg_kvwmapsp_daily_schema.sql > /home/fgs/sicherung/liste.txt

Anschließend können die Zeilen in der ausgegebenen Datei umsortiert oder mit Semikolon auskommentiert werden. Die Wiederherstellung berücksichtigt dann die Reihenfolge in dieser Liste:

$ pg_restore -U kvwmap -d kvwmapsp_neu  -L /home/fgs/sicherung/liste.txt /var/.si/dumps/pg_kvwmapsp_daily_schema.sql

Manchmal kommen so viele Fehlermeldungen, dass man die ersten auf der Konsole nicht lesen kann. Fehlermeldungen können mit 2> in eine Datei, z.B. pg_restore.err umgeleitet werden. Wenn Fehler und Ausgaben von pg_restore umgeleitet werden sollen, lautet der Befehl:

$ pg_restore -U kvwmap -d kvwmapsp_neu  -L /home/fgs/sicherung/liste.txt /var/.si/dumps/pg_kvwmapsp_daily_schema.sql > pg_restore.log 2> pg_restore.err

Die Verwendung der Liste ist nützlich zur Wiederherstellung einer Datenbank mit einer alten PostGIS Version in eine Datenbank mit einer neueren PostGIS Version, getestet für den Übergang von 1.3 auf 1.5. Beim Anlegen des Schemas meckert der restore rum, dass die Datei liblwgeom nicht gefunden wird. Das liegt daran, dass in Version 1.5 die Bibliothek postgis.so heißt. Einen symbolischen Link liblwgeom.so auf postgis.so bring auch nichts, weil in postgis.so zum Teil Funktionen nicht drin sind, die in liblwgeom.so von Version 1.3 noch verwendet wurden. Hier hilft z.B. Folgendes:

An Stelle der leeren Datenbank legt man eine Datenbank mit dem neuen postgis_template an, welches schon das neue PostGIS enthält. Dann löscht man alle PostGIS relevanten Einträge in liste.txt, die stehen meistens schon am Anfang hinter plpgsql und enden da, wo die selbst angelegten Tabellen beginnen. Die Sprachunterstützung plpgsql muss man übrigens auch rausnehmen, da diese auch schon im postgis_template enthalten ist. Um die Einträge in spatial_ref_sys wieder herstellen zu können, löscht man vorher den Inhalt der Tabelle spatial_ref_sys, sonst hat man da doppelte Einträge drin.

Wenn das Datenbankschema erfolgreich angelegt wurde, können die Daten eingespielt werden:

./pg_restore -U kvwmap -d kvwmapsp_neu /var/.si/dumps/pg_kvwmapsp_daily_data.sql

Oder auch unter Berücksichtigung der Listendatei, d.h. nur Wiederherstellung bestimmter Tabellen:

./pg_restore -U kvwmap -d kvwmapsp_neu -L /home/fgs/sicherung/liste.txt /var/.si/dumps/pg_kvwmapsp_daily_data.sql

Referenz zur MySQL-Datenbank von kvwmap

Dieser Abschnitt enthält eine Beschreibung der Feldinhalte zu Nutzerdaten und Layern, die in der MySQL-Datenbank von kvwmap gespeichert werden.

Die Referenz entspricht der kvwmap-Version 1.7.5

Ein Tabellen-Beziehungsmodell (ER-Diagramm) ist als PDF-Datei verfügbar.

Eine ausführliche deutschsprachige Beschreibung aller MapFile-Parameter, die in der Datenbank abgebildet werden, findet sich unter http://mapserver.org/de/mapfile/. Das englische Original ist zu finden unter http://mapserver.org/mapfile/index.html#mapfile.

Alle nummerierten Parameter entsprechen den MapScript-Definitionen. Diese Definitionen können in der map.h der mapServer-Source im Abschnitt "General enumerated types" nachgesehen werden.

Tabelle "classes"

Jede Class wird genau einem Layer zugeordnet. Mit der Class können Daten, die in einem Shape liegen, nach bestimmten Kriterien selektiert und in unterschiedlichen Ausgestaltungen präsentiert werden.

Name

Der Name der Class wird in der Legende angezeigt.

Layer_ID

Die entsprechende ID aus der Tabelle "layer".

Expression

Wenn der Layer mehrere Classes enthält, regelt "Expression" die Zugehörigkeit eines Features zur jeweiligen Class. Wenn kein Ausdruck vorhanden ist, werden alle Features einer Class zugeordnet.

Kvwmap lässt momentan nur logical Expressions zu. Dabei muss das Attribut (Spaltenüberschrift in der DBF-Tabelle des Shapes) explizit angegeben werden. Die Notation erfolgt so:

Die komplette Expression wird grundsätzlich mit einer runden Klammer ( ) versehen.
Das Attribut wird in eckige Klammern [ ] gesetzt. Handelt es sich um das Attribut eines Shapes, ist darauf zu achten, dass es in Großbuchstaben geschrieben wird. Handelt es sich um das Attribut einer PostGIS-Tabelle, ist darauf zu achten, dass es in Kleinbuchstaben geschrieben wird.
Wird eine Zeichenkette abgefragt, wird sowohl die eckige Klammer des Attributs als auch der Ausdruck in einfache Anführungszeichen ' ' gesetzt.
Folgende logische Operatoren werden unterstützt: =, >, <, <=, >=, =, lt (lower than), gt (greater than), ge (greater equal), le (lower equal), eq (equal), ne (not equal).
logische Ausdrücke können mit "AND" bzw. "OR" beliebig verschachtelt werden.

Beispiel:

([EINWOHNERZAHL] >= 20000 AND '[ART]' ne 'Stadt')

drawingorder

Darstellungsreihenfolge der Classes in der Legende. Wenn nichts angegegeben wird, werden die Classes alphanumerisch sortiert.

text

Möchte man einen feststehenden Text für alle Objekte der class erzeugen, gibt man diesen Text in Hochkommata an.

Tabelle "colors"

speichert Farben im RGB-Schema, die für die (normale und klassifizierte) Suchergebnisanzeige verwendet werden. Farbverläufe kann man z.B. hier erstellen: [1] oder [2]

Tabelle "datendrucklayouts"

speichert layerbezogen die Sachdaten-Drucklayouts.

Tabelle "ddl2freitexte"

speichert die Freitexte eines Sachdaten-Drucklayouts.

Tabelle "ddl2stelle"

weist das Sachdaten-Drucklayout einer Stelle zu.

Tabelle "ddl_elemente"

Speichert die Elemente des Sachdaten-Drucklayouts, d.h. die zu druckenden Attribute des Layers mit ihrer layoutspezifischen Gestaltung.

Tabelle "druckausschnitte"

speichert Kartenausschnitt, Druckmaßstab und verwendeten Druckrahmen, die ein User beim Drucken für spätere Wiederverwendung speichern kann. Wird von kvwmap automatisch gefüllt.

Tabelle "druckfreibilder"

speichert die Grafiken, die in der Druckrahmenverwaltung einem Druckrahmen zugeordnet werden. Wird von kvwmap bei Benutzung des entsprechenden Menüs gefüllt.

Tabelle "druckfreitexte"

speichert die Freitexte, die in der Druckrahmenverwaltung einem Druckrahmen zugeordnet werden. Wird von kvwmap bei Benutzung des entsprechenden Menüs gefüllt.

Tabelle "druckrahmen"

speichert die Parameter der einzelnen Druckrahmen. Diese Tabelle wird von kvwmap bei Benutzung des entsprechenden Menüs gefüllt.

Tabelle "druckrahmen2freibilder"

ordnet die Grafiken aus der Tabelle druckfreibilder den Druckrahmen zu und enthält die Position der Bilder im Druckrahmen sowie die Größe und den Drehwinkel die für die Darstellung der Bilder im Druckrahmen verwendet werden sollen. Muss zur Zeit noch per Hand eingetragen werden. Wenn die Bilder größer sind, als die Größenangaben in dieser Tabelle, wird das Bild gestaucht und erhält damit eine höhere Auflösung.

Tabelle "druckrahmen2freitexte"

ordnet die Texte ausder Tabelle druckfreitexte den Druckrahmen zu. Wird von kvwmap bei Benutzung des entsprechenden Menüs gefüllt.

Tabelle "druckrahmen2stelle"

ordnet die Druckrahmen den Stellen zu. Wird von kvwmap bei Benutzung des entsprechenden Menüs gefüllt.

Tabelle "labels"

MapFile-Doku MapScript-Doku

Sämtliche Parameter dieser Tabelle werden in der MapServer Referenz unter den o.a. Internetadressen ausführlich beschrieben. Hier sollen nur die "Schalter" benannt werden:

Type

"0" = Truetype
"1" = Bitmap

Standardmäßig wird "0" verwendet. Der Font muss im Ordner "Fonts" enthalten sein und in der fonts.txt eingetragen sein!

minsize, maxsize

Definiert die minimale bzw. maximale Größe der Texte des Layers (in Pixel). Hinweis: Damit die Darstellung skalierbar wird, müssen in der Tabelle "used_layer" ein Wert für symbolscale und in der Tabelle "layer" Werte für labelminscale bzw. labelmaxscale gesetzt sein.

Position

"0" = Die Beschriftung befindet sich links über dem Bezugspunkt
"1" = Die Beschriftung befindet sich rechts unter dem Bezugspunkt
"2" = Die Beschriftung befindet sich rechts über dem Bezugspunkt
"3" = Die Beschriftung befindet sich links unter dem Bezugspunkt
"4" = Die Beschriftung befindet sich rechts vom Bezugspunkt
"5" = Die Beschriftung befindet sich links vom Bezugspunkt
"6" = Die Beschriftung befindet sich über dem Bezugspunkt
"7" = Die Beschriftung befindet sich unter dem Bezugspunkt
"8" = Die Beschriftung befindet sich genau auf dem Bezugspunkt
"9" = "Auto", kalkuliert eine Beschriftungsposition, die keine andere Beschriftung beeinträchtigen wird.

offsetx, offsety

Versetzt den Text aller Objekte des Layers in X- bzw. Y-Richtung um den angegebenen Betrag (negative Werte sind auch möglich).

angle, autoangle

"angle" speichert einen festen Winkel, unter dem alle Texte des Layers gedreht werden. "autoangle = 1" dreht jeden einzelnen Text nach dem Winkel, der zum entsprechenden Objekt in dem Attribut gespeichert ist, das in der Tabelle layer unter "labelangleitem" gespeichert ist. Default ist 0.

buffer

Erzwingt einen Leerraum um alle Texte dieses Layers in Pixeln. Default ist 0.

Antialias

Kantenglättung. Funktioniert nur bei "Truetype".

"0" = ja
"1" = nein

minfeaturesize, maxfeaturesize

Wird in Pixeln eingegeben. Wenn die Größe eines Objektes (in Pixeln) unter der eingetragenen Grenze liegt, wird der Text des Objekts nicht mehr gezeichnet. Der Eintrag "auto" bewirkt die Beschriftung ausschließlich der Objekte, die größer sind als der zugehörige Text.

Partials

Zeigt Texte, die vom Kartenrand abgeschnitten werden.

"0" = ja: auch Teile des Textes sollen noch angezeigt werden.
"1" = nein: wenn der Text angeschnitten wird, ist er nicht mehr zu sehen.

Wird nichts angegeben, wird standardmäßig "0" gesetzt.

wrap

Ermöglicht es, Zeilenumbrüche in Texte einzufügen. Als "wrap" ist der Dezimalwert des entsprechenden ASCII-Zeichens (= "ANSI Character") einzugeben, der dann durch einen Zeilenumbruch ersetzt wird, z.B. "35" für das Zeichen "#".

the_force

Zwingt Beschriftungen zur Anzeige, ohne Rücksicht auf Kollisionen.

"0" = nein
"1" = ja

Wird nichts angegeben, wird standardmäßig "0" gesetzt.

Tabelle "layer"

Jeder Layer beinhaltet einen thematisch logischen und abgegrenzten Teilaspekt der Gesamtdatenmenge. Dabei wird in Raster-, Punkt-, Linien- und Flächenlayer unterschieden. Layer (soweit nicht Rasterlayer) können in kvwmap als Shapes vorliegen, aus einer PostgreSQL/PostGIS-Datenbank stammen oder als WMS bezogen werden.

Name

Der Name des Layers wird in der Legende angezeigt. Wird kein Name vergeben, wird dieser Layer nicht in der Legende angezeigt. Layernamen sollten keine Sonderzeichen enthalten, Umlaute und Leerzeichen sind dagegen kein Problem.

Datentyp

"0" = Punktlayer ("Point")
"1" = Linienlayer ("Line")
"2" = Flächenlayer ("Polygon")
"3" = Rasterlayer ("Raster")
"4" = Beschriftungslayer ("Annotation", erzeugt nur Beschriftungen)
"5" = Abfragelayer ("Query", wird nicht gezeichnet, kann nur abgefragt werden)
"6" = Kreislayer ("Circle", erzeugt Ellipsen durch die Angabe eines Rechtecks)

Ausführlichere Angaben, z.B. zum Ort der Beschriftung, siehe die deutschsprachige Mapfile-Referenz.

Der Datentyp muss nicht derselbe Typ sein wie das Feature selbst. Eine Polygon Feauture kann beispielsweise auch als Punkt-, Linien- oder Abfragelayer generiert werden.

Gruppe

Layer werden einer Gruppe zugeordnet. In der Legende erscheinen sie dann unter dieser Gruppenbezeichnung.

Query

Dieses Feld enthält vordefinierte SQL-Statements für die Sachdatenabfrage von PostGIS-Layern. Beispiele für ein Abfragestatement in diesem Feld sind:

SELECT * FROM gd_lk_fluren WHERE 1=1

SELECT *,AsText(koordinaten) AS punkte FROM fp_punkte_temp WHERE art IN (0,1)

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

Auf alle hier selektierten Tabellenfelder kann eine Abfrage durchgeführt werden, wenn der Layer abfragbar geschaltet ist. Soll von der Sachdatenanzeige zum Objekt in der Karte gezoomt werden, ist the_geom ebenfalls in der Query anzugeben. Die Reihenfolge der Attribute in der Abfrage bestimmt die Reihenfolge der Attribute in der Sachdatenanzeige.

Schwierigkeiten bereiten bestimmte SQL-Befehle, die Kommata enthalten sowie Abfragen über mehrere Tabellen, wenn oids uneindeutig sind oder ganz fehlen. In diesen Fällen bietet sich an, die eigentliche Abfrage in einen View zu schreiben und in Query (vielleicht auch in data) auf diesen View zuzugreifen. Möglicherweise ist es beim View dann allerdings nötig, Rules zu schreiben, die die INSERT-, UPDATE- und DELETE-Anweisungen durchführen.

Die Sachdatenanzeige erfolgt über den Generischen Layereditor. Bei besonderen Darstellungen kann alternativ auch ein Template" angelegt werden, dessen Dateiname im Feld "template" der Tabelle used_layer eingetragen wird.

Data

Bei Anbindung eines Shapes der Name des Shapes ohne Endung.
Bei Daten aus einer PostGIS-Tabelle wird die Geometriespalte und der Tabellenname angegeben, Beispiel:

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

Auch hier können komplexe Abfragen definiert werden, Beispiel:

centroid(the_geom) from (
 SELECT fl.objnr AS oid, fl.objnr AS id, fl.the_geom, ab.flurstkennz, ab.blattnr
 FROM alb_f_baulasten ab, alknflst f, alkobj_e_fla fl
 WHERE fl.folie = '001' AND ab.flurstkennz = f.flurstkennz AND f.objnr = fl.objnr
) as foo using unique oid using srid=2398

Wenn nicht einfach "the_geom from <tabellenname> ..." eingetragen wird, muss das in Klammern stehende SELECT alle für den Mapserver notwendigen Elemente aufführen: Das unique-Attribut (üblicherweise oid), eventuelle Beschriftungs- und Klassifizierungsattribute (LABELITEM, CLASSITEM, FILTERITEM), eventuell in den Expressions der Klassen verwendete Attribute und natürlich the_geom.

Das eingeschlossene SQL-Statement kann auch in einem View gespeichert werden.

schema

Speichert den Schemanamen in der Postgre-DB, in der die Tabelle liegt. Default ist "public".

documentpath

speichert die Angabe eines Pfades für einen Ordner, in dem layerbezogen die Dokumente abgelegt werden sollen. Wird hier nichts angegeben, ist CUSTOM_IMAGE_PATH aus der config.php der default.

tileindex

Wird nur bei Rasterlayern gesetzt. Wenn Rasterbilder gekachelt vorliegen und in einem Bildkatalog indiziert wurden, wird der Name des Index-Shapes hier angegeben. Die Eingabe im Feld "Data" entfällt. Hinweis: Die Indizierung kann z.B. mit dem Werkzeug gdaltindex aus der GDAL-Installation erfolgen.

tileitem

Wird nur bei indizierten Rasterlayern gesetzt. Attributname (= Spaltenüberschrift im Indexshape), in dem die Pfade zu den einzelnen Bildern stehen.

labelangleitem

Enthält den Attributnamen der Sachdaten des Layers, der die Winkel der Texte enthält. Braucht nur ausgefüllt werden, wenn beschriftet werden soll und der Text nach bestimmten Werten in den Sachdaten ausgerichtet werden soll.

labelitem

Wird nur gesetzt, wenn eine Beschriftung erzeugt werden soll. Attributname (= Spaltenüberschrift im entsprechenden Shape), aus dem die Beschriftung entnommen werden soll.

labelmaxscale

Größte Maßstabszahl, über die hinaus der Layer nicht mehr beschriftet wird (z.B. 400.000)

labelminscale

Kleinste Maßstabszahl, unterhalb der der Layer nicht mehr beschriftet wird (z.B. 500)

labelrequires

macht die Beschriftung abhängig von der Darstellung der Beschriftung eines anderen Layers, siehe Feld "requires" in der Tabelle used_layer.

connection

Die Angabe der connection entfällt bei Shapefiles. Die connection ist im Falle einer Datenbank die Zeichenkette der Datenbankverbindung, bestehend aus Benutzername, Passwort, Datenbankname, Hostnamen, Name des Vorgangs. Beispiel:

user=kvwmap password=****** dbname=kvwmapsp159 host=localhost port=5432

In der connection kann auch ein Dienst angegeben werden. Vom OGC-konformen Aufruf wird der "feste" Teil eingegeben, die änderbaren Parameter SRS, WIDTH, HEIGHT, BBOX und FORMAT werden von kvwmap bei jedem Aufruf an die in connection angegebene URL angehängt. Beispiel für eine WMS-Angabe:

http://geoportal.lk-nvp.de:8080/cgi-bin/mapserv?MAP=/home/fgs/fgs/www/wms/gemarkungen_fluren.map&REQUEST=getMap&VERSION=1.1.1&LAYERS=Gemarkungen,Fluren,Gemarkungsnamen,Flurnummern

Und so sieht der Aufruf beispielsweise vollständig aus:

 http://geoportal.lk-nvp.de:8080/cgi-bin/mapserv? \\
 MAP=/home/fgs/fgs/www/wms/gemarkungen_fluren.map& \\
 REQUEST=getMap& \\
 VERSION=1.1.1& \\
 LAYERS=Gemarkungen,Fluren,Gemarkungsnamen,Flurnummern& \\
 SRS=EPSG:2398& \\
 WIDTH=600&HEIGHT=500& \\
 BBOX=4550000,6010000,4560000,6018000& \\
 FORMAT=image/png
 
(Zur Übersichtlichkeit ist der Aufruf in mehrere Zeilen aufgetrennt.)

printconnection

Erlaubt die Angabe eines WMS, der im Druck für diesen Layer verwendet wird.

connectiontype

Der connectiontype ist die Einstellung des Verbindungstyps, z.B.:

"6" = postgis
"7" = WMS
"9" = WFS

Die Angabe des connectiontypes kann bei Shapefiles entfallen.

classitem

Attributname (= Spaltenüberschrift im entsprechenden Shape), aus dem die Class erzeugt werden soll.

filteritem

Angabe zum Einsatz der "Filter"-Ausdrücke aus der Tabelle "used_layer". Im Regelfall wird kein Filter definiert, dann sollte das Feld mit "id" gefüllt sein. Wird der Layer aus einer Sicht erzeugt, muss ein in der Sicht verwendeter Attributname (z.B. "objnr") eingetragen werden.

tolerance

Die Empfindlichkeit von punktbasierten Abfragen. Wie weit darf man den Punkt verfehlen, damit er dennoch gefangen wird? Gilt in kvwmap bei der Abfrage von PostGIS-Layern auch beim Aufziehen von Rechteckboxen.

toleranceunits

Einheit der Tolerance-Werte. Standardmäßig ist "pixels" gesetzt. Für die Abfrage von PostGIS-Layern wird die Angabe von "tolerance" mit der aktuellen Pixelgröße multipliziert. Ist "toleranceunits" leer wird auch die Pixelgröße verwendet, ist sie "meters" wird die "tolerance" mit 1 multipliziert.

epsg_code

Die Angabe des Koordinatensystems, in dem die Daten dieses Features vorliegen. Stimmt das originäre Koordinatensystem nicht mit dem Ausgabekoordinatensystem überein, dass im Feld "epsg_code" in der Tabelle Rolle definiert wird, werden die Koordinaten vom MapServer on-the-fly transformiert. Dieses Feld hat keine Bedeutung bei WMS-Layern. Dort wirkt das Feld ows_srs.

template

Defaulttemplate, der beim Einfügen des Layers in eine Stelle übernommen wird.

queryable

Defaultwert für die Abfragbarkeit des Layers, der beim Einfügen des Layers in eine Stelle übernommen wird.

transparency

Defaultwert für die Transparenz des Layers, der beim Einfügen des Layers in eine Stelle übernommen wird.

drawingorder

Defaultwert für die Zeichenreihenfolge des Layers, der beim Einfügen des Layers in eine Stelle übernommen wird.

minscale, maxscale

Defaultwerte für den Maßstabsbereich des Layers, die beim Einfügen des Layers in eine Stelle übernommen werden.

offsite

Defaultwert für den transparent zu zeichnenden RGB-Farbwert, der beim Einfügen des (Raster-)Layers in eine Stelle übernommen wird.

ows_srs

Angabe des Ausgabekoordinatensystems, wenn der Layer als WMS bzw. WFS von kvwmap zur Verfügung gestellt werden soll oder wenn der Layer einen externen WMS einbindet, in der Form:

"EPSG:<code>"

Es können alle Koordinatenreferenzsysteme angegeben werden, die der eigene kvwmap-Dienst anbieten soll bzw. alle Koordinatenreferenzsysteme, die die dienstanbietende Stelle im getCapabilities anbietet, in der Form:

"EPSG:<code1> EPSG:<code2> EPSG:<code3>"

Hat der Nutzer in seinen Optionen eine der angegebenen Kartenprojektionen ausgewählt, wird der Dienst in diesem EPSG angefordert (horizontale Texte und Linien erscheinen horizontal). Hat der Nutzer eine Kartenprojektion ausgewählt, die in diesem Feld nicht aufgelistet ist, transformiert der Mapserver das gelieferte Kartenbild (horizontale Texte und Linien erscheinen u.U. schräg).

wms_name

Angabe des Layernamens, wenn der Layer als WMS bzw. WFS zur Verfügung gestellt werden soll. Wird das Feld freigelassen, wird der im Feld "Name" verwendete Layername ausgegeben. Hinweis: Bei Layernamen, die deutsche Sonderzeichen enthalten, empfiehlt sich die Angabe eines WMS-Namens ohne deutsche Sonderzeichen.

wms_server_version

kvwmap unterstützt alle WMS-Versionen bis einschließlich 1.3.0

wms_format

Das Rasterformat des Ausgabebildes, wenn der Layer als WMS bzw. WFS zur Verfügung gestellt werden soll.

wms_connectiontimeout

Zeitspanne, nach der der WMS als "nicht verfügbar" klassifiziert wird und der Verbindungsaufbau auf diesen Layer abgebrochen wird.

wms_auth_username

Basiert der Layer auf einem passwortgeschützten WMS, wird hier der entsprechende Username gespeichert.

wms_auth_password

Basiert der Layer auf einem passwortgeschützten WMS, wird hier das entsprechende (verschlüsselte) Passwort gespeichert.

wfs_geom

Gibt bei WFS-Diensten mit mehreren Geometrie-Attributen dasjenige Attribut an, das Mapserver als Geometrie verwenden soll.

selectiontype

"radio" erzeugt in der Legende einen Radiobutton statt des üblichen Häkchenfeldes zum Ein- oder Ausschalten des Layers. Sind alle Layer einer Gruppe "radio", so kann also immer nur ein Layer in dieser Gruppe angeschaltet sein. Default ist NULL.

querymap

"1" = in der Sachdatenanzeige wird eine kleine Übersichtskarte mit dem Objekt gezeichnet. Default ist 0.

logconsume

Definiert, ob Zugriffe auf diesen Layer geloggt werden sollen:

"0" = Dieser Layer soll generell nicht geloggt werden
"1" = Dieser Layer kann geloggt werden.

Ob die Zugriffe auf die mit "1" gekennzeichneten Layer tatsächlich in der Tabelle u_consume2layer protokolliert werden, entscheidet die Einstellung des Feldes "logconsume" der jeweiligen Stelle, in der dieser Layer aufgerufen wird.

Tabelle "layer_attributes"

Jedes Attribut eines Layers kann im Generischen Layereditor angezeigt werden, wenn es im Query-Statement genannt wird.

name

Attributname, wie er im Query-Statement aus der Datenbank geholt wird (also nicht unbedingt identisch mit dem Tabellenattributnamen).

real_name

Tatsächlicher Tabellen-Attributname auf Datenbankebene.

tablename

Tatsächlicher Tabellen-Name auf Datenbankebene.

table_alias_name

Tabellen-Name, wie er im Query-Statement aus der Datenbank geholt wird (i.d.R. als Alias).

type

Datentyp des Attributes, wie er im Query-Statement aus der Datenbank geholt wird.

geometrytype

Geometrietyp des Attributs, wenn es vom Typ geometry ist.

constraints

Einschränkungen, die auf Datenbankebene in der Tabelle gesetzt sind.

nullable

'1', wenn das Attribut auf Datenbankebene NOT NULL ist. Default '0'.

length

Einschränkung der Zeichenkettenlänge auf Datenbankebene.

default

Standardwerte auf Datenbankebene, die bei Nichtausfüllen automatisch gesetzt werden bzw. von kvwmap im Generische Layereditor als Vorgabewert bei einem neuen Datensatz automatisch vorgeschlagen werden. Betrifft auch Vorgaben aus Sequenzen.

form_element_type

Beschreibung des Formelements, in dem das Attribut angezeigt wird:

Text
Textfeld
Auswahlfeld
Geometrie
SubFormPK
SubFormFK
SubFormEmbeddedPK
Dokument
Link
Time
User

SubFormPK und SubFormFK dienen der Erzeugung verschachtelter Tabellen. Time und User werden von kvwmap automatisch gefüllt. Weiter Informationen siehe die Dokumentation zum Generischen Layereditor.

options

Zuweisung bestimmter Vorgabewerte für den Attributtyp Auswahlfeld

alias

Zuweisung von (langschriftlichen) Attributnamen für die Anzeige im Generischen Layereditor zur besseren Lesbarkeit.

tooltip

Der hier gespeicherte Text erscheint in der Sachdateneinzeige des GLE als Tooltipp, wenn man mit dem Cursor über den Attributnamen fährt.

mandatory

'1': es handelt sich um ein Pflichtattribut in der Layersuche, das ausgefüllt werden muss. Default ist '0'.

order

speichert die Reihenfolge der Attribute in der Query-Angabe, die maßgeblich für die Reihenfolge der Attribute in der Sachdatenanzeige ist.

Tabelle "layer_attributes2stelle"

Setzt für jedes Attribut des Layers in jeder Stelle die Rechte des Benutzers auf das Attribut.

Attributname

Attributname, wie er im Query-Statement aus der Datenbank geholt wird (also nicht unbedngt identisch mit dem Tabellenattributnamen).

privileg

Bestimmt die Möglichkeiten des Users in der Stelle:

kein Eintrag = der User kann das Attribut nicht sehen
"0" = der User kann das Attribut lesen, aber nicht editieren
"1" = der User kann das Attribut editieren

tooltip

Bestimmt, ob das Attribut beim Überfahren des Objekts mit der Maus als Tooltip angezeigt wird oder nicht:

"0" = wird nicht als Tooltip angezeigt
"1" = wird als Tooltip angezeigt

Tabelle "m_grids"

Dient der Erzeugung eines Gitternetzes.

Tabelle "m_grids2used_layer"

Ordnet das Gitternetz aus der Tabelle "m_grids" einem Layer zu.

Tabelle "referenzkarten"

Diese Tabelle regelt den Aufbau der Übersichtskarte. Die Koordinatenwerte der linken unteren bzw. rechten oberen Ecke müssen der tatsächlichen ausdehnung des Koordinatenausschnitts im Koordinatensystem der Stelle entsprechen.

Name

Bezeichnung für die Übersichtskarte, kann frei gewählt werden.

Dateiname

Name der Rasterbild-Datei. Pfad zur Übersichtskarte ist in der config.php gesetzt!

xmin, ymin, xmax, ymax

Ausdehnung der Übersichtskarte.

width, height

Größe der Übersichtskarte (in Pixeln), z.B. 120, 90.

Tabelle "rolle"

Durch die Rolle werden dem jeweiligen Benutzer (User) beim Start von kvwmap verschiedene Stellen (mindestens eine) zunächst angeboten und nach erfolgter Auswahl zugeordnet. Für jeden User können beliebig viele Rollen angelegt werden. Zu jeder Rolle gehört genau eine Stelle. Erst durch die Rolle (d.h. eben durch die Zuweisung des Benutzers zu einer Stelle) werden dem Benutzer bestimmte Rechte verliehen, die sich aus der Zuordnung zur Stelle ergeben.

user_id

Die entsprechende ID aus der Tabelle "user". Es können beliebig viele Rollen angelegt werden, in denen die user_id identisch ist, nur muss jeweils das Feld "stelle_id" anders belegt werden.

stelle_id

Die entsprechende ID aus der Tabelle "stelle". Zum Begriff "Stelle" siehe dort.

nImageWidth, nImageHeight

Größe des Kartenfensters beim Start (in Pixeln), z.B. "500, 500". Diese Einstellung wird aus der jeweils letzten Sitzung übernommen.

minx, miny, maxx, maxy

Ausdehnung des Kartenausschnitts beim Start (in Koordinaten). Diese Einstellung wird aus der jeweils letzten Sitzung übernommen.

nzoomFaktor

Faktor, der das Maß des Herein- bzw. Herauszoomens bestimmt. "2" ist Verdoppelung bzw. Halbierung des Maßstabs. Diese Einstellung wird aus der jeweils letzten Sitzung übernommen.

selectedButton

Speichert, welcher Zoom-Button beim Beenden aktiviert war.

epsg_code

Definiert das Ausgabekoordinatensystem für den jeweiligen User in dieser Stelle. Hinweis: Jeder User einer Stelle kann also sein Kartenbild in einem anderen Koordinatensystem erhalten.

epsg_code2

Definiert ein zusätzliches Ausgabekoordinatensystem für den jeweiligen User in dieser Stelle, das nur für die Anzeige unter der Karte verwendet wird.

active_frame

Hier wird die aktuelle Druckrahmen-ID gespeichert.

last_time_id

Speichert den Zeitpunkt des letzten aufgerufenen Kartenausschnitts eines Users.

gui

speichert die graphische Oberfläche, die der User ausgewählt hat. Standard: "gui.php". Hinweis: Eigene GUIs können im Ordner layouts/custom von kvwmap gespeichert werden. Sie werden dann z.B. so angegeben: "custom/gui_1".

language

Speichert die Sprachversion, die der User in der Stelle auswählt.

charset

Speichert den entsprechenden zu verwendenden Zeichensatz, abhängig von language.

hidemenue

Speichert, ob der User in der Stelle das Menü zu- oder weggeschaltet hat.

hidelegend

Speichert, ob der User in der Stelle die Legende zu- oder weggeschaltet hat.

fontsize_gle

Speichert die Textgröße, die der User für die Sachdatenanzeige in der Stelle ausgewählt hat.

highlighting

Speichert, ob der User in der Stelle die Objekte gehighlightet haben will oder nicht.

buttons

Speichert, welche Buttons der Navigationsleiste der User in der Stelle benutzen will.

scrollposition

Speichert die Position des Scrollbalkens an der Legende.

result_color

Speichert die ID der Farbe aus der Tabelle colors, die für die Anzeige von Suchergebnissen verwendet werden soll.

Tabelle "rollenlayer"

Ersetzt die Einträge in den Tabellen layer, used_layer, u_rolle2used_layer und classes, wenn ein Layer nicht allen Usern der Stelle zur Verfügung stehen soll, z.B. die Suchergebnislayer. Zu den entsprechenden Feldern siehe die Beschreibungen in den genannten Tabellen.

Tabelle "rolle_nachweise"

Dient der Speicherung von Suchpolygonen für die Fachschale Nachweisverwaltung.

Tabelle "stelle"

Der Begriff "Stelle" meint eine Arbeitsstelle oder besser Arbeitsaufgabe. An die Stelle ist eine festgelegte Benutzeroberfläche geknüpft mit allen daran hängenden Rechten an Funktionen, räumlicher Ausdehnung und Bedienelementen. Die Stelle definiert auch den Zugriff auf die Daten, die der Benutzer sehen und abfragen darf.

Bezeichnung

Wenn der Benutzer kvwmap startet, kann er aus den Stellen auswählen, die ihm über die Rolle zugewiesen wurden. In der Auswahl erscheint die Bezeichnung der Stellen.

start, stop

Damit kann die zeitliche Zuordnung des Benutzers zur Stelle eingestellt werden, z.B. bei Auslegungsfristen für Bürgerbeteiligungen oder für zeitlich begrenzte Gast-Zugriffe.

minxmax, minymax, maxxmax, maxymax

Maximal erlaubte Ausdehnung (in Koordinaten) des Kartenausschnitts, z.B. der gesamte Landkreis, die Stadt oder eine Gemeinde.

epsg-code

Default-EPSG, wenn die Stelle als neue Stelle kopiert wird.

Referenzkarte_ID

Die entsprechende ID aus der Tabelle "referenzkarten" zur Anbindung der Übersichtskarte. Zum Begriff "Referenzkarte" siehe dort.

Authentifizierung

Regelt, ob für den Zugriff auf diese Stelle eine Benutzerauthentifizierung nötig ist ('1') oder nicht ('0').

ALB_status

Regelt die PDF-Ausgabe des ALB.

"30" = Eigentümerangaben nicht sichtbar
"35" = Eigentümerangaben sichtbar.

wappen

Dateiname des zugehörigen Wappens (Pfad wird in die config.php eingetragen).

wasserzeichen

ermöglicht das Zeichnen eines Textes, der als Wasserzeichen in der Karte angezeigt wird.

alb_raumbezug

Mit "alb_raumbezug" und "alb_raumbezug_wert" kann man eine räumliche Einschränkung auf die ALB-Daten für eine Stelle vornehmen. Auswahlmöglichkeiten: "Kreis", "Amt", "Gemeinde".

alb_raumbezug_wert

Gibt den Schlüssel des Kreises/des Amtes/der Gemeinde an.

logconsume

"0" = es erfolgt keine Protokollierung der Layerzugriffe für die User dieser Stelle
"1" = wenn ein User dieser Stelle in der Karte navigiert oder eine Layerauswahl vornimmt, werden alle logbaren Layer in der Tabelle u_consume2layer mit Angabe eines Zeitstempels gespeichert.

Hinweis: Es werden nur die Layer der Stelle protokolliert, die im Feld "logconsume" der Tabelle layer als protokollierbar gekennzeichnet sind.

ows_ ...

Einträge, die relevant sind, wenn Daten der Stelle als Dienst angeboten werden. Die Einträge erscheinen im GetCapabilities-Dokument.

check_client_ip

"1" = es erfolgt eine Prüfung ob der User von einer der in der Tabelle user in Spalte ips eingetragenen IP Adressen aus auf kvwmap zugreift.
"0" = keine Prüfung

check_password_age

"1" = es erfolgt eine Prüfung ob das Password des Nutzers zum Zeitpunkt des Einloggens älter ist als in Spalte allowed_password_age für die Stelle angegeben. Tritt der Fall ein, muss der Nutzer erst sein Passoword ändern um sich einloggen zu können. (Funktion ist in Version 1.7.0 in Arbeit)
"0" = es erfolgt keine Prüfung

allowed_password_age Erlaubtes Alter der Passwörter der Benutzer die sich an der Stelle anmelden wollen. Angegeben als ganze Zahl, eine Anzahl von Monaten definiert. Wirkt nur wenn check_password_age=1 für die Stelle gesetzt ist.

Tabellenstruktur:

CREATE TABLE `stelle` (
 `ID` int(11) NOT NULL auto_increment,
 `Bezeichnung` varchar(255) character set latin1 NOT NULL default ,
 `Bezeichnung_low-german_windows-1252` varchar(255) character set latin1 default NULL,
 `Bezeichnung_english_windows-1252` varchar(255) character set latin1 default NULL,
 `Bezeichnung_vietnamese_utf-8` varchar(255) character set latin1 default NULL,
 `start` date NOT NULL default '0000-00-00',
 `stop` date NOT NULL default '0000-00-00',
 `minxmax` double default NULL,
 `minymax` double default NULL,
 `maxxmax` double default NULL,
 `maxymax` double default NULL,
 `epsg_code` int(5) NOT NULL default '2398',
 `Referenzkarte_ID` int(11) default NULL,
 `Authentifizierung` enum('0','1') character set latin1 NOT NULL default '1',
 `ALB_status` enum('30','35') character set latin1 NOT NULL default '30',
 `wappen` varchar(150) character set latin1 NOT NULL default 'wappen_nvp.png',
 `wasserzeichen` varchar(150) character set latin1 default NULL,
 `alb_raumbezug` set(,'Kreis','Amtsverwaltung','Gemeinde') character set latin1 NOT NULL default ,
 `alb_raumbezug_wert` varchar(255) character set latin1 NOT NULL default ,
 `logconsume` enum('0','1') character set latin1 default NULL,
 `pgdbhost` varchar(25) character set latin1 NOT NULL default 'localhost',
 `pgdbname` varchar(25) character set latin1 default NULL,
 `pgdbuser` varchar(25) character set latin1 default NULL,
 `pgdbpasswd` varchar(25) character set latin1 default NULL,
 `ows_title` varchar(255) character set latin1 default NULL,
 `wms_accessconstraints` varchar(255) character set latin1 default NULL,
 `ows_abstract` varchar(255) character set latin1 default NULL,
 `ows_contactperson` varchar(255) character set latin1 default NULL,
 `ows_contactorganization` varchar(255) character set latin1 default NULL,
 `ows_contactemailaddress` varchar(255) character set latin1 default NULL,
 `ows_contactposition` varchar(255) character set latin1 default NULL,
 `ows_fees` varchar(255) character set latin1 default NULL,
 `ows_srs` varchar(255) character set latin1 default NULL,
 `check_password_age` enum('0','1') character set latin1 NOT NULL default '0',
 `allowed_password_age` tinyint(4) NOT NULL default '6',
 `check_client_ip` enum('0','1') character set latin1 NOT NULL default '0',
 PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci;

Tabelle "stelle_gemeinden"

Sowohl Adress- als auch Flurstückssuche können auf die Gemeinden, auf die die Stelle Zugriff haben soll, eingeschränkt werden.

Stelle_ID

Die ID der Stelle, die die Einschränkung erfahren soll.

Gemeinde_ID

Der (achtstellige) Gemeindeschlüssel der Gemeinde, die in dieser Stelle zur Auswahl stehen soll. Sollen mehrere Gemeinden in der Stelle zur Auswahl stehen, werden für die entsprechende Stelle mehrere Einträge erzeugt.

Tabelle "styles"

Styles beinhalten Parameter zur Symbolisierung und Ausgestaltung der im Layer enthaltenen Geometrien.

symbol

Die laufende Nummer des Symbols in der Symboldatei (z.B. symbols.sym). Beginnend mit 1, ist also das fünfte Symbol die Nummer 5. In der Symboldatei müssen dafür keine Nummern explizit angegeben werden.

Hinweis: Große Schwierigkeiten gibt’s, wenn Symbole in die Symbol-Datei eingefügt werden. Besser nur den Symbolnamen verwenden und das Feld "Symbol" grundsätzlich freilassen.

symbolname

Wenn die Symbole der Symboldatei Namen haben, sollten diese benutzt werden. Diese Verfahrensweise ist derjenigen der Symbolnummern vorzuziehen.

size

Angabe der Höhe (in Pixeln) des Symbols bzw. des Musters, wenn es sich um einen Linienlayer handelt. Werden "Sizeunits" gesetzt, bezieht sich die Angabe auf die definierte Einheit (momentan von kvwmap noch nicht unterstützt).

Für Symbole vom Type HATCH ist der angegebene Wert der Abstand zwischen den Schraffurlinien.

Die Umrandungen von Flächenlayern werden immer mit size=1 erzeugt. Sollen hier andere Größen bzw. auch Muster erscheinen, müssen Fläche und Umringslinie über zwei Classes und zwei Styles separat definiert werden.

"Size" bei Flächenlayern in Kombination mit der Angabe von "Symbol" erzeugt eine Flächenfüllung mit dem angegebenen Muster und der angegebenen Größe.

Sollen Flächenlayer, die nur eine Farbe enthalten (siehe color), druckbar sein, darf für size niemals der Wert 0 gesetzt werden. Bei der Druckaufbereitung wird der Wert für size mit in die Umrechnung der Auflösung mit einbezogen. Wenn size=0 eingestellt ist hat das zur Folge, dass der entsprechende layer weder in der Druckvorschau noch im Druck ausgegeben wird.

color

Farbe des Symbols, der Linie, der Fläche. Wird angegeben in "R G B" (3 Zahlen mit Leerzeichen getrennt: "125 200 50").

backgroundcolor

Angabe einer Farbe für nicht-transparente Symbole.

outlinecolor

Angabe einer Farbe, um Polygone und bestimmte Markersymbole zu umranden. Linien haben keine outlinecolor, hier müssen gegebenenfalls mehrere Styles miteinander kombiniert werden.

minsize, maxsize

Definiert die minimale bzw. maximale Anzahl der Pixel, um ein Symbol zu zeichnen. Hinweis: Damit die Darstellung skalierbar wird, müssen in der Tabelle "used_layer" ein Wert für symbolscale und die Werte für minscale und maxscale gesetzt sein.

angle

Angabe des Winkels, unter dem alle Symbole der class erscheinen sollen. Wenn kein Wert angegeben werden soll (z.B. bei Kreissignaturen), darf nicht '0' eingetragen werden, sondern 'NULL' oder '360'.

angleitem

Angabe des Attributs in einem Layer, in dem der jeweilige Winkel eines Symbols gespeichert ist.

antialias

'1': Schaltet die Kantenglättung bei TrueType- und Cartoline-Symbolen ein. Hat keine Auswirkungen auf andere Style-Typen.

width

Die Dicke der zu zeichnenden Linien in Pixel, Default ist 1. Bei Symbolen vom Typ HATCH wird mit width die Breite der Schraffurlinien angegeben.

minwidth, maxwidth

Minimale bzw. maximale Breite von Linien (in Pixel). Damit Linienstärken skalieren, muss in der Tabelle layer ein Symbolscale eingetragen sein und in der Tabelle used_layer ein minscale bzw. maxscale.

sizeitem

Wenn die Größe der Linien in einem Attribut gespeichert wird, kann man den Attributnamen angeben. Damit können die Objekte einer Klasse verschieden breite Linien bzw. verschieden große Symbole bekommen.

offsetx, offsety

Verschiebt das Symbol um den angegebenen Betrag in X- bzw. Y-Richtung. Die Eingabe von negativen Werten ist möglich.

Die Anwendergruppe kvwmap veröffentlicht Symbole, Signaturen und karthographische HowTos hier in diesem WIKI. Weitere Informationen zur Erstellung von Symbolen und Liniensignaturen z.B. hier: http://mapserver.org/de/mapfile/symbology/construction.html

Tabelle "used_layer"

Jeder Stelle können beliebig viele Used Layer zugeordnet werden. Zu jedem Used Layer gehört genau ein Layer. Umgekehrt ausgedrückt: Durch die Tabelle "used_layer" kann ein Layer beliebig vielen Stellen zugeordnet werden.

stelle_id

Die entsprechende ID aus der Tabelle "stelle".

layer_id

Die entsprechende ID aus der Tabelle "layer". Zum Begriff "Layer" siehe dort.

queryable

Layer können als abfragbar ("1") oder nicht abfragbar ("0") gekennzeichnet werden. Entsprechend ist das Info-Häkchenfeld in der Legende vorhanden oder nicht.

drawingorder

Die Zeichenreihenfolge, in der die Layer dargestellt werden, ist entscheidend für das Aussehen der Karte. Der Layer mit der kleinsten drawingorder wird zuerst gezeichnet. Die drawingorder regelt weiterhin die Position des Layers innerhalb der Gruppe in der Themenauswahl/Legende. Die drawingorder kann bis zu elf Stellen besitzen, es empfiehlt sich also, großzügig bei der Vergabe zu sein, um später in kvwmap integrierte Layer noch sinnvoll einfügen zu können. Rasterlayer sollten zuerst gezeichnet werden, Beschriftungslayer zuletzt.

Durch die Angabe der Zeichenreihenfolge in den Used Layern kann jeder Stelle individuell eine eigene Zeichenreihenfolge gegeben werden.

minscale

Kleinste Maßstabszahl, unterhalb der der Layer nicht mehr angezeigt wird (z.B. 500).

maxscale

Größte Maßstabszahl, über die hinaus der Layer nicht mehr angezeigt wird (z.B. 10.000).

offsite

erzeugt einen Farbindex [R G B] bei Rasterlayern, um sie transparent zu machen.

transparency

Wert, der angibt, wie opak der Layer sein soll, zwischen

"0" = vollkommen durchsichtig und
"100" = gar nicht durchsichtig.

postlabelcache

Zeichnet den Layer nach allen anderen und auch nach der Beschriftung, wenn "1" angegeben wird.

Filter

Dieser Parameter erlaubt für Daten spezifische Attributfilter einzusetzen, die zur selben Zeit abgearbeitet werden wie die räumlichen Filter, aber bevor irgendwelche CLASS-Ausdrücke ausgewertet werden.

Beispiel zur Einschränkung über den Gemarkungsschlüssel:

für eine bestimmte Gemarkung - (gemkgschl = '132100')
oder bei mehreren Gemarkungen - (gemkgschl = '132100' or gemkgschl = '132105')
oder mit Platzhaltern - (gemkgschl = '1321%')

"gemkschl" ist der Spaltenname zu den Objekten, die in der PostgreSQL-Datenbank gehalten werden, und um dessen Wert die Anfrage gefiltert werden soll.

template

Angabe eines PHP-Snippets, wenn NICHT der Generische Layereditor für die Sachdatenanzeige verwendet werden soll. Wenn Layer in verschiedenen Stellen unterschiedliche Sachdatenanzeigen bekommen sollen, können verschiedene Snippets zur Anzeige definiert werden. (Beispiel: biotope_amt1.php, biotope_amt2.php, etc.)

symbolscale

Gibt den Maßstab an, bei dem ein Symbol oder eine Beschriftung die Größe haben soll, die ihm in der Tabelle "styles" bzw. "labels" als size zugewiesen ist. Funktioniert nur, wenn gleichzeitig die Felder "minsize" und "maxsize" in der Tabelle "styles" bzw. "labels" mit Werten gefüllt sind.

Werden bei "symbolscale" keine Angaben gemacht, hat das Symbol bzw. die Beschriftung immer genau die Größe, die durch "size" definiert ist.

requires

Angabe um den Zusammenhang zum Anzeigen des Layers festzulegen. Beispiel für einen Layer "Gebäudepunkte":

([Gebäude] = 1)

D.h. der Layer "Gebäudepunkte" ist nur dann sichtbar, wenn auch der Layer "Gebäude" sichtbar ist. Hinweis: In der Legende bzw. Themenauswahl erscheint der Layername dann nicht mehr (im Beispiel also der Layer "Gebäudepunkte"), es werden nur noch seine Classes angezeigt.

logconsume

entscheidet, ob der Zugriff auf den Layer in der Tabelle u_consume2layer geloggt werden soll.

privileg

Regelt den grundsätzlichen Zugriff auf sämtliche Objekte des Layers in der Stelle im Generischen Layereditor. Die Rechte auf die einzelnen Attribute des Layers werden in der Tabelle layer_attributes2stelle gesetzt.

"0" = Der User darf sämtliche Attribute lesen und bearbeiten
"1" = Der User darf lesen, bearbeiten und neue Datensätze erzeugen
"2" = Der User darf lesen, bearbeiten, neue Datensätze erzeugen und Datensätze löschen.

start_aktiv

'1': Schaltet den Layer automatisch ein, wenn es sich um eine Gast-Stelle handelt. Default ist '0'.

Tabelle "user"

In dieser Tabelle werden die einzelnen Benutzer von kvwmap eingetragen. Jeder Benutzer wird mit Name und Vorname einzeln eingetragen. Das Anlegen von Gruppenbezeichnungen ("Naturschutz", "Kataster" o.ä.) empfiehlt sich nicht. Hier erfolgt keine Zuweisung von Rechten oder Daten!

login_name

Der Login-Name erscheint im Browserfenster als "Nutzer" unten rechts.

ips

Hier können eine oder mehrere mit ; getrennte IP Adressen eingetragen werden, von denen der Nutzer aus auf kvwmap zugreifen darf. Tritt aber nur in Kraft, wenn in Tabelle stelle in die Spalte check_client_ip eine 1 eingetragen wurde. Wenn check_client_ip=1 ist und in dieser Spalte ips steht nichts, bekommt der User keinen Zugang.

password_setting_time

Hier wird das Datum eingetragen an dem der Nutzer das letzte mal das Passwort geändert hat. Wird berücksichtigt, wenn in der Stelle in der der Nutzer sich anmelden will (siehe Tabelle stelle), der Parameter check_password_age = 1 gesetzt ist. Die Zeitdifferenz zwischen der aktuellen Zeit und der hier eingetragenen darf dann nicht größer sein als in der Spalte allowed_password_age in der Tabelle stelle.

Funktion

Wenn es sich um einen Gast-Nutzer handelt, wird 'gast' eingetragen. Default ist 'user'.

stelle_id

Hier wird die Stelle angegeben, der dieser User beim ersten Start von kvwmap zugeordnet sein soll.

Tabelle "u_attributfilter2used_layer"

Speicherung der Attribut-Filter der Layer einer Stelle. Diese Tabelle wird von kvwmap bei Benutzung des entsprechenden Menüs gefüllt.

Tabelle "u_consume"

Speichert die räumliche Ausdehnung aller Kartenausschnitte, die von den Benutzern generiert werden. Diese Tabelle wird von kvwmap bei Benutzung des entsprechenden Menüs gefüllt.

user_id

Speichert die ID-Nummer des Benutzers.

stelle_id

Speichert die ID-Nummer der Stelle, die der User im Moment der Ausschnittgenerierung gewählt hat.

time_id

Speichert Datum und Uhrzeit des Zeitpunkts, an dem der Ausschnitt erzeugt wurde.

activity

Speichert die Art des Zugriffs.

nimagewidth, nimageheight

Speichert die Kartenfenstergröße.

minx, miny, maxx, maxy

Speichert die Eckpunktkoordinaten des erzeugten Kartenausschnitts.

prev, next

Speichert, ob dieser Kartenausschnitt über die History-Funktion entstanden ist und ob er einen Vorgänger- bzw. Nachfolgerkartenausschnitt hat.

Tabelle "u_consume2comments"

Wenn ein Nutzer einen räumlichen Ausschnitt über die Funktion Kartenausschnitt speichern speichert, dann wird von kvwmap diese Tabelle bei Benutzung des entsprechenden Menüs gefüllt.

Tabelle "u_consume2layer"

Diese Tabelle speichert die Auswahl der Layer, die ein Benutzer in einer Stelle auswählt. Damit diese Protokollierung erfolgt, muss das Feld "logconsume" der entsprechenden Stelle in der Tabelle stelle mit "1" belegt werden.

Tabelle "u_consumeALB"

Speichert die druckenden Zugriffe eines Users auf das ALB, das jeweils ausgedruckte ALB-Format und die Anzahl der ausgedruckten Seiten. Wird von kvwmap bei Benutzung des entsprechenden Menüs ausgefüllt.

Tabelle "u_consumeALK"

Speichert die druckenden Zugriffe eines Users auf die ALK und den jeweils verwendeten Druckrahmen. Wird von kvwmap bei Benutzung des entsprechenden Menüs ausgefüllt.

Tabelle "u_funktion2stelle"

Die Zuweisung der Funktionen zur jeweiligen Stelle. Dadurch wird erreicht, dass bestimmte Funktionen nur bestimmten Stellen zur Verfügung stehen.

Funktion_id

Die entsprechende ID aus der Tabelle "u_funktionen".

Stelle_id

Die entsprechende ID aus der Tabelle "stelle".

Erlaubt

Wenn eine Funktion zugeordnet werden soll, muss sie mit "1" auch explizit erlaubt werden.

Tabelle "u_funktionen"

Funktionen sind spezielle Anwendungen, deren Ablauf in der index.php definiert wird. Mit Funktionen sind nicht die Navigationswerkzeuge oder die Menüs gemeint, sondern bestimmte Anwendungen wie etwa die Anzeige von Eigentümerdaten, für die benutzerbezogen Rechte vergeben werden müssen.

Bezeichnung

Der Name wird in der Funktionenauswahl angezeigt.

Link

Der Link weist auf den Anwendungsfall, der in der index.php definiert ist. Zur Schreibweise siehe Tabelle u_menues.

Derzeit läuft es so, dass man die Funktion so definiert, wie der Anwendungsfall, den man schützen will. Also wenn man z.B. den Anwendungsfall: "ALB_Aenderung" schützen möchte, muss "ALB_Aenderung" in Bezeichnung eingegeben werden.

In der index.php werden diese Einschränkungen für den jeweiligen Anwendungsfall aber nur dann wirksam, wenn die Rechteeinschränkung abgefragt wird.

Ein Anwendungsfall ohne Rechteeinschränkungsmöglichkeit:

case "Anwendungsfall" :
{
 $GUI->functiondieausgefuehrtwerdensoll();
}

Anwendungsfall mit Einschränkungsmöglicheit:

case "Anwendungsfall" :
{
   if ($GUI->Stelle->isFunctionAllowed($GUI->formvars['go'])) {
     $GUI-> functiondieausgefuehrtwerdensoll();
   }
   else {
     # Benutzer ist nicht berechtigt zum Ausführen der Funktion
     $GUI->Fehlermeldung='Sie sind nicht berechtigt diesen Anwendungsfall auszuführen.';
     $GUI->rollenwahl($Stelle_ID);
     $GUI->output();
   }
}

Man sieht, dass im Falle der erteilten Berechtigung der Anwendungsfall ausgeführt wird und man sonst auf die Stellenauswahl geleitet wird. Man könnte meinen, dass diese Verzweigung generell für alle Anwendungsfälle vor der Abarbeitung der cases ausgeführt werden könnte, dann kann man aber nicht individuell entscheiden was geschehen soll, wenn keine Rechte vorliegen.

Bisher gilt also, wenn Sie Anwendungsfälle extra schützen wollen (zusätzlich zu der Möglichkeit den Link zur Anwendung in der Stelle gar nicht erst anzuzeigen) dann teilen sie es den Entwicklern mit und diese können das fest in die index.php aufnehmen. Es hindert sie natürlich keiner daran ihre eigene index.php zu erstellen. Achtung dann aber beim Update.

Tabelle "u_groups"

Speichert den Namen einer Gruppe. Alle Layer werden einer Gruppe zugeordnet.

Tabelle "u_groups2rolle"

Speichert benutzerbezogen, ob die Layer einer Gruppe gerade sichtbar sind oder nicht.

Die Felder "user_id", "stelle_id" und "id" müssen für jeden User in jeder Stelle erstellt werden. In das Feld "Status" speichert kvwmap den jeweiligen Zustand der Gruppe.

Tabelle "u_labels2classes"

Da mehrere Label zu einer Class gehören können, wird die Zuordnung des jeweiligen Labels in einer eigenen Tabelle vorgenommen.

class_id

Die entsprechende ID aus der Tabelle "classes".

label_id

Die entsprechende ID aus der Tabelle "labels".

Tabelle "u_menue2rolle"

Speichert für jeden User, ob ein Menü aufgeklappt ist oder nicht.

Tabelle "u_menue2stelle"

Die Zuweisung der Menüs zur jeweiligen Stelle. Dadurch wird erreicht, dass bestimmte Menüs nur bestimmten Stellen zur Verfügung stehen.

stelle_id

Die entsprechende ID aus der Tabelle "stelle".

menue_id

Die entsprechende ID aus der Tabelle "u_menues".

menue_order

Reihenfolge der Darstellung bei der Sortierung der Menüs in der Stelle. Das Menü mit der kleinsten Menue_order-Nummer wird zuerst gezeichnet. Die Nummer kann bis zu elf Stellen besitzen, es empfiehlt sich also, großzügig bei der Vergabe zu sein, um später für die Stelle hinzukommende Menüs noch einfügen zu können.

Tabelle "u_menues"

Menüs sind bestimmte Funktionen, z.B. die Suchfunktionen oder die Hilfe. Mit Menü ist nicht die Themenauswahl oder die Navigationsleiste gemeint. Jeder Stelle können unterschiedliche Menüs zugeordnet werden.

Menüs werden weiterhin für die Fachschalen benötigt.

name

Der Name wird im Menütext angezeigt.

links

Der Link weist auf den Anwendungsfall, der in der index.php definiert ist. Beispiel: Der Nutzer soll Flurstücke suchen können. Der Anwendungsfall in der index.php lautet "Flurstueck_Auswaehlen". Der entsprechende Eintrag im Feld "Links" lautet dann "index.php?go=Flurstueck_Auswaehlen"

obermenue

Die Menüs werden verschachtelt. Es gibt Obermenüs und darunter angeordnet Untermenüs. Soll ein Menü ein Untermenü sein, so wird hier die ID des entsprechenden Obermenüs angegeben. Beispiel: Die Flurstückssuche soll keinem Obermenü zugeordnet werden. Im Feld wird eine "0" eingetragen.

Beispiel: Die ALB-Fortführung soll ein Untermenü im Menü "Fortführung" sein. Das Menü "Fortführung" hat die ID "17". Diese ID wird im Feld eingetragen.

menueebene

Die Verschachtelungstiefe wird in Ebenennummern beginnend bei "1" angegeben. Beispiel: Die Flurstückssuche soll in der Verästelung am Anfang stehen. Im Feld wird eine "1" eingetragen. Beispiel: Die ALB-Fortführung soll in der Verästelung unter dem Menü "Fortführung" erscheinen. Im Feld wird eine "2" eingetragen, da das Menü "Fortführung" die Menüebene "1" hat.

target

"_blank" öffnet ein neues Fenster. Das kann z.B. bei der Hilfe nützlich sein. Standardmäßig wird nichts eingetragen, dann wird die Funktion im gleichen Fenster ausgeführt.

order

Mit der Spalte "order" lassen sich die Menüpunkte sortieren. Allerdings wirkt sich diese Sortierung nicht global und sofort aus, sondern durch die Werte in dieser Spalte wird die Reihenfolge der Menüpunkte für die Stellen-Zuweisung in kvwmap festgelegt. Diese Spalte ist also dafür da, damit beim Zuweisen eines Obermenüpunktes mit seinen Unterpunkten an eine bestehende Menüstruktur einer Stelle der neue Menüpunkt nicht immer ganz unten angehängt wird, sondern eben entsprechend seinem Wert "order" innerhalb der vorhandenen Menüstruktur. Für Untermenüpunkte gilt der Wert der Spalte "order" nur innerhalb des jeweiligen Obermenüpunktes. Dort können dann Werte wie z.B. 1,2,3,4,5 drin stehen, während der zugehörige Obermenüpunkt den order-Wert 3 hat.

Tabelle "u_rolle2used_layer"

Die Tabelle speichert beim Verlassen von kvwmap den Status der Häkchenfelder in der Legende. Damit werden die Einstellungen eines Benutzers gespeichert, unabhängig davon, ob ein anderer Benutzer in der selben Stelle andere Einstellungen vornimmt.

aktivStatus

Speichert benutzerbezogen den letzten Zustand dieses Layers in Bezug auf die Sichtbarkeit.

"0" = Layer ist ausgeschaltet
"1" = Layer ist eingeschaltet
"2" = Layer ist eingeschaltet, aber in der Legende nicht sichtbar, weil die Gruppe zugeklappt ist.

queryStatus

Speichert benutzerbezogen den letzten Zustand dieses Layers in Bezug auf seine Abfragbarkeit.

"0" = Layer ist nicht abfragbar geschaltet
"1" = Layer ist abfragbar geschaltet
"2" = Layer ist abfragbar geschaltet, aber in der Legende nicht sichtbar, weil die Gruppe zugeklappt ist.

showclasses

Speichert benutzerbezogen, ob die Classes des Layers ein- oder ausgeblendet sind.

logconsume

"0" = Layer wird nicht geloggt.
"1" = Layer wird innerhalb der Stelle für den bestimmten Nutzer geloggt. Z.B. für User Müller innerhalb der Gemeinde xy für den Layer Flurstücke.

Damit die Protokollierung erfolgt, muss entweder in der Tabelle stelle oder in der Tabelle layer oder in der Tabelle used_layer das Feld "logconsume" = "1" gesetzt sein.

Tabelle "u_styles2classes"

Da mehrere Styles zu einer Class gehören können, wird die Zuordnung des jeweiligen Styles in einer eigenen Tabelle vorgenommen.

class_id

Die entsprechende ID aus der Tabelle "classes".

style_id

Die entsprechende ID aus der Tabelle "styles".

drawingorder

Legt die Zeichnungsreihenfolge der Styles fest, wenn (z.B. bei komplexeren Linienausgestaltungen) mehrere Styles in einer Class enthalten sind.

API Doc

Automatisierte Dokumentation der Klassen und dessen Funktionen aus Kommentaren im Quelltext

Ich habe mal einen ersten Versuch unternommen mit PHPDoc eine Referenzdokumentation zu allen in kvwmap vorhandenen Klassen zu erstellen. Das Resultat liefert zwar schon alle Klassen und dazugehörigen Funktionen und Parameter, aber ist noch weitestgehend ohne zusätzliche Beschreibung. Die Dokumentation im Quellcode kann aber nach und nach so angepasst und erweitert werden, dass daraus eine passable API Doc wird. Für die Funktion loadMap habe ich das mal beispielhaft gemacht. Es bedarf wirklich nur ein paar formatierter Zeilen Kommentar, die so aussehen:

/**
* Laden der Daten für das Map-Objekt aus Variablen, der Datenbank und/oder einer Map-Datei.
* 
* Diese Funktion ließt die Werte, die notwendig sind um die Karte zu konfigurieren. Die Quellen werden in Abhängigkeit vom Parameter $loadMapSource aus Variablen, aus einer Datenbank oder aus einem MapFile
* 
* Reihenfolge: Übersichtssatz - Kommentar - Tags.
* 
* @param  string	$loadMapSource Art der Quelle, aus der die Werte für das Map-Objekt gelesen werden sollen
*                 Mögliche Werte zur Zeit:
*                 Post: Werte werden aus Variablen gelesen, die über Post mitgeschickt wurden
*                        Dabei werden einige defaultmäßig zu setzende Parameter aus dem angegebenen MapFile gelesen.
*                 File: Die Werte für das Map-Objekt werden aus einer Map-Datei gelesen
*                 DataBase: Dies ist der Standardfall. Die Werte für das Map-Objekt werden aus der Datenbank gelesen.
* @return boolean	liefert derzeit immer true zurück.
* @see    db_mapObj(), $map
*/

Die Kommentare finden sich dann dirket in der Dokulmentation wieder, siehe [3]. Um nach einer Änderung eine aktuelle API Doc zu erstellen muss man nur den Link [4] aufrufen. Alle Dokumentationsdateien werden daraufhin in ca. 8 Sekunden neu erstellt.

Benutzung von kvwmap

Stelle Wählen

Die Anzeige von Karteninhalten erfolgt immer über Stellen. Jeder Benutzer ist einer oder mehreren Stellen zugewiesen. Innerhalb der Stellen kann der Benutzer seine eigenen Einstellungen speicher. Einige werden auch automatisch gespeichert, z.B. der letzte Kartenausschnitt, die letzten aktiven Layer und welche Menüpunkte aufgeklappt waren. Um in eine bestimmte Stelle zu wechsen benutzt man den Menüpunkt "Stelle wählen", der standardmäßig in allen Menüs enthalten ist.

In dem Formular können die verfügbaren Stellen (ggf. steht nur eine zur Verfügung) ausgewählt werden. Wenn eine andere Stelle gewählt wird, werden automatisch die Einstellungen der unten angegebenen Parameter nachgeladen und angezeigt. Möchte man diese Parameter auch verändern, werden diese über den Butten "Weiter" gespeichert. Damit kommt man auch zur Kartendarstellung der gewählten Stelle.

Zoomfaktor

Mit Zoomfaktor legt man fest um das wievielfache der Zoom erfolgen soll, wenn man mit dem einfachen Zoomwerkzeug "Hereinzoomen" und "Herauszoomen" Zoomen möchte. Achtung! Wenn hier der Wert 1 steht, erfolgt nur eine Verschiebung zur angeklickten Stelle, keine Maßstabsänderung. Steht hier etwa ein negativer Wert, wird Hineinzoomen zum Herauszoomen und umgekehrt.

Graphische Oberfläche

Über die Auswahlliste Graphische Oberfläche kann, soweit vom Administrator angeboten, ein anderes Layout gewählt werden. Wenn man ein angepasstes eigenes Layout haben möchte, muss man eine eigene php-Datei erzeugen. Dazu fragt man am besten bei den Entwicklern nach oder schaut sich die Datei gui.php an und kopiert eine veränderte Datei in das Verzeichnis layouts/custom. Diese ist dann für alle auswählbar.

Kartenfenstergröße

Hier stellt man die Größe des Kartenfensters ein. Die Angaben erfolgen nach dem Schema Breite x Höhe. Möchte man weitere Formate außer denen, die zur Auswahl stehen, muss man die Datei rollenwahl.php anpassen. Dort stehen die Option im Formularfeld "mapsize". Fragen Sie dazu ihren Administrator oder jemanden, der Zugang zu dieser Datei hat.

Aktuelle Kartenausdehnung

Hier kann die aktuelle Kartenausdehnung eingestellt werden. Die Kartenausdehnung wird in dem Format "minx miny,maxx maxy" angegeben. Die Koordinaten müssen immer in dem System angegeben sein, welches in dem Feld "Kartenprojektion (EPSG-Code)" ausgewählt wurde.

Kartenprojektion (EPSG-Code)

Hier kann man schließlich ein Koordinatensystem auswählen, welches für die Anzeige verwendet werden soll. Diese Funktion steht seit der Version 1.6.5 zur Verfügung. Es ist jedoch zu beachten, dass sich dies erstmal nur auf die Darstellung bezieht. Bei der Digitalisierung von neuen Objekten auf einer Kartendarstellung mit einem Koordinatensystem, welches nicht dem System der Daten in der PostGIS Tabelle entspricht, kann noch zu Problemen führen. Also für die Erfassung und Änderung von Daten sollte man zunächst immer den EPSG Code wählen, der für den Layer in PostGIS festgelegt wurde. In MV dürfte das meißtens 2398 sein.

Drucken in PDF

Um in einer Stelle in PDF drucken zu können, muss der Administrator vorher einen Menüpunkt sowie einen oder mehrere zur Auswahl stehende Kartendruck-Layouts eingerichtet haben. Das Erstellen der Kartendruck-Layouts erfolgt im Kartendruck-Layouteditor (go=Druckrahmen). Jedes Kartendruck-Layout kann in beliebig vielen Stellen verwendet werden.

Der Druck erfolgt über die Druckausschnittswahl (go=Druckausschnittswahl). Hier ist zunächst der aktuelle Kartenausschnitt mit den üblichen Navigationswerkzeugen zu sehen. Über die Themenauswahl können auch hier Themen ein- oder ausgeschaltet werden. Zusätzlich stehen ein Eingabefeld zur Angabe des gewünschten Druckmaßstabes und ein Auswahlfeld zur Auswahl des gewünschten Kartendruck-Layouts zur Verfügung. Es kann auch der aktuelle Kartenmaßstab am Bildschirm als Druckmaßstab gewählt werden, dafür gibt es eine Schaltfläche Kartenmaßstab übernehmen. In der Karte kann der gewünschte Druckausschnitt gewählt werden, der in das PDF exportiert werden soll. Dafür gibt es die Schaltfläche Druckausschnitt setzen. Der Druckausschnitt wird per Klick in die Karte gesetzt. Der Klick bestimmt den Mittelpunkt des Druckausschnitts. Wiederholte Klicks verschieben den Druckausschnitt. Ist der Kartenausschnitt zu klein bzw. zu groß, muss der Druckmaßstab entsprechend angepasst werden.

Unterhalb der Karte kann ein Drehwinkel für den Druckausschnitt eingegeben werden. Außerdem können Lage und Größe des aktuell gesetzten Druckausschnitts (nicht aber die gerade angeschalteten Themen oder das gerade gewählte Kartendruck-Layout) gespeichert werden.

Hat der Druckausschnitt das richtige Kartendruck-Layout, die gewünschte Position und die gewünschte Größe, kann das PDF durch Klick auf Drucken direkt erzeugt und anschließend gespeichert oder ausgedruckt werden.

Beim Klick auf Vorschau gelangt man zu einer Druck-Voransicht, die das spätere PDF-Dokument, d.h. den Kartenausschnitt plus das gewählte Kartendruck-Layout, am Bildschirm anzeigt. Hier kann man beispielsweise überprüfen, ob alle benötigten Kartenelemente zu erkennen sind. Sind im Kartendruck-Layouteditor für dieses Kartendruck-Layout variable Freitexte erlaubt werden, kann der Bearbeiter einen oder mehrere sog. Freitexte beliebig positionieren, beliebig mit Text füllen und beliebig in Größe und Form ändern.

Ist die Druckvorschau nicht zufriedenstellend, gelangt man durch Klick auf 'zurück' wieder zur Druckausschnittswahl und kann die Einstellungen anpassen. Ist die Vorschau in Ordnung, kann man durch Klick auf Drucken das PDF erzeugen.

Es ist möglich, den Druck zu kacheln, das heißt, Druckausschnitte exakt neben- bzw. untereinander zu positionieren. Hat man einen PDF-Ausdruck via Drucken erstellt, kehrt man über zurück zum Druckausschnitt zur Auswahl der Druckausschnitts zurück. Der Druckausschnitt ist in der Karte noch positioniert. Wenn man mit dem Cursor über eine der 4 Kanten des Druckausschnitts fährt, erscheint ein kleines Dreieck. Ein Klick auf dieses Dreieck verschiebt den Druckausschnitt so, dass der neue Ausschnitt an dieser Kante exakt neben bzw. unter oder über dem vorherigen Ausschnitt positioniert wird.

Metadaten

Eingabe

Zur Erfassung von Metadaten wird zunächst der entsprechende Menüpunkt ausgewählt. Zur Einbindung des Menüpunktes siehe Menüverwaltung. Der Linke auf diesen Anwendungsfall lautet index.php?go=Metadateneingabe.

Das Eingabeformular für die Metadaten enthält gemäß ISO 19119 für Servicemetadaten einige Pflichtangaben und einige optionale. Die Pflichtangaben sind durch * gekennzeichnet, siehe Bild:Metadateneingabe.png. Je nachdem was man beschreiben möchte wählt man die Art der Metadaten aus. Die Id des Metadatensatzes wird vorgegeben. Vorgegeben werden auch die Auswahlmöglichkeiten für die Kategorie und Schlagwörter. Wenn die Listen angepasst werden sollen, muss dies im Snippets "metadateneingabeformular.php" bzw. in der Tabelle md_keywords durch einen Administrator erfolgen.

Um das Umschließende Rechteck zu ermitteln kann man in der Karte ein Rechteckaufziehen und den Button "Box aus Karte" wählen. Die Koordinaten werden in die Textfelder übernommen.

Einige Metadaten gelten nur für Services, Datensätze oder Applikationen und müssen nur bei Bedarf ausgefüllt werden.

Nach dem Senden des Metadatendokumentes wird geprüft ob alle Pflichtfelder ausgefüllt wurden. Wenn die Speicherung erfolgte, werden die Angaben für eine nächste Eingabe übernommen. Das entsprechende Auswahlfeld neben dem Zurücksenden Button sorgt dafür, dass nach dem Senden mehr Infos zu Metadaten angezeigt werden, z.B. die Bezeichnungen der Metadatenelemente im Standard oder sonsotige Hinweise.

Alle eingegebenen Daten werden in die Tabelle md_metadata gespeichert. Die Zuordnung zwischen den Schlagwörtern und dem Metadatendokument erfolgt über die Tabelle md_keywords2metadata.

Suche

Nach Metadaten kann entweder über ein spezielles Suchfenster gesucht werden oder über die normale Sachdatenabfrage im Kartenfenster. Bei letzerer Variante muss jedoch ein Layer für die Metadatenboxanzeige angelegt und der Stelle zugewiesen worden sein, siehe Abschnitt Layer.

Für das Suchen über das Suchfenster nutzt man den Menüpunkt "Suchen" Unterpunkt "Metadaten". Wenn dieser noch nicht eingerichtet ist, muss das vorher durch einen Administrator erfolgen. Der Link auf den Anwendungsfall lautet:index.php?go=Metadaten_Auswaehlen, siehe Abschnitt: Menü. Das Suchformular ist einfach gehalten. Es kann nach dem Was, Wo, Wer und Wann gesucht werden. Die Suche wird in den entsprechenden Metadatenelementen räumlich, thematisch und/oder zeitlich vorgenommen. Zur räumlichen Auswahl kann auch hier wieder ein Rechteck in der Karte gezeichnet werden und mit "Box aus Karte" in die Formularfelder übernommen werden, siehe Bild:Metadatensuche.png.

Das Suchergebnis besteht aus einer Trefferliste mit verkürzten Informationen zu dem Metadatensatz, siehe Bild:Metadatenergebnis.png. Ein Link führt auf die Detailanzeige, siehe Bild:Metadatendetailansicht.png und ein Link zur Bearbeitung des Datensatzes, wie im Eingabeformular.

Die Anzeige der Metadaten erfolgt nach der Suche über das spezielle Suchformular oder nach der Sachdatenabfrage über die Karte. Da wie bei allen Layern das Template für die Sachdatenanzeige frei gewählt werden kann, ist es möglich, dass ein Administrator auch ein anderes Layout für die Anzeige der Metadaten wählt, als standardmäßig vom GLE erzeugt wird. Bei Metadaten ist es z.B. genau das selbe Template zu verwenden, wie es auch für die Trefferlistenanzeige verwendet wird. Dazu ist das Template "Metadaten.php" in den stellenbezogenen Layereigenschaften einzutragen.

Layer aus Mapdatei laden

Über die Funktion "Layer aus Mapdatei laden" (go-Variable: layerfrommapfile) hat man die Möglichkeit Mapdateien einzulesen und die darin enthaltenen Layer-, Klassen-, Styles- und Labels in die MySQL-DB zu speichern.

Man kann entweder eine einzelne Mapdatei hochladen oder eine gezippte Verzeichnisstruktur, in der die Fonts, Symbole usw. enthalten sind. Läd man eine Zip-Datei hoch, stehen alle in diesem Archiv vorhandenen Mapdateien für den Einlesevorgang zur Auswahl. Beim Einlesen der Mapdateien ist darauf zu achten, dass die Pfadangaben für das Fontset und das Symbolset in der Mapdatei stimmen. Ansonsten funktioniert der Einlesevorgang nämlich nicht.

Nachdem die ausgewählte Mapdatei eingelesen wurde, werden alle in ihr enthaltenen Layer nach Gruppen geordnet untereinander aufgelistet. Die Layer, die in der Mapdatei keiner Gruppe zugeordnet wurden, werden der Gruppe "Gruppe1" zugeordnet. Hinter jedem Layer gibt es eine Checkbox, über die man festlegen kann, ob der jeweilige Layer in die Datenbank gespeichert werden soll. Zusätzlich kann hier noch ausgewählt werden, ob das Font- und Symbolset um die zusätzlichen Fonts bzw. Symbole erweitert werden soll. Bei Auswahl der Fontseterweiterung werden außerdem noch die neuen Fonts in den Fontordner kopiert. Hierbei ist jedoch darauf zu achten, dass keine vorhandenen Symbole oder Fonts überschrieben werden. Daher empfiehlt es sich, diese beiden Anpassungen von Hand zu machen.

Nach Auswahl der gewünschten Layer klickt man auf "Layer hinzufügen" und die entsprechenden Layer werden in die Datenbank geschrieben. Nach erfolgter Speicherung der Layer wird ausgegeben, wieviele Gruppen, Layer, Klassen, Styles und Labels in die Datenbank eingefügt wurden.

ALB-Änderung

Zum Einlesen von ALB Daten aus WLDGE-Dateien gibt es verschiedene Möglichkeiten. Zum einen können eine oder mehrere Grunddatenbestände und zum anderen Fortführungsdateien eingelesen werden.(siehe Abbildung)
Der Anwendungsfall für die ALB-Änderungen nennt sich: ALB_Aenderung
Wer also die ALB-Änderung in einen Menüpunkt einbinden möchte (Wenn noch nicht geschehen) sollte in der Tabelle u_menues in der Spalte links "index.php?go=ALB_Aenderung" eintragen.
Nach Auswahl des Menüpunktes erscheint ein Formular zum Auswählen der WLDGE-Datei. Wenn die Datei schon auf dem Server liegt, geben Sie den Pfad und den Dateinamen im ersten Formularfeld an, ansonsten wählen Sie eine Datei von Ihrem lokalen Rechner zum hochladen aus.
Dann wählen Sie über den Radiobutton aus ob es sich um eine Fortführung oder einen Grundbestand handelt aus.
Wählen Sie in welche Datenbank die Daten sollen. Empfohlen wird PostgreSQL, weil da auch die ALK-Daten sind und die ALB-Daten sonst nicht mit ALK genutzt werden können. Nur wer seine ALK-Datein in MySQL hat und die ALB-Daten auch darein haben möchte sollte MySQL wählen. Die Unterstützung für das Speichern unter MySQL läuft aber aus. Mittelfristig sollen alle GIS-Daten, wozu auch die ALB-Daten zählen in die PostgreSQL Datenbank. Der Knopf MySQL wird also bald verschwinden.

Wenn nicht direkt in die Datenbank geschrieben werden soll, sondern nur die Logdatei angelegt werden soll mit den SQL-Statements zum Einlesen der ALB Daten, kann als nächstes die Checkbox ausgewählt werden.
Die Checkbox "Datenbank vorher leeren" darf nur ausgewählt werden, wenn die allererste Grundbestandsdatei eingelesen wird. Wenn mehrere Grundbestandsdateien eingelesen werden nur bei der ersten diesen Haken setzen.
"Ohne Transaktion" sollte nur gewählt werden, wenn es sich um sehr große Dateien handelt, man das Einlesen testen möchte oder das Schreiben in die Datenbank sowieso unterdrückt hat. Die SQL-Befehle für den Begin der Transaktion wird dann auch nicht in die Logfiles geschrieben. Die Ausführung der SQL in einer Transaktion beim späteren Einlesen obliegt dann also dem Nutzer.
Die Prüfung der WLDGE Kopfzeilen kann unterdrückt werden, wenn Fortführungen ohne Kopfzeilen oder mit falschen Datumsangaben eingelesen werden sollen. Geprüft wird:

- Ob die Datei mit der richtigen Dateikennung beginnt (1).
- Ob bei einer Fortführung die Fortführungsart S enthalten ist.
- Ob die Druckauftragsart 11 (Ausgabe mit Entschlüsselung) ist.
- Ob die Dateikennungen 1.E.20 und 1.E.30 bei Fortführungen existieren.
- Ob die Kennung der Erstabgabe L ist.
- Ob das Datum der Grundausstattung ein gültiges ist.
- Ob das Datum der Grundausstattung in der WLDGE Datei in der Datenbank vorkommt
- Ob die Datumsangaben für den Zeitraum einer Fortführung gültig sind.
- Ob das Anfangsdatum der Fortführung mit dem Enddatum der letzten Fortführung bereinstimmt.

Letztlich kann noch gewählt werden ob die SQL-Statements in eine Logdatei geschrieben werden sollen oder nicht. Die Logdateien werden in den Pfad geschrieben, der in der Konstante:LOGPATH aus der Datei config.php angegeben ist.
Die Namen der Logdateien der Grundbestandsdateien setzen sich wie folgt zusammen:

WLDGE_Dump_<Datenbank>_<Datumsstempel>.sql

Die Namen der Fortführungen:

WLDGE_update_Dump_<Datenbank>_<Datumsstempel>.sql

Nach dem Anklicken des Buttons Abschicken wird die Datei geprüft, eingelesen und die entsprechenden Tabellen in der Datenbank aktualisiert.

ALK-Aktualisieren

Mit Shapefiles

Menüpunkt Fortführung Unterpunkt ALK_Änderung ausführen.
Die Shape-Dateien ALK_Flurstuecke, ALK_Gebaeude, ALK_Nutzungen und ALK_Ausgest im Verzeichnis data/ werden eingelesen und die dazugehörigen Tabellen in der Datenbank aktualisiert.
Die Fortführung erfolgt im Moment nur komplett über den gesamten Datenbestand im Shape-Format.

Mit EDBS-Dateien (BZSN)

Die Postgres-Datenbank mit PostGIS-Unterstützung muss vorhanden sein. Der Konverter EDBS2WKT muss auf einem Windows-Rechner installiert sein und eine ODBC-Verbindung zum Datenbankserver existieren. Die ALK-Tabellen müssen mit EDBS2WKT angelegt werden.
Dann kann das Einlesen der EDBS-Dateien über EDBS2WKT erfolgen.
Es kann sein, dass die Dateien noch vom UNIX Textformat in PC-Format geändert werden müssen. Dazu kann das Tool UnixToWin verwendet werden. Zu finden unter: http://62.153.231.87/alb/daten/UnixToWin.exe

WMS-Konformität

Kvwmap kann auf zwei Arten als WMS konformer MapServer eingesetzt werden.

1. über CGI Dazu produziert kvwmap „Mapfiles“ mit entsprechenden Metadaten (siehe MapServer WMS Server HOWTO).

Den Speicherort für Mapdateien stellen Sie über die Konstante WMS_MAPFILE_Path ein.

Wenn Sie eine WMS konforme Map-Datei erstellen wollen, klicken auf den Menüpunkt WMS-Export und geben dort den Namen der Datei (z.B. wms_test.map) an. In dieser Datei wird dann der zuletzt angezeigte Zustand der kvwmap Kartenansicht abgelegt und ist für die Nutzung in einem Web Map Service nutzbar. Die Map-Datei enthält alle Metadaten, die für den getCapabilities Request erforderlich sind.

Die Map-Datei sollte in einem WWW-Verzeichnis stehen, z.B. /meinwwwroot/WMS. Dieses Verzeichnis muss wwwrun gehören.

Auf diese Map-Datei kann dann wie folgt zugegriffen werden.

getCapabilities-Request

http...://www.myserver.de/cgi-bin/mapserv?map=/mywwwroot/WMS/wms_test.map
&request=getcapabilities&service=wms&version=1.1.0

In dem vom MapServer geliefertem XML-Dokument sind die verfügbaren Layer aufgelistet. Diese können dann im getMap-Request zur Ansicht gebracht werden.

getMap-Request

http...://www.myserver.de/cgi-bin/mapserv?map=/mywwwroot/WMS/wms_test.map&service=wms
&request=getmap&version=1.1.0&layers=Landkreis,Gemeinde,Gemarkung,LSG& Height=500&width=500

2. über kvwmap selbst

Dazu wird direkt kvwmap aufgerufen mit dem Anwendungsfall go=OWS. Genau wie beim normalen Aufruf der Anwendung muß sich der Nutzer auch hier beim ersten Mal authentifizieren. Dann stehen alle Layer des Nutzers in der aktuellen (letzten) Stelle als WMS zur Verfügung.

Hinter dem Parameter go können dann alle WMS konformen Anfrageparameter angehängt werden, für alle Requestarten. Um auch auf die Layer einer anderen Stelle des Nutzers zugreifen zu können, läßt sich der Parameter Stelle_ID angeben.

Im Beispiel ist ein getCapabilities Aufruf dargestellt.

http...://www.server.de/kvwmap/index.php?go=OWS&request=getCapabilities&service=wms&version=1.1.0&Stelle_ID=1

Existiert eine Stelle nicht oder jemand versucht auf eine falsche Stelle zuzugreifen, für die keine Berechtigung vorliegt wird folgende Exception zurückgeliefert:

ESRI-Shape Import

Der Import von Shape Dateien in die PostGIS Datenbank wird mit dem Anwendungsfall: go=SHP_Import gestartet.

Die Einzulesenden Shape-Dateien werden als ZIP-Datei gepackt und gemeinsam, zunächst temporär auf den Server hochgeladen. Anschließend können Einstellungen für den Import vorgenommen werden.

Dabei kann gewählt werden, ob die Daten in eine neue Tabelle eingefügt werden, eine vorhandene Tabelle überschrieben werden soll oder die Daten an eine vorhandene Tabelle angehängt werden sollen. Für das Anlegen neuer Tabellen kann noch angegeben werden, welches Koordinatensystem zugeordnet (EPSG-Code) und ob ein GIST Index erzeugt werden soll. Die Zuordnung zwischen den Attributen in der dbf-Tabelle und den Tabellen der Datenbank kann folgendermaßen erfolgen. Entfernen des Häkchens aus der Checkbox bedeutet, dass das Attribut nicht übernommen wird. Ansonsten kann neben dem jeweiligen Attribut aus der dbf Tabelle der Name der Spalte in der PostGIS Tabelle angegeben werden. Außerdem kann der Datentyp geändert werden. Mit dem Radiobutton hinter jedem Attribut läßt sich festlegen, ob dieses Attribut der Primärschlüssel sein soll. Alternativ dazu kann auch ein zusätzlicher Primärschlüssel 'gid' angelegt werden. Zu beachten ist, dass die Geometrien der eingelesenen Daten gleich sein müssen und auch bei Fortführungen vom gleichen Typ sein müssen.

Weitere Hilfe

Unter der Rubrik Foren in der Menüleiste links finden Sie weitere Hilfe. Unter anderem befindet sich dort ein Bug-Report, eine Liste mit HowTo und eine allgemeine Fragen-Liste zu kvwmap.

Viele Einträge sind von Nutzern selber gemacht worden. Scheuen Sie sich also nicht hier im Wiki auch zur Dokumentation von kvwmap beizutragen.

Admin-Dokumentation

Inhaltsverzeichnis

Übersicht

Hintergründe für die Entwicklung

Funktionalität im Client

Anzeige

Navigation

Legendenfunktionen

Abfragen

Suche

Messen

Redlining

Der Generische Layereditor GLE

Die Layerattribut-Rechteverwaltung des generischen Layereditors

Bearbeitung von Sachdaten

Formularelementtypen und Formularelementfestlegungen

Text

Textfeld

Auswahlfeld

SubformPK

SubformFK

SubformEmbeddedPK

Time

Dokument

Link

dynamischer Link

MailTo

User

UserID

Stelle

Fläche

Länge

Checkbox

Erläuterungen zu Attributen

Gruppierung von Attributen

Bearbeitung von Geometrien - Geometrie-Editor

Layer-Suche

Sachdaten-Druck

Style- und Labeleditor

Import/Export-Funktionen

Shape-Export

Shape-Import

Kartenausschnitt speichern/laden

Drucken

Weitere Funktionalitäten

Funktionen auf dem Server

Fachschalen

Änderung der Eigentümeradressen

Bauleitplanungsänderung

Notizen

Kataster

Nachweisverwaltung

Bodenrichtwerterfassung

Flächenversiegelung

Aufbau des PHP-Skript

kvwmap mobil

Überblick

Voraussetzungen für die GPS-gestützte Erfassung

Voraussetzungen für die Datenübertragung

Netzwerk, Firewall

Datenbankkonfiguration

config.php

Layer und Tabellen

Aufspielen von Primärdaten auf den mobilen Client

Datenerfassung mit dem mobilen Client

Synchronisation der erfassten Daten mit dem Server

Installation

Voraussetzungen

Serverseite

Clientseite

UMN-MapServer

PostgreSQL mit PostGIS Erweiterung

PostgreSQL

PROJ

GEOS

PostGIS

MySQL

Schritte zur Installation von kvwmap

Verzeichnisse

config.php