Plugins

ALKIS

Beschreibung des Plugins ALKIS

Bauleitplanung

Bebauungsplandaten

Automatisierte Flächenübernahme aus den ROK-Geometrien

Mit der Schaltfläche "Flächen aus ROK holen" werden die Werte für die Flächen aus den Geometrien der ROK-Tabellen entnommen und für alle zugeordneten Teilflächen eingetragen.

Konzeption

Das Konzept für die Umsetzung dieser Funktionalität basiert auf der Möglichkeit die Gebiete und Sondergebiete auf Bauleitplanungsseite über die ROK-Nummer eindeutig bestimmten Datensätzen auf ROK-Seite zuordnen zu können. Für jedes Gebiet/Sondergebiet kann dadurch automatisiert eine Datenbankabfrage erstellt werden, die die entsprechenden ROK-Datensätze selektiert, die Geometrien zusammenfasst und die Gesamtfläche berechnet. Diese Fläche kann dann im Gebiet/Sondergebiet aktualisiert werden. Ein Gebiet bzw. Sondergebiet ist durch 3 Parameter definiert:

1. ROK-Nummer

2. Gebietstyp

3. Konkretisierung (optional)

Diese 3 Parameter sind in der Bauleitplanung und im ROK in unterschiedlichen Datenmodellen wieder zu finden. Auf Bauleitplanungsseite gibt es 3 Tabellen (b_plan_stammdaten, b_plan_gebiete und b_plan_sondergebiete) in denen die Stammdaten des Plans und die jedem Plan zugeordneten Gebiete und Sondergebiete gespeichert sind. Die ROK-Nummer ist in den Stammdaten gespeichert. Der Gebietstyp ist in den Tabellen b_plan_gebiete und b_plan_sondergebiete über einen Schlüssel in der Spalte gebietstyp gespeichert. Außerdem kann in der Spalte konkretisierung der Schlüssel für eine Konkretisierung angegeben sein. Auf ROK-Seite gibt es 85 Tabellen, in denen die verschiedenen Flächen gespeichert sind. Jede Tabelle entspricht einem Gebietstyp (z.B. Wohngebiete, Verkehrsflächen, Grünflächen). In jeder Tabelle ist die ROK-Nummer gespeichert und außerdem kann eine Konkretisierung in textlicher Form angegeben sein. Neben den unterschiedlichen Datenmodellen können auch die Bezeichnungen für die Gebietstypen und Konkretisierungen verschieden sein. Außerdem können verschiedene Gebietstypen in der Bauleitplanung demselben Typ im ROK entsprechen und eine Konkretisierung in der Bauleitplanung mehreren Konkretisierungen im ROK. Beispiel:

	Bauleitplanung	ROK
Gebietstyp	Verkehrsfläche	verkehrsflaechen
Konkretisierung	Luftverkehrsfläche	Flugplatz und Flughafen - Rechtskraft Flugplatz und Flughafen - Planung Hubschrauberlandeplatz - Rechtskraft Hubschrauberlandeplatz - Planung Sonderlandeplatz - Rechtskraft Sonderlandeplatz - Planung

Deshalb ist es notwendig für die Gebietstypen und Konkretisierungen 2 Zuordnungstabellen Bauleitplanung – ROK zu erstellen, um für jedes Gebiet/Sondergebiet aus der Bauleitplanung die entsprechenden Objekte im ROK zu finden. Mit Hilfe der beiden Zuordnungstabellen ist es dann möglich, aus den Daten der Bauleitplanung die zugehörige ROK-Tabelle über den Gebietstyp auszuwählen und daraus die entsprechenden Datensätze über die ROK-Nummer und die Konkretisierungen zu selektieren. Die Geometrien der Datensätze können dann vereinigt und die Gesamtfläche berechnet werden.

Umsetzung

Beim Klick auf diese Schaltfläche wird zunächst im Hintergrund abgefragt, welche Gebiete und Sondergebiete es zu dieser Plan-ID gibt. Zu jedem dieser Gebiete wird nach dem oben beschriebenen Prinzip über die ROK-Nummer, den Gebietstyp und die Konkretisierung eine Abfrage generiert, welche die Gesamtfläche der entsprechenden ROK-Geometrien aus dem ROK-Schema ermittelt. Wenn damit eine Fläche bestimmt werden konnte, wird das Gebiet mit diesem Wert aktualisiert. Ansonsten bleibt das Gebiet unverändert. Anschließend wird das Formular mit dem aktuellen Plan neu geladen, so dass die aktualisierten Flächenangaben bei den Gebieten und Sondergebieten zu sehen sind.

Flächennutzungsplandaten

Erfassung und Bearbeitung

Über den Menüpunkt "neuer Datensatz->F-Plan" gelangt man in das Formular zur Erfassung eines neuen Flächennutzungsdatensatzes. Das Formular entspricht in vielen Punkten dem der Bebauungsplandaten. Hier kann zunächst die Gemeinde ausgewählt werden, woraufhin alle weiteren raumbezogenen Daten automatisch gesetzt werden. Unter Plandaten können die Stammdaten des FNP-Datensatzes erfasst werden. Darunter befinden sich 2 Unterformulare zur Erfassung von Gebieten und Sondergebieten. Diese Gebiete werden dem FNP-Datensatz zugeordnet und können erst erfasst werden, wenn der FNP-Datensatz gespeichert wurde. Rechts befinden Felder um den Zeitbezug zu erfassen und darunter 3 Bemerkungsfelder um Maßgaben, Hinweise und allgemeine Bemerkungen einzutragen.

Wenn ein neu erfasster Datensatz gespeichert wird oder ein bestehender bearbeitet wird, lassen sich dem Datensatz Gebiete und Sondergebiete zuordnen. Um ein neues Gebiet oder Sondergebiet zu erfassen, klickt man auf des kleine "+" rechts unten. Es öffnet sich ein Unterformular in dem man den Gebietstyp auswählen und die Fläche und die Kapazitäten eintragen kann.

Neben der Neuerfassung eines FNP-Datensatzes besteht auch die Möglichkeit, einen bestehenden Datensatz zu kopieren um bspw. eine Änderung zu diesem Plan zu erfassen. Dazu klickt man auf die Schaltfläche "Datensatz kopieren", woraufhin ein neuer Datensatz mit den gleichen Stammdaten und gleichen Gebieten und Sondergebieten angelegt und sofort angezeigt wird. Man kann nun die Änderungen an dem kopierten Datensatz vornehmen.

Bodenrichtwerte

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.
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 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.

Wichtig ist außerdem, dass im BORIS-Layer die beiden Attribute gemeinde und gemarkung im Attribut-Editor als Auswahlfelder mit diesen SQL-Statements definiert werden müssen:

gemeinde: select schluesselgesamt as value, bezeichnung as output from alkis.ax_gemeinde <required by>gemarkung</required by>

gemarkung: select land*10000+gemarkung as value, gemarkungsname as output from alkis.pp_gemarkung as g WHERE g.land*1000000+regierungsbezirk*100000+kreis*1000+gemeinde = <requires>gemeinde</requires>

Deckblätter des katasterlichen Nachweis-Archivs

Das Nachweis-Archiv des Landkreises Vorpommern-Rügen ist so organisiert, dass die Nachweise gemarkungsweise abgelegt werden. In einigen Gemarkungen, die sehr viele Fluren haben und in denen dauerhaft eine vergleichsweise hohe Vermessungstätigkeit stattfindet, werden die Nachweise flurweise abgelegt. Am Ende jedes Fortführungsjahres wird ein Übersichtsblatt für jede Gemarkung/Flur erzeugt, welches die im vergangenen Fortführungsjahr erfolgten Messungs-Übernahmen auflistet. Dabei werden pro Messung die Rissnummer, die Auftragsnummer, Gemarkung(en)/Flur(en), die betroffenen Flurstücke vor der Fortführung, die betroffenen Flurstücke nach der Fortführung, das Fortführungsdatum und die Fortführungsart benannt. Das Übersichtsblatt (das sog. "Deckblatt") ist für zukünftige Zugriffe auf das Archiv ein unverzichtbares Hilfsmittel beim Wiederfinden und Zuordnen der Messungen. Daher muss das Deckblatt sorgfältig geführt werden - ein Fall für eine datenbankgestützte Erzeugung und Verarbeitung.

Die meisten der oben genannten Informationen sind im Auftragsverwaltungsprogramm GeOrg abgelegt. Zwei Skripte lesen die Informationen zu den relevanten Aufträgen und zu den Flurstücken dieser Aufträge aus der GeOrg-Datenbank aus. Bei den Flurstücken, die in GeOrg gespeichert werden, handelt es sich um die "Flurstücke vor der Fortführung". Diese Informationen werden in zwei entsprechende Tabellen der PostgreSQL gespeichert und laufend aktualisiert.

Drei Tabellen und entsprechend drei Layer ermöglichen in kvwmap das Erstellen von Datensätzen, die letztlich jeweils eine Zeile pro Messung im Deckblatt-Drucklayout erzeugen.

Die Einträge der Datensätze in kvwmap werden von den Mitarbeitern erzeugt, die die Messungsübernahme durchführen. Sie müssen lediglich die Rissnummer, die GeOrg-Antragsnummer und die "Flurstücke nach der Fortführung" angeben. Die Rissnummer können sie sich automatisch als Vorschlag generieren lassen oder selber vergeben. Mit der Angabe der Antragsnummer werden alle weiteren noch nötigen Informationen aus den GeOrg-Tabellen geholt. Der Mitarbeiter muss also nur dafür sorgen, dass er vorab alles Wesentliche richtig in GeOrg eingetragen hat.

Datenbankseitig werden Ausnahmen abgefangen. Geht die Messung über mehrere Fluren, werden entsprechend automatisch mehrere Datensätze erzeugt. Geht die Messung sogar über mehrere Gemarkungen, kann der Bearbeiter die Rissnummer nur in der Gemarkung vergeben, in der er die Nachweise auch im Rissarchiv ablegt. In den anderen Gemarkungen wird automatisch ein Datensatz ohne Rissnummer erzeugt, der neben den oben angeführten Informationen noch den Hinweis auf diejenige Gemarkung trägt, unter der man den Nachweis im Archiv finden kann. Fehlerhafte Einträge wie doppelte Vergabe einer Rissnummer in einer Gemarkung, falsche oder doppelte Auftragsnummern oder Zuordnungen von Auftragsnummern zur falschen Gemarkung/Flur werden erkannt und die Speicherung abgelehnt.

Sobald die Messung im Rahmen der katasterlichen Übernahme archiviert wird, setzt der bearbeitende Mitarbeiter der Archivierung ein Häkchen im Datensatz des Messungsauftrags. Ab diesem Zeitpunkt ist es den Mitarbeitern in der Messungsübernahme nicht mehr möglich, Änderungen am Datensatz vorzunehmen.

Am Jahresende werden die Deckblätter (massenweise) gedruckt und den Rissordnern beigelegt. In kvwmap wird per Klick auf den entsprechenden Menüpunkt außerdem der noch aktuelle Jahrgang der Gemarkungen/Fluren in den neuen, folgenden Jahrgang kopiert. Damit beginnt das neue Fortführungsjahr.

Jagdkataster

Übersicht

Layer des Jagdkatasters

Das Jagdrecht ist geregelt in den Jagdgesetzen des Bundes und der Länder. Diese Fachschale ist entstanden aus den Erfordernissen des Jagdgesetz des Landes Mecklenburg-Vorpommern (Landesjagdgesetz - LJagdG M-V). Die Fachschale Jagdkataster hat die Abrundung der Eigenjagdbezirke zur Aufgabe und stellt eigene Oberflächen für die Erstellung und die Anzeige von Datensätzen zur Verfügung. Im Zentrum steht der Eigenjagdbezirk vor Abrundung sowie seine Zuordnungs- und Abtrennungsflächen:

• Enklave
• Exklave
• Jagdbezirksfreie Fläche
• Angliederungsfläche
• Abtrennungsfläche
• Abtrennungsfläche durch Verzicht
• Anpachtfläche

Zusätzlich ist es möglich, über die Oberfläche der Fachschale Gemeinschaftliche Jagdbe-zirke und sog. „Teiljagdbezirke“ zu erstellen.

Zur Fachschale gehören weitere Themen: Das Thema „EJB Verdachtsflächen“ visualisiert die Flächen, die möglicherweise einen Eigenjagdbezirk nach LJG M-V bilden. Das Thema „Jagdbezirke Einfärbung“ ermöglicht die farbliche Erkennung eines EJB im Verfahren und seiner zugehörigen Zuordnungs- und Abtrennungsflächen in der Karte. Für jede Zuordnungs- und Abtrennungsfläche existiert ein eigenes Thema.

Alle oben genannten Themen mit Ausnahme der Gemeinschaftlichen Jagdbezirke und die Teiljagdbezirke finden sich in der Gruppe „Jagdkataster-Abrundung“. Lesenden und schrei-benden Zugriff auf die Themen dieser Gruppe hat ausschließlich die untere Jagdbehörde.

Wenn eine Abrundung abgeschlossen ist, wird der dann geometrisch veränderte Eigenjagdbezirk in das Thema „Eigenjagdbezirke abgerundet“ kopiert. Dieses Thema findet sich in der Gruppe „Jagdkataster“. Zu dieser Gruppe gehören weitere Themen: Das Thema „befriedete Bezirke“ visualisiert Flächen, auf denen die Jagd gemäß LJG M-V ruht. Außerdem werden die Gemeinschaftlichen Jagdbezirke und die Teiljagdbezirke in dieser Gruppe angezeigt. Lesende Rechte auf die Themen dieser Gruppe können im Prinzip alle Nutzer bekommen. Schreibenden Zugriff auf die Themen dieser Gruppe hat ausschließlich die untere Jagdbehörde.

EJB Verdachtsflächen

Die Inhalte des Themas erzeugen sich script-gesteuert aus ALKIS. Das Script "lk_ejb-verdachtsflaechen.sh" addiert alle Flächen eines Eigentümers (Er muss völlig identisch sein), die zusammenhängen. Durch Pufferung werden alle Trennungen, die schmaler als 20 Meter sind, zur Fläche addiert (auch Flächen, die nicht Hindernisse für das Wild im Sinne LJG M-V sind). Zur Anzeige im Thema EJB Verdachtsflächen kommen alle so berechneten Flächen, die größer als 75 Hektar sind.

Da die Pufferung zu falschen Ergebnissen führen kann und die Flächen auch nicht daraufhin geprüft werden, ob sie ganz oder teilweise zu befriedeten Bezirken gehören, sind sie mit jagdrechtlichem Sachverstand zu beurteilen, bevor ein Eigenjagdbezirk im Verfahren angelegt wird.

Abrundung

Der EJB im Verfahren entsteht durch Digitalisierung der Fläche und Klassifizierung als „Eigenjagdbezirk“. Üblicherweise orientieren sich die Grenzen der Fläche an den Flurstücksflächen, wobei Abweichungen möglich sind. Existiert ein entsprechender Datensatz im Fachverfahren condition, bekommt der EJB im Verfahren die Nummer dieses condition-Jagdbezirks.

Beim Digitalisieren der Fläche des EJB im Verfahren erhält der Nutzer eine Information über den/die Eigentümer eines Flurstücks in Form eines Tooltipps, wenn er mit dem Cursor über ein Flurstück fährt und kurz darüber verweilt.

Besteht eine Anbindung an das Fachverfahren condition, werden einige relevante Informationen, die in condition gespeichert sind, im kvwmap-Datensatz angezeigt.

Es ist möglich, für den EJB im Verfahren einen Verzicht gemäß LJG M-V §3 auf die gesamte Fläche einzutragen.

Weitere Datensätze, die über die Oberfläche erstellt werden können, betreffen die Zuordnungs- und Abtrennungsflächen. Bei der Digitalisierung muss die Nummer des zugehörigen EJB im Verfahren eingetragen werden. In der Karte exisitert für jede Klasse der Zuordnungs- und Abtrennungsflächen ein separates Thema.

Es ist möglich, einen Verzicht gemäß LJG M-V §3 auf eine Abtrennungsfläche einzutragen.

Wegen der extrem unübersichtlichen Situation in der Karte, die es dem Betrachter oft unmöglich macht zu erkennen, welche Flächen zu welchen EJB im Verfahren gehören, gibt es ein Thema „Jagdbezirke - Einfärbung“. Das Thema verwendet 10 verschiedene Farben und färbt in der Karte den EJB im Verfahren sowie alle zugehörigen Zuordnungs- und Abtrennungsflächen mit einer (zufälligen) Farbe ein. Das passiert beim Neuanlegen eines EJB im Verfahren und danach bei jeder Änderung des EJB im Verfahren oder einer der zugehörigen Zuordnungs- und Abtrennungsflächen. Der Nutzer kann die Einfärbungsflächen abfragen und die Farbe nach Bedarf ändern (nach der nächsten geometrischen Änderung ist seine Auswahl allerdings wieder weg).

Die Recherche nach EJB im Verfahren listet, wenn die Nummer oder der Name des EJB im Verfahren eingegeben wird, sowohl den EJB im Verfahren als auch die zugehörigen Zuordnungs- und Abtrennungsflächen auf (Bei Name muss gegebenenfalls mit Platzhaltern operiert werden). Es können die enthaltenen Flurstücke einzelner oder aller Flächen abgefragt werden. Die Liste der enthaltenen Flurstücke listet zusätzlich die Flurstückseigentümer auf sowie den Flächenanteil des Flurstücks im Jagdbezirk.

Für jeden EJB im Verfahren kann ein PDF erzeugt werden, das für jeden beteiligten Eigentümer die zugehörigen Flurstücke im Verfahren auflistet. Dieses PDF dient als Anlage zu Anschreiben im Rahmen der Anhörung der Eigentümer. Der Inhalt zeilenweise pro Flurstück ist: Gemarkung, Flur, Flurstücksnummer, vollständige amtl. Fläche [m²], Anteil der amtl. Fläche im Verfahren [m²].

Wird bei einem EJB im Verfahren die „Art“ in „Abgerundeter Eigenjagdbezirk“ geändert, addiert bzw. subtrahiert kvwmap die zugehörigen Zuordnungs- und Abtrennungsflächen zum EJB im Verfahren und erzeugt daraus einen neuen Datensatz im Thema „Eigenjagdbezirk abgerundet“. Die Art im EJB im Verfahren bleibt „Eigenjagdbezirk“, der Status des EJB im Verfahren und aller zugehörigen Zuordnungs- und Abtrennungsflächen wird auf „historisch“ gesetzt. Diese Flächen tauchen nicht mehr in der Karte auf, sind aber über die Recherche weiterhin abfragbar. Ist der Status auf „historisch“ gesetzt, sind keine Änderungen am Datensatz mehr möglich.

Ist für einen EJB im Verfahren ein Verzicht gemäß LJG M-V §3 auf die gesamte Fläche eingetragen, wird dieser Status mitgenommen in den Datensatz im Thema „Eigenjagdbezirk abgerundet“ und kann dort später geändert werden.

Befriedete Bezirke

Ein befriedeter Bezirk entsteht durch Erstellung eines entsprechenden Datensatzes. Neben dem Namen der Ortslage wird der Name des zugehörigen gemeinschaftlichen Jagdbezirks gespeichert. Durch Verschneidung der Geometrie des befriedeten Bezirks mit den aktuellen Flurstücken des Liegenschaftskatasters entsteht eine Liste der vom Bezirk angeschnittenen Flurstücke. Neben dem Flurstückskennzeichen und dem Anteil der Flurstücksfläche im befriedeten Bezirk (absolut und prozentual) werden die Nutzungsarten des Flurstücks aufgelistet, die vom Bezirk berührt werden. Die Nutzungsartenschlüssel werden aufgeführt sowie die Einordnung der Nutzungsart in den Katalog gemäß §5 LJG M-V.

Das Anlegen eines befriedeten Bezirks ist somit ein iterativer Prozess, bei dem zunächst ein grobes Polygon um eine Verdachtsfläche gelegt wird, die dann mit Hilfe der Informationen aus dem Liegenschaftskataster und des jagdrechtlichen Sachverstands präzisiert wird.

Gemeinschaftliche Jagdbezirke und Teiljagdbezirke

Weitere Datensätze, die analog zu den Zuordnungs- und Abtrennungsflächen über die Oberfläche erstellt werden können, betreffen die gemeinschaftlichen Jagdbezirke und die Teiljagdbezirke. Existiert ein entsprechender Datensatz im Fachverfahren condition, bekommt gemeinschaftliche Jagdbezirk oder der Teiljagdbezirk die Nummer dieses condition-Jagdbezirks.

Beim Digitalisieren der Fläche erhält der Nutzer analog zur Digitalisierung eines EJB im Verfahren eine Information über den/die Eigentümer eines Flurstücks in Form eines Tooltipps, wenn er mit dem Cursor über ein Flurstück fährt und kurz darüber verweilt.

Besteht eine Anbindung an das Fachverfahren condition, werden einige relevante Informationen, die in condition gespeichert sind, im kvwmap-Datensatz angezeigt.

Wird ein gemeinschaftlicher Jagdbezirk oder ein Teiljagdbezirk recherchiert, können die enthaltenen Flurstücke abgefragt werden. Die Liste der enthaltenen Flurstücke listet zusätzlich die Flurstückseigentümer auf sowie den Flächenanteil des Flurstücks im Jagdbezirk. Die Abfrage auf enthaltene Flurstücke in einem gemeinschaftlicher Jagdbezirk kann unter Umständen lange dauern.

Abgerundete Eigenjagdbezirke

Abgerundete Eigenjagdbezirke entstehen automatisch aus der Abrundung eines EJB im Verfahren.

Die untere Jagdbehörde erhält vollen schreibenden Zugriff auf dieses Thema und kann jederzeit Änderungen im Namen, im Verzichts-Status und in der Geometrie vornehmen. Außerdem können zusätzliche Informationen wie das Datum des Beschlusses und das Datum der Bekanntmachung eingetragen werden.

KoLiBRI

Mit dem Plugin kann man von kvwmap aus über die Flurstücksanzeige das Grundstücksinformationssystem KoLiBRI aufrufen und umgekehrt. Die Verknüpfung stellen Flurstückskennzeichen dar. Wer das Plugin nutzen möchte, muss es nicht nur in der config.php aktivieren, sondern auch noch die Funktion 'Kolibristart' den Stellen zuweisen, die das benutzen möchten.

von KoLiBRI nach kvwmap

Um kvwmap aus KoLiBRI heraus öffnen zu können, müssen dort in der Konfiguration folgende Einstellungen vorgenommen werden:

• GIS Typ: WebGIS
• GIS WebGIS-URL:

  https://meinServer.de/kvwmap/index.php?go=ZoomToFlst&FlurstKennz={ALKIS}

von kvwmap nach KoLiBRI

Das Starten von KoLiBRI aus dem Browser heraus in dem kvwmap angezeigt wird erfolgt über ein spezielles Protokoll, welches wir kvwkol genannt haben. Die Links in der Flurstücksdatenanzeige beginnen also nicht mit http:// sondern mit kvwkol:// Damit der Browser, bzw. der Rechner weiss was er mit dem Protokoll anfangen soll, wird dieses Protokoll in der Registry von Windows eingetragen und zwar so, dass ein Programm startet, welches die übergebenen Parameter in eine Austauschdatei schreibt. KoLiBRI ist so eingestellt, dass es in regelmäßigen in einem Verzeichnis nachsieht ob da eine solche neue Datei angekommen ist und öffnet dann mit dem oder den darin befindlichen Flurstücken die Anwendung. Zur Einrichtung der Eintragung in der Registry kann die Datei plugins/kolibri/tools/kvwkol.reg verwendet werden. Die Datei plugins/kolibri/tools/kvwkol.exe ist die Datei, die die übergebenen Flurstückskennzeichen in die Austauschdatei schreibt. Die Datei plugins/kolibri/tools/kvwkol.cs enthält den Quellcode der kvwkol.exe geschrieben in C#. Damit das funktioniert müssen folgende Einstellungen in KoLiBRI vorgenommen worden sein:

• GIS Überwachungsverzeichnis: C:\Austausch ... Das kann auch ein anderes sein. Dies wird aber vom Plugin standardmäßig vorausgesetzt.
• GIS Überwachungsdatei: vonGIS.txt ... Das kann auch ein anderen Namen haben, wird aber vom Plugin standardmäßig vorausgesetzt. Das ist die Datei in die die Datei kvwkol.exe schreibt.

Mobile (für kvmobile)

Das Plugin ermöglicht die Zusammenarbeit der App kvmobile für mobile Endgeräte mit dem WebGIS kvwmap. Es stellt Funktionen zur Abfrage und Synchronisierung der Daten, die in der App angezeigt, erfasst und verarbeitet werden können zur Verfügung.

kvmobile läuft auf Handy oder Tablet. Derzeit wird das Betriebssystem Android unterstützt. Weiterführende Informationen zur App kvmobile finden Sie hier.

Voraussetzungen

kvwmap

Plugin

Wie bei allen anderen Plugins muss das Plugin unter Administrationsfuktionen eingeschaltet sein. Das Plugin lautet:

 mobile

Der Name ist in Doppelte Anführungszeichen zu schreiben und mit Komma von den anderen Plugins zu trennen.

Stelleneinstellungen

Der Stelle, die den mobilen Layer beinhaltet, muss der Menüpunkt Daten-Export mit dem Verweis "index.php?go=Daten_Export" oder die Funktion mit go=Daten_Export zugewiesen haben, damit die Daten vom Client über die Stelle heruntergeladen werden können.

Funktionen

Es müssen folgende Funktionen in der Stelle in der die mobilen Layer sind freigeschaltet sein:

• mobile_upload_image
• mobile_download_image
• mobile_delete_images

Datenbank

Erweiterung uuid-ossp

Die Datenbank in der Tabellen sind, die von Layern in kvmobile genutzt werden müssen die Erweiterung uuid-ossp haben. Diese lässt sich als Superuser mit folgendem Befehl einrichten:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

Spalte uuid

In der Tabelle, die vom Layer in kvmobile genutzt wird, muss eine Spalte mit dem Namen uuid existieren. Das Attribut muss vom Typ uuid sein, als Primary Key gesetzt sein und als Default-Wert die Funktion uuid_generate_v4 haben, die automatisch uuid's in der Version 4 erzeugt. Diese kann mit folgendem Befehl erzeugt werden:

• uuid

ALTER TABLE schema.table ADD COLUMN uuid uuid NOT NULL DEFAULT uuid_generate_v4() PRIMARY KEY;

Spalte bilder

Zum Aufnehmen von mehreren Bildern pro Datensatz in kvmobile muss es eine Spalte bilder geben, vom Typ ""character varying []. Diese legt man an mit folgendem Befehl:

• bilder

ALTER TABLE schema.table ADD COLUMN bilder character varying[];

Spalte bilder_updated_at

• bilder_updated_at

Zur Hinterlegung eines Zeitstempels, der angibt wann das letzte Bild gemacht wurde wird die Spalte bilder_updated_at benötigt. Sie kann wie folgt angelegt werden:

ALTER TABLE schema.table ADD COLUMN bilder_updated_at timestamp without time zone;

Geometriespalte

Derzeit unterstützt die App kvmobile die Erfassung von Punkten, Linien, Polygonen und Multipolygonen. Dazu muss es eine entsprechende Geometrie im System WGS84 (EPSG:4326) geben. Eine solche Spalte kann wie folgt angelegt werden.

• point

ALTER TABLE schema.table ADD COLUMN point geometry(Point, 4326);
ALTER TABLE schema.table ADD COLUMN point geometry(LineString, 4326);
ALTER TABLE schema.table ADD COLUMN point geometry(Polygon, 4326);
ALTER TABLE schema.table ADD COLUMN point geometry(MultiPolygon, 4326);

Datumsstempel Zusätzlich zum Datum der Bilder müssen folgende Datumsstempel eingerichtet werden:

• created_at

ALTER TABLE schema.table ADD COLUMN created_at timestamp without time zone NOT NULL DEFAULT (now())::timestamp(0) without time zone;

• updated_at_server

ALTER TABLE schema.table ADD COLUMN updated_at_server timestamp without time zone;

• updated_at_client

ALTER TABLE schema.table ADD COLUMN updated_at_client timestamp without time zone;

Nutzer, Status und Version

Zur Speicherung welcher Nutzer den Datensatz bearbeitet hat, den Status der Daten und der Version der Änderung werden folgende Spalten benötigt.

• user_name

ALTER TABLE schema.table ADD COLUMN user_name text;

Zusätzlich zu der Festlegung dass es ein Attribut Names user_name geben muss gilt dass alle Attribute vom Formularelementtyp User, UserID oder Time im Client mit den Autowerten belegt werden.

• status

ALTER TABLE schema.table ADD COLUMN status integer NOT NULL DEFAULT 0;
COMMENT ON COLUMN schema.table.status IS '0 = default, 1 = created, 2 = updated, 3 = deleted';

• version Wird für die Synchronisierung verwendet und darf nicht vom Nutzer geändert werden

ALTER TABLE schema.table ADD COLUMN version integer NOT NULL DEFAULT 1;

Man kann natürlich auch alle Spalten in einem Statement anlegen durch kommasepariertes Auflisten der ADD COLUMN Ausdrücke. Spalten, die man schon hat kann man so auch einfach auskommentieren, z.B.:

 ALTER TABLE fachdaten.asp_zaun
   ADD COLUMN uuid uuid NOT NULL DEFAULT uuid_generate_v4() PRIMARY KEY,
   ADD COLUMN bilder character varying[],
   ADD COLUMN bilder_updated_at timestamp without time zone,
   ADD COLUMN polyline geometry(MultiLinestring, 4326),
   ADD COLUMN created_at timestamp without time zone NOT NULL DEFAULT (now())::timestamp(0) without time zone,
   ADD COLUMN updated_at_server timestamp without time zone,
   ADD COLUMN updated_at_client timestamp without time zone,
   ADD COLUMN user_name text,
-- ADD COLUMN status integer NOT NULL DEFAULT 0,
   ADD COLUMN version integer NOT NULL DEFAULT 1;

Pflichtspalten Tabellenspalten, die einen Wert erfordern weil sie auf NOT NULL gesetzt sind, müssen editierbar eingestellt sein. Insbesondere sollte das Feld Status editierbar sein, weil davon die Darstellung im Client abhängt. Davon ausgenommen sind die auf dem Client automatisch mit Werten versehenden Attribute:

• uuid, bilder_updated_at, updated_at_client, user_name, version

Aliasnamen Damit die Attribute gut lesbar in der App angezeigt werden können ist es zu empfehlen für alle Attribute Aliasnamen anzugeben.

Layereinstellungen

Query Die Query des Layers muss die Tabellen mit Angabe der Schemanamen enthalten. Der Maintable muss den Alias ht haben und alle Attribute müssen sich auf diesen alias beziehen.

Attributrechte Alle Attribute die im SQL der Query enthalten sind müssen mindestens Leserechte haben.

Attribute

Die Attribute point, bilder und bilder_updated_at sollten am Anfang der Select-Liste der Query-Definition stehen, damit die Funktion zum Ändern der Position des Datensatzes und der Erfassung und Löschung von Bildern im Mobilen Client kvmobile in der Bearbeitungsmaske ganz oben erscheinen. Des Weiteren müssen folgende Attribute im Query des Layers vorhanden sein. Die Einstellungen im Attribut-Editor stehen in Klammern:

• created_at timestamp without time zone NOT NULL DEFAULT now() without time zone (Formularelement: Zeitstempel, Optionen: insert)
• updated_at_server timestamp without time zone (Formularelement: Zeitstempel, Optionen: update)
• updated_at_client timestamp without time zone (Formularelement: Zeitstempel, Optionen: update)
• user_name character varying (Formularelement: Nutzer)
• status integer NOT NULL DEFAULT in diesem Beispiel 0, Formularelement: Auswahlfehld Option:

SELECT
  column1 AS output, column2 AS value
FROM ( VALUES
  ('noch nicht festgelegt', 0),
  ('förderfähig', 1),
  ('nicht förderfähig', 2),
  ('vielleicht förderfähig', 3)
) AS options

wobei 0, 1, 2 und 3 Pflicht sind und die Texte frei angegeben werden können.

• version integer NOT NULL DEFAULT 1

Am besten man ordnet diese am Ende der Attributliste an und fügt sie im Attributeditor in eine Gruppe.

Bilder Das Attribut Bilder muss als Formularelementtyp Dokument und editierbar eingestellt sein. Hochgeladene Bilder werden im Dokumente-Ordner des Layers abgelegt, siehe Admin-Doku.

ID-Spalte Die Layereinstellung ID-Spalte muss auf uuid stehen

Sync - Modus

Um Layer in kvmobile laden und bearbeiten zu können muss! die Eigenschaft Sync - Modus im Layereditor eingeschaltet sein. Hat ein Layer keine Unterformulare, wird ein Hinweis angezeigt, dass die Deltas-Tabellen und Trigger angelegt wurden.

Hat der Layer hingegen Unterformulare wird der Nutzer aufgefordert auch den Sync-Modus dieser Layer umzuschalten. Über die Links gelangt er zu den Layerformularen der anderen Layer.

Wird ein Sync-Modus ausgeschaltet, wird dies kurz mit einer Meldung quittiert, dass die Deltas-Tabelle und die Trigger gelöscht sind.

Ist der Layer, dessen Sync-Modus ausgeschaltet werden soll selbst ein Sub-Layer, wird ein Hinweis angezeigt ggf. auch den Sync-Mode des übergeordneten Layer auszuschalten.

Labelitem

In kvmobile werden die Datensätze eines Layers in einer Liste dargestellt. Als Beschriftung des Listenelementes wird der Inhalt des Attributes verwendet, welches im Layer als Lableitem definiert ist. Ist kein Labelitem definiert, wird statt dessen alternativ der Text 'Datensatz ' + ID des Datensatzes als Text verwendet und im Popup wird als Bezeichnung die ID des Datensatzes angezeigt.

Dokument Ordner

Wenn in kvwmap für die Datensätze Bilder aufgenommen werden sollen, muss es im Layer unter Dokumente Ordner einen Eintrag für ein Verzeichnis geben, z.B. unter /var/www/data/upload/Bilder/. Der Pfad muss hinten ein Schrägstrich haben, damit die Daten immer in einem Unterordner landen und nicht das letzte Wort als Prefix für die Bilder interpretiert wird. Das Attribut bilder muss vom Formularelementtyp Dokument sein.

Options Wenn in den Optionen von Auswahllisten SQL-Statements definiert sind, dürfen in den Output und Value Feldern keine Ausdrücke mit doppelten Anführungszeichen sein.

Versionierung

Wie funktioniert aktuell die Versionierung von Datensätzen?

Wenn ein Layer für die Synchronisierung ausgewählt wurde, wird passend zu der in main_table festgelegten Tabelle eine deltas Tabelle angelegt, die so heißt wie die Tabelle plus _deltas. Also heißt dann z.B. die Deltas-Tabelle von haltestellen haltestellen_deltas. Jede deltas Tabelle hat folgende Struktur:

• version serial NOT NULL
• sql text
• created_at timestamp without time zone NOT NULL DEFAULT (now())::timestamp without time zone
• username character varying

Zusätzlich werden im Anwendungsfall mobile_prepare_layer_sync des Plugins mobile, in dem die Deltas Tabelle angelegt wurde, auch die Trigger zum befüllen der Deltastabelle erzeugt. Die Trigger hängen an der zu synchronisierenden Tabelle. Bei einem Insert, Update oder Delete wird jeweils das dazugehörige SQL mit einer Versionsnummer in die Deltas-Tabelle eingetragen. Die Versionsnummer ist dabei immer eins größer als die letzte in der Deltas-Tabelle. Dabei wird die folgende Anfrage verwendet.

SELECT (coalesce(max(version), 1) + 1)::integer FROM " . $layer->get('schema') . "." . $layer->get('maintable') . "_deltas

Wenn Änderungen auf dem Client gemacht werden, landen die dazugehörigen Deltas auch in der Deltas-Tabelle. Jeder Eintrag erhält dabei auch eine hochgezählte Versionsnummer. Die Versionsnummer in der Deltas-Tabelle dienen dazu, dass andere Clients ermitteln können welche Änderungen sie noch nicht kennen und bei einer Synchronisation ausführen müssen.

Die Spalte version in der Tabelle, die synchronisiert gehalten werden soll, ist für die Synchronisierung nicht relevant. Dort wird lediglich zur Dokumentation hinterlegt welche Version ein Datensatz hatte als er im Client angelegt oder geändert wurde.

Wenn sich ein Client die Daten holt um damit offline zu arbeiten, bekommt er die höchste Versionsnummer aus der Deltas-Tabelle mitgeliefert.

Führt der Client eine Synchronisation mit dem Server aus, werden folgende Schritte durchlaufen:

• Clientseitig mit Class activeLayer:
  • Abfragen der auf dem Client gespeicherten Deltas mit syncData
  • Schreiben der Deltas in eine Datei mit writeFile
  • Hochladen der Datei zum Server mit upload
• Serverseitig mit function sync in Class synchro:
  • Wenn vom Client nix geschickt wurde, prüfe ob es neue Deltas auf dem Server gibt. Wenn nicht, schicke eine result in dem push_to_version identisch ist mit last_client_version und einen entsprechenden Text.
  • Ansonsten legt eine neue Syncronisation in der Datenbank in Tabelle public.syncs an mit $client_id, $user_name und
    • $pull_from_version: Die letzte Version im Client von der an alle Änderungen vom Server geholt werden sollen
    • $pull_to_version: Die höchste Version der Deltas auf dem Server bis wohin die Änderungen vom Server geholt werden sollen
    • $push_from_version: Die Version ($pull_to_version + 1) die die erste Änderung auf dem Server bekommen wird. Also der Anfang der Änderungen auf dem Server, die durch die Synchronisation des Clients entstehen.
  • Führt alle mitgesendeten Änderungen ($client_deltas) in die Datenbank aus. Durch die Trigger werden die Änderungen auch in die Deltas-Tabelle geschrieben und dort die Version fortlaufend hochgezählt.
  • Trägt die neue letzte Version $push_to_version in die aktuelle Syncronisation ein.
  • Fragt alle Änderungen (deltas) am Layer $layer_id von $pull_from_version bis $pull_to_version ab, also alles was sich seit dem letzten Download oder der letzten Synchronisation geändert hat.
  • Fragt die Sync-Daten ab.
  • liefert die Deltas und Sync-Daten zurück an den Client
• Clientseitig mit Class activeLayer
  • Führe jedes zurückgelieferte Delta in Client-Datenbank aus, aber ohne Deltas in Client-Tabelle zu erzeugen
  • Lösche alle Deltas in Client-Datenbank
  • setze syncVersion im Client auf zurückgeliefertes push_to_version, was der höchsten Versionsnummer im Deltas-Table des Servers entspricht nachdem die Änderungen des Clients eingespielt waren.

Nachweisverwaltung

Mit der Nachweisverwaltung können alle (gültigen und ungültigen) Nachweise des Liegenschaftskatasters (Fortführungsrisse, Grenzniederschriften, Koordinatenverzeichnisse, Flurkarten...) mit Metadaten beschrieben, in einem Rissarchiv gespeichert, recherchiert, angezeigt und heruntergeladen werden. Die Beschreibung erfolgt mit Sachinformationen wie Dokumentenart, Rissnummer, Vermessungsstelle etc. Der Raumbezug wird in Form eines Multipolygons gespeichert, das auf der Grundlage der Grenzen und Gebäude des Liegenschaftskatasters festgelegt wird. Zur Nachweisverwaltung gehört auch eine Nachweisrecherche. In dieser kann attributiv über die genannten Metadaten gesucht werden. Außerdem ermöglicht die Suche über den Raumbezug das Auffinden von Nachweisen auch ohne die Angabe von Metadaten.

Die Nachweisverwaltung besitzt eine Schnittstelle zu LENRIS.

Voraussetzungen

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

• Es müssen Stellen eingerichtet sein, in der die Funktionen der Nachweisverwaltung genutzt werden können. Als praktisch erweist es sich, wenn eine Stelle für die Nachweiserfassung und eine Stelle für die Nachweisrecherche existiert.
• Es müssen Menüpunkte für die Funktionen der Nachweisverwaltung eingerichtet sein. Dazu kann man die entsprechenden SQL-Statements in der menues.sql unter plugins/nachweisverwaltung/db/mysql/data 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 den entsprechenden Stellen zugeordnet sein.
• Die Nutzer der Nachweisverwaltung müssen den entsprechenden Stellen zugeordnet 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-Vorlage unter plugins/nachweisverwaltung/db/mysql/data.
• Die zugehörigen Layer müssen angelegt sein. Dazu kann man die entsprechenden SQL-Statements in der layer.sql unter plugins/nachweisverwaltung/db/mysql/data nutzen.
• In der Adminstration müssen verschiedene Einträge in der config.php gemacht werden:
  • maximale Länge der Antragsnummer
  • maximale Länge der Rissnummer
  • maximale Länge der Blattnummer
  • maximale Anzahl der in einer Recherche zurückgelieferten Zeilen
  • das primäre Ordnungskriterium ("Rissnummer" oder "Antragsnummer", datenbankseitig mit stammnr benannt)
  • ein zusätzliches Ordnungskriterium (wenn das primäre nicht eindeutig ist)

Erfassen von Nachweisen

Optimalerweise navigiert man in der Karte an die richtige Stelle, z.B. über die Flurstückssuche. Anschließend wählt man den entsprechenden Menüpunkt an, der die Nachweiserfassung startet.

Der Scan sollte zuvor auf eine optimale Qualität bei geringstmöglicher Dateigröße hin bearbeitet worden sein (PDF oder JPG). kvwmap unternimmt keinerlei Bildbearbeitung. Da die Dateien beim Hochladen umbenannt werden, ist es nicht nötig, den Dateinamen vorab in ein bestimmtes Ordnungsschema zu bringen.

• Da eine Messung sich über mehr als eine Flur oder eine Gemarkung erstrecken kann, ist die Angabe von "Flur" und "Gemarkung" für die spätere Recherche wenig geeignet, sondern dient primär der Umbenennung der Datei und der Einordnung der Datei in die Verzeichnisstruktur des Nachweiservers. Beim Speichern des Datensatzes prüft kvwmap, ob die Mitte des Kartenausschnittes in der angegebenen Flur/Gemarkung liegen und liefert einen Warnhinweis, falls dem nicht so ist.
• Die "Antragsnummer" speichert die zugehörige Geschäftsbuchnummer.
• Die "Rissnummer" erscheint in der GUI vor der "Antragsnummer", wenn sie primäres Ordnungskriterium ist, ansonsten dahinter.
• Die "Dokumentart" sieht drei Arten von Nachweisen vor: Fortführungsriss, Grenzniederschrift, Koordinatenverzeichnis. Weitere Dokumentarten können in einer separaten Tabelle definiert werden und erscheinen als Auswahlliste.
• Die Blattnummer kann alphanumerisch sein.
• "Fortführung" meint das Jahr der Fortführung.
• Datum ist das Datum der Messung. Es sind Festlegungen notwendig, welches Datum eingetragen werden soll, wenn die Messung über mehrere Tage ging oder wenn vom Nachweis nur das Jahr bekannt ist.
• Die Einträge der "Vermessungsstelle" werden in einer separaten Tabelle definiert und erscheinen als Auswahlliste.

Der Raumbezug wird an Hand folgender Kriterien ermittelt und als Multipolygon gespeichert: Alle im Nachweis dargestellten ermittelten Grenz- bzw. Gebäudepunkte sowie alle relevanten Vermessungspunkte müssen im Multipolygon enthalten sein. Im Bereich festgestellter Grenzen kann der Umring des Multipolygons mit den Flurstücksgrenzen zusammenfallen. In digitalisierten Bereichen muss sich der Abstand des Umrings von den im Nachweis dargestellten Punkten an der Darstellungsungenauigkeit der Liegenschaftskarte in diesem Bereich orientieren. Für Fortführungsriss und zugehöriger Grenzniederschrift ergeben sich u.U. unterschiedliche Raumbezüge.

Das Datenmodell ist konform zur verbindlichen Attributliste der REGIS-UAG "DMS" für die Katasterbehörden in M-V.

Über den Button "Senden" wird der Datensatz gespeichert. Das ausgewählte Dokument wird auf den Nachweisserver hochgeladen, mit Hilfe der attributiven Angaben umbenannt und in eine Verzeichnisstruktur gespeichert. Fehlen Pflichtangaben, erfolgen Fehlermeldungen.

Recherchieren von Nachweisen

Der entsprechende Menüpunkt startet die Nachweisrecherche.

Der Nutzer kann im Kartenausschnitt über ein Suchpolygon recherchieren oder eine Suche über die gespeicherten Metainformationen starten. Wurden Recherchen bereits einer Antragsnummer zugeordnet, kann dieser Antrag hier auch wieder aufgerufen werden. Recherchiert man über Suchpolygon, ist es sinnvoll, zuvor an die richtige Stelle in der Karte zu navigieren, z.B. über die Flurstückssuche.

Die Suche nach Gemarkung und Flur erfolgt über die aktuelle Geometrie der gesuchten Gemarkung und Flur und verschneidet mit den gespeicherten Raumbezügen der Nachweise. Erst wenn das Häkchen "thematisch" gesetzt ist, wird über die gespeicherte Sachinformation Gemarkung und Flur gesucht.

Es ist möglich, entweder einen bestimmten Tag anzugeben oder eine Zeitspanne, in der das Messungsdatum der gesuchten Dokumente zeitlich eingeordnet ist.

Die Recherche über ein Suchpolygon liefert definitiv alle Dokumente, die geoemtrisch an der gesuchten Stelle verortet sind.

Das Rechercheergebnis kann an dieser Stelle bereits auf bestimmte Dokumentenarten oder nur auf gültige bzw. nur auf ungültige Nachweise eingeschränkt werden.

Mit dem Button "Senden" wird eine Trefferliste als Rechercheergebnis produziert.

Anzeigen von Nachweisen

Die Suche nach Nachweisen liefert eine Trefferliste, in der die gesuchten Nachweise zeilenweise aufgeführt werden. Im Kopf werden die verwendeten Suchkriterien aufgeführt und die Anzahl der Treffer benannt.

Die Treffer können durch Klicks auf die Spaltennamen sortiert werden. Über der Trefferliste erscheint eine Liste der verwendeten Srtierungen. Das jeweils letzte genannte Attribut kann auf- oder absteigend sortiert werden. Attribute können per Klick aus der Liste der verwendeten Sortierungen entfernt werden. Wird eine Sortierung verwendet, erscheinen die Zeilen nach dem ersten Sortierkriterium unterschiedlich eingefärbt.

Mit dem Auswahl-Feld "markieren" oder "einblenden" unter dem Rechercheergebnis können die Treffer mit bestimmten Dokumentenarten markiert oder eingeblendet/ausgeblendet werden. Alle markierten Treffer können entweder zu einer Vorbereitungsnummer hinzugefügt oder aus der vorhandenen Trefferliste einer Vorbereitungsnummer entfernt werden. Die Vorbereitungsnummer muss zuvor ausgewählt werden.

Hat der Nutzer entsprechende Rechte, kann er aus der Trefferliste heraus einzelne Nachweise bearbeiten oder löschen. Hat er einen oder mehrere Treffer markiert, kann er diese als Vorlage für die Erfassung eines neuen Nachweises verwenden.

Geht der Nutzer mit dem Cursor auf das "doc"-Symbol am Ende einer Zeile in der Trefferliste, dann wird ihm ein Vorschaubild des Nachweises angezeigt.

Portal (für kvportal)

Für die Darstellung von besonderen Inhalten mit vereinfachten Anzeige- und Abfragefunktionen wurde die Anwendung kvportal entwickelt. Es handelt sich um eine smart mapping Anwendung auf Basis von HTML, CSS und JavaScript.

Mit dem Plugin Portal kann in einer Stelle eine Layerdefinitionsdatei (layerdef.json) exportiert werden. Diese dient der Konfiguration des Geoportals kvportal und legt fest welche Layer in welchen Gruppen mit welchen Metadaten verfügbar sein sollen und welche Ausdehnung das Portal haben soll.

Das Kartenportal kvportal [1] ist eine OpenSource Application auf Basis von Leaflet [2].

kvportal holt sich Vektordaten über die Datenexport-Funktion von kvwmap ab oder lädt externe Daten, z.B. aus Diensten.

Build

 git clone https://github.com/rtrier/kvportal/
 cd kvportal
 npm install
 npm run build

Wenn der build durchläuft stehen die für die Installation oder Update benötigten Dateien im Unterverzeichnis dist zur Verfügung.

Installation

Zur erstmaligen Installation auf dem Server ein Web-Verzeichnis anlegen auf dem ein Alias liegt.

 mkdir portal

Anschließend den Inhalt des gebauten dist-Verzeichnisses in das angelegte Web-Verzeichnis kopieren.

Update

Zum Update werden nur die Dateien map.js, map.css und das Verzeichnis img aus dem dist-Verzeichnis in das Web-Verzeichnis kopiert. Die anderen Dateien im Web-Verzeichnis können individuell je nach Inhalt der Webseite und layerdef.json angepasst werden.

Konfiguration

Die Konstante LAYERDEF_EXPORT_FILE in der Gruppe Plugin/portal enthält den Pfad und Namen der Datei in die die JSON-Datei geschrieben werden soll, die kvportal nutzt.

Ist der Wert gesetzt, existiert die Datei aber noch nicht auf dem Server legt kvwmap diese Datei wenn schreibrechte an der Stelle sind an, ansonsten wird die Datei überschrieben.

Ist der Wert der Konstante leer, wird die Ausgabe im Browser ausgegeben und kann dann von Hand in eine Konfigurationsdatei von kvportal kopiert werden. Diese Option ist sinnvoll, wenn z.B. die Anwendung auf einem anderem Server liegt als kvwmap.

Icons

Im Portal stehen vor den Layergruppen Bilder. Die für das Portal verwendeten Bilder können in kvwmap im Layergruppen Editor unter Icon eingetragen werden.

Verwendung der Quellenangaben

Im Portal werden über die i-Button in der Kartenauswahl und unter meine Kartenauswahl Metadaten zum jeweiligen Layer angezeigt. Über den Copy-Right-Button werden die Copy-Right-Information aller gerade eingeschalteten Layer und Hintergrundlayer angezeigt.

Im folgenden wird beschrieben wie sich die Angaben zusammensetzen und wo diese angepasst werden können. Es ist zu beachten, dass sich die Änderungen von Metadaten und Datasources auch auf die Anzeige im WebGIS kvwmap auswirken, siehe Admin-Doku.

Copy-Rights

Für die Baselayer wird eine „attribution“ geschrieben. Die ergibt sich

• aus der Beschreibung der zum Layer zugeordneten Datasource falls vorhanden, sonst
• aus dem Namen der zum Layer zugeordneten Datasource falls vorhanden, sonst
• die Kurzbeschreibung des Layers

Sind mehr als eine Datasource zugeordnet werden die Angaben Kommasepariert zu einem Text zusammengefasst. Die attribution ist das was angezeigt wird wenn man auf den Copy-Right-Button klickt. Die Beschreibung und der Name der Datasources können über den Layereditor und den Stift hinter Quellenangaben geändert werden, oder direkt über den Case go=datasources_anzeigen&selected_layer_id=<Die ID des Layers>&csrf_token=<Der aktuelle CSRF-Token>. Die Kurzbeschreibung des Layers wird im gleichnamigen Feld des Layereditors angepasst.

Für die Themenlayer wird die attribution ausschließlich aus dem Layerattribut dataowner_name gesetzt. Das Attribut kann im Layereditor im Feld Ansprechpartner geändert werden.

Layermetadaten

Nur zu den Themenkarten werden Layermetadaten angezeigt. Zu den Baselayern nur die Copy-Right-Informationen. Die Metadaten setzen sich wie folgt zusammen und werden durch folgende Felder im Layereditor definiert.

Im Portal	In Layer/Datasource Editor	Attribut in kvwmapdb	Feld in layerdef.json
Bezeichnung	Kurzbeschreibung	layer.kurzbeschreibung	abstract
Quelle	Beschreibung in Datasources	datasources.beschreibung*	contactOrganisation
Ansprechpartner	Ansprechpartner	layer.dataowner_name	contactPersonName
E-Mail	E-Mail	layer.dataowner_email	contactEMail
Telefon	Telefon	layer.dataowner_tel	contactPhon
Aktualität	Aktualität	layer.uptodateness	actuality
Aktualisierungszyklus	Aktualisierungszyklus	layer.updatecycle	actualityCircle

• ) Wenn keine datasource.beschreibung vorhanden ist wird statt dessen der datasource.name verwendet. Wenn der auch nicht vorhanden ist wird layer.kurzbeschreibung verwendet. Wenn es mehrere datasources zum Layer gibt werden die Angaben kommasepariert ausgegeben.

Layerdef exportieren

Ist das Plugin eingestellt erscheint unter der Auflistung der Layer der Stelle im Menü Stellenverwaltung > Stellen anzeigen > Layer ein Button mit der Bezeichnung "Layerdef" Ein klick auf den Button schreibt die Layerdefinitionsdatei oder gibt den Inhalt im Browser aus.

ProBAUG

Fachschale zum Suchen und Anzeigen von Bauakten, die zuvor über Views aus der Software ProBAUG in die kvwmap Datenbank importiert wurden.

Suche

Ergebnisanzeige

Bauaktenanzeige

UKOS

Umsetzungsprojekt kommunale Straßendaten (UkoS)

In diesem Plugin wird das im Rahmen des UkoS-Projektes erarbeitete Datenmodell inklusive der Codelisten für kvwmap verfügbar gemacht und fortgeführt.

Änderungen an den Daten im UKOS-Datenmodell werden durch Anwendungsfälle beschrieben und einen Erfassungsleitfaden erläutert. Die Anwendungsfälle sollen in Form von Triggerfunktionen in das Datenbankmodell eingearbeitet werden. Die Verschiebung der Funktionalität auf die Server-Seite in die Datenbank, insbesondere die Einhaltung der Topologie, soll ermöglichen, dass die Daten mit einfachen GIS-Clients auch über WFS bearbeitet werden können.

kvwmap als WebGIS Server- und Client-Komponente hält sowohl das Datenmodell als auch Definitionen von Layern zur Visualisierung und Bearbeitung der Daten im UKOS-Plugin vor und möchte so die Nutzung des UKOS-Modells im WebGIS kvwmap unterstützen.

Ermöglicht

• die topologisch korrekte Erfassung und Verarbeitung von Straßendaten in Anlehnung an das Modell von OKSTRA
• die auf das Straßennetz bezogene Erfassung und Fortführung von Doppik-Objekten

Hinweis

Das Plugin ist noch nicht vollständig, da die Trigger zur Unterstützung der Anwendungsfälle noch nicht veröffentlicht sind. Außerdem fehlen noch die Layer. Das Datenmodell kann aber schon genutzt werden um Daten in den vorhandenen Tabellen zu erfassen

Wasserrecht

Allgemeines

Das Landesamt für Umwelt, Naturschutz und Geologie Mecklenburg-Vorpommern (LUNG) erstellt gegenwärtig ein zentrales Fachinformationssystem für den Wasserrechtlichen Vollzug (FisWrV). Ziel ist es, die verschiedenen Fachinformationssysteme und Datenbanken im Wasserrechtlichen Vollzug (Wasserbuch M-V, Kläranlagen, Berechnung der Abwasserabgabe für das Land Mecklenburg-Vorpommern, Rohwasserdaten, SÜVO-Daten, HELCOM-Daten, Prioritäre-Stoffe-Daten) zentral an einer Stelle zusammenzuführen und die dezentrale, oft redundante und im ungünstigsten Fall widersprüchliche Datenhaltung zu beenden. Das Fachinformationssystem soll ferner in der Lage sein, über nutzergruppenspezifische Fachschalen das Wasserbuch M-V zu erstellen und zu verwalten, verschiedenen Berichtspflichten nachzukommen (EU-Kommunalabwasserrichtlinie, HELCOM) sowie die Erhebung des Wasserentnahmeentgeltes und der Abwasserabgabe zu gewährleisten. Ferner sollen Daten zur Rohwasserbeschaffenheit eingebunden werden können. Der Aufbau soll über mehrere Jahre modular in Schritten erfolgen.

Komponenten des Plugins

Das Plugin "Wasserrecht" enthält als erste Bausteine des FIS-WrV zwei Fachschalen:

• Fachschale "Wasserrechte" als zentrales Register aller Gewässerbenutzungen im Land Mecklenburg-Vorpommern als Folgelösung für das Wasserbuch MV.
• Fachschale "Wasserentnahmeentgelt" (WEE): Diese kann alle zentral zu verwaltenden Aspekte rund um die Erhebung des Wasserentnahmeentgeltes abbilden, verwalten und Schreiben, Bescheide sowie Berichte erstellen.

Der Zugang zu und die Rechte an den beiden Fachschalen werden über unterschiedliche Stellen geregelt.

Fachschale „Wasserrechte“

Die Fachschale Wasserrechte soll nach Inbetriebnahme das derzeitige Wasserbuch M-V ablösen. Damit verbunden ist eine „Modernisierung“ des Datenmodells. Die Fachschale enthält fünf Layer (Anlagen, Personen, Wasserrechtliche Zulassungen, Gewässerbenutzungen und die Lage der Benutzungen), die untereinander verknüpft sind.

Layer „Anlagen“

Anlagen sind die zentralen Objekte (Wasserwerk, Kläranlage, Landwirtschaftsbetrieb etc.) für die ein oder mehrere funktional zusammenhängende FisWrV-Datensätze vorliegen. Der Layer Anlagen ist somit zentraler Einstiegspunkt in die Verwaltung von Gewässerbenutzungen. Hier hat der Benutzer die fünf Bestandteile des relationalen Datenmodells (Anlagen, Personen, Wasserrechtliche Zulassungen, Gewässerbenutzungen und die Lage der Benutzungen) auf einen Blick zur Verfügung und kann in die anderen Layer wechseln um dort neue Objekte anzulegen oder vorhandene Datensätze (z.B. Personen) einer Wasserrechtlichen Zulassung zuzuordnen.

Layer „Personen“

Alle Personendaten im Zusammenhang mit dem Wasserrechtlichen Vollzug sollen zentral in einer Tabelle gespeichert werden. Entsprechend enthält die Haupttabelle des Layers Personen der Fachschale Wasserrechte vor allem klassische Adressdaten (Name, Straße, PLZ etc.), die Bankverbindung sowie Spalten, welche die Gruppenzugehörigkeit der Personen regeln. Ferner können Personen mit übergeordneten Personen verbunden werden, um Behörden und deren Mitarbeiter oder Schuldnergemeinschaften darzustellen. Dabei wird von einem normalen Schutzbedarf (BSI-Grundschutzhandbuch Schicht 5) ausgegangen.

Layer „Wasserrechtliche Zulassungen“

Für eine Anlage können ein oder mehrere Wasserrechtliche Zulassungen vorliegen. Dies sind Verwaltungsakte, die eine oder mehrere Gewässerbenutzungen regeln. In der Haupttabelle werden vor allem der Adressat (natürliche oder juristische Person), die erlassende Behörde und der Sachbearbeiter hinterlegt. Außerdem verschiedene formelle Daten wie Typus (Wasserrechtliche Erlaubnis, Bewilligung etc.), Aktenzeichen, Datum, Fassung, Bestandskraft und Gültigkeit.
Es soll darüber hinaus die Möglichkeit bestehen, digitale Ausfertigungen der Wasserrechtlichen Zulassung in der Datenbank zu speichern. Ein Problem bei der Verwaltung der Wasserrechte ist der automatische Übergang einer Wasserrechtlichen Zulassung an einen Rechtsnachfolger (ohne, dass es einer Anzeige oder eines neuen Bescheides bedarf). Gleichzeitig ändern sich die Zulassungen einer Anlage ständig durch Neu- oder Änderungsbescheide. Dies kann bei der Erhebung des Wasserentnahmeentgelts insofern problematisch werden, da es rückwirkend erhoben wird. Daher wurde eine Historienverwaltung implementiert.

Layer „Gewässerbenutzungen“

Wasserrechtliche Zulassungen können auch mehrere Gewässerbenutzungen beinhalten. Entsprechend müssen diese in einer anderen Tabelle geführt werden. Die Haupttabelle des Benutzungslayers enthält im Wesentlichen vier Informationen:

• die Art der Benutzung (Entnahme, Einleitung, Stauhaltung etc.)
• den Zweck der Benutzung (öffentliche Trinkwasserver-sorgung, Bewässerung, Kühlung etc.)
• den Umfang der Benutzung (Kubikmeter pro Tag, Monat, Jahr, Verschmutzungsrechte etc.)
• und die Lage der Benutzung (Hoch- und Rechtswerte vom Brunnen, Ausleitbauwerk etc.)

Fachschale „Wasserentnahmeentgelt“

Die Fachschale Wasserentnahmeentgelt soll die Haupttabellen der Layer Personen, Wasserrechtliche Zulassungen und Gewässerbenutzungen zu einem Layer „Wasserentnahmebenutzer“ zusammenfassen, in dem für jeden Benutzer alle Benutzungen mit Eckdaten aufgeführt werden. In einem zweiten Layer „Wasserentnahmeentgelt“ sollen die Parameter der zugelassenen Benutzung aus der Gewässerbenutzungstabelle mit den für die Erhebung des Wasserentnahmeentgelts gemeldeten Daten verglichen werden. Der dritte Layer „Zentrale Stelle“ fasst dann alle Gewässerbenutzer einer Unteren Wasserbehörde zusammen und ermöglicht die Erstattung des Verwaltungsaufwandes.
Mit der Fachschale Wasserentnahmeentgelt ist es möglich alle zentral zu verwaltenden Aspekte rund um die Erhebung des Wasserentnahmeentgeltes abzubilden, zu verwalten und Schreiben, Bescheide sowie Berichte zu erstellen. Im Wesentlichen beinhaltet die Fachschale vier Layer und entsprechende Oberflächen, welche die einzelnen Bearbeitungsschritte bei der Erhebung des Wasserentnahmeentgeltes wiedergeben. Die dafür benötigten Adress- und Wasserrechtsdaten werden aus Haupttabellen der Fachschale Wasserrechte (Layer Personen, Wasserrechtliche Zulassungen und Gewässerbenutzungen) abgefragt.

Layer „Wasserentnahmebenutzer“

Über den Layer Wasserentnahmebenutzer lassen sich die Sammelaufforderungen zur Erklärung der Wasserentnahme und die Sammelfestsetzungsbescheide an den Adressaten der entsprechenden Wasserrechtlichen Zulassungen erstellen. Ferner sollen Gewässerbenutzer durch die Untere Wasserbehörde für die Erstellung des Antrages auf Erstattung des Verwaltungsaufwandes an das Landesamt für Umwelt, Naturschutz und Geologie (LUNG) ausgewählt werden können.

Layer „Wasserentnahmeentgelt“

Der Layer Wasserentnahmeentgelt soll es nach Rücklauf der Erfassungsbögen (siehe oben) ermöglichen, für jede Wasserentnahmebenutzung die im Erhebungsjahr entnommene Menge sowie den Entnahmezweck zu erklären und diese mit der zugelassene Menge und dem zugelassenen Zweck zu vergleichen. Außerdem sollen Ausnahmetatbestände nach § 16 Absatz 2 Nummer 1 bis 6 LWaG M-V identifiziert werden können. Es besteht die Möglichkeit zu erklären, dass mit einem Verlust von weniger als 1% wiedereingeleitet wurde (im Zusammenhang mit § 16 Absatz 3 Satz 2 LWaG M-V). Anschließend soll mit diesen Angaben das Wasserentnahmeentgelt ermittelt werden.

Layer „Zentrale Stelle“

Der Layer „Zentrale Stelle“ listet für jede Wasserbehörde alle Gewässerbenutzer und Übersichtsdaten der zugehörigen Gewässerbenutzungen auf. Es wird die Anzahl der Entnahmebenutzungen, der Aufforderungen zur Erklärung der Wasserentnahmen, der Rücklauf der Erklärungen der Wasserentnahmen, der Sammelfestsetzungsbescheid sowie die Summe der festgesetzten, eingegangen und abgeführten Beträge dargestellt. Außerdem wird geprüft, ob noch Vorgänge offen sind. Ferner wird dargestellt, ob das festgesetzte Wasserrentnahmeentgelt vollständig bei den UWB eingegangen ist und an das LM abgeführt wurde. Für Benutzer, für die mindestens ein Festsetzungsbescheid vorliegt, wird mit Hilfe des Layers und einer Auswahlfunktion ein Datensatz für den Layer „Erstattung des Verwaltungsaufwandes“ erstellt. Dies darf pro Erhebungsjahr und Benutzer jedoch nur einmal erfolgen.

Layer „Erstattung des Verwaltungsaufwands“

Der Layer „Erstattung des Verwaltungsaufwandes“ führt alle Benutzer auf, für die von der UWB die Erstattung des Verwaltungsaufwandes beim LUNG beantragt wurde. Dies ist auch mit mehreren Anträgen, aus dem Layer „Zentrale Stelle“, möglich. Entsprechend kann ein Datensatz des Layers „Zentrale Stelle“ auf mehrere Datensätze des Layers „Erstattung des Verwaltungsaufwands“ verweisen. Dies wäre beispielsweise der Fall, wenn eine UWB die Anträge auf Erstattung für ihre Benutzer zu unterschiedlichen Zeiten stellt. Der Layer enthält eine Übersicht aller im Layer „Zentrale Stelle“ bei der Erstellung ausgewählten Benutzer, für welche die Erstattung beantragt werden soll. Ferner ist es möglich das Datum des Antrages, Informationen zum Sachbearbeiter, der den Antrag gestellt hat und ein Kassenzeichen und/oder Personenkonto einzutragen. Mit Hilfe eines Buttons soll aus dem Datensatz ein Antrag auf Erstattung an das LUNG gestellt werden können. Außerdem wird der Datensatz damit gegen Veränderungen durch die UWB geschützt und zur Bearbeitung durch das LUNG freigegeben. Gleichzeitig wird verhindert, dass über den Layer „Zentrale Stelle“ neue Datensätze zur Erstattung des Verwaltungsaufwandes für diese Benutzer und dieses Jahr erstellt werden können. Dazu wird diese Information auch an den Benutzer und die Benutzung weitergegeben. Allerdings ist es den anderen Unteren Wasserbehörden weiterhin möglich, Anträge auf Erstattung des Verwaltungsaufwands zu stellen, falls der betreffende Benutzer auch Gewässerbenutzungen im Zuständigkeitsbereich der anderen Behörden hat. Die gestellten Anträge werden im Layer hinterlegt.
Für jeden Gewässerbenutzer kann eine Stelle des LUNG entscheiden, ob dessen Antrag auf Erstattung stattgegeben wird oder nicht. Dazu wird mittels eines Auswahlfeldes für jeden entsprechenden Benutzer „stattgegeben“ oder „abgelehnt“ ausgewählt. Anschließend kann mittels eines Buttons ein Bescheid erstellt werden, der sich an die Untere Wasserbehörde richtet. Dieser enthält eine Liste aller Benutzer, für welche dem Antrag auf Erstattung stattgegeben und für welche er abgelehnt wurde. Mit Erstellung des Bescheides wird die Entscheidung über „stattgeben“ oder „ablehnen“ gegen nachträgliche Veränderung gesperrt. Ferner werden das Datum des Bescheides und Informationen zum Sachbearbeiter, der den Bescheid erstellt hat, aufgeführt. Die erstellten Bescheide werden im Layer hinterlegt.

Benutzer- und Rechteverwaltung

Mit den Fachschalen sollen anfänglich die Unteren Wasserbehörden der sechs Landkreise, der zwei kreisfreien Städte und der vier Staatlichen Ämter, das Landesamt für Umwelt Naturschutz und Geologie (LUNG) als Obere Wasserbehörde sowie das Ministerium für Landwirtschaft und Umwelt (LM) als Oberste Wasserbehörde arbeiten.
Die Verwaltung der Personen-Daten soll beim LUNG liegen. Dieses soll auf Antrag der Unteren Wasserbehörden neue Personen anlegen und bestehende korrigieren können.
Die Wasserrechtlichen Zulassungen, Benutzungen und Lage-der-Benutzung-Daten sollen von den Unteren Wasserbehörden eingepflegt, aber nur vom LUNG freigegeben werden können.
Die Aufforderung zur Erklärung der Entnahme, die Erklärung der Entnahme, die Festsetzung des Wasserentnahmeentgeltes, der Sammelfestsetzungsbescheid sowie der Antrag auf Erstattung des Verwaltungsaufwandes liegen in alleiniger Verantwortung der Unteren Wasserbehörden. Das LM soll lediglich Leserechte erhalten.
Die UWB und das LUNG sollen grundsätzlich drei verschiedene Nutzergruppen erhalten, die im Plugin als Stellen enthalten sind:

• „Dateneingeber“ dürfen Datensätze in der Zuständigkeit der Behörde (über Attribut geregelt; z.B. UWB LR LRO) erstellen und abspeichern, aber keine Bescheide, Anträge etc. erstellen, also keine Arbeitsvorgänge abschließen und keine Änderungen an bestehenden Daten vornehmen.
• „Entscheider“ dürfen Datensätze in der Zuständigkeit der Behörde erstellen und abspeichern und Bescheide, Anträge etc. erstellen, also Arbeitsvorgänge abschließen; sie dürfen aber keine Änderungen an bestehenden Daten vornehmen.
• „Administratoren“ dürfen Datensätze in der Zuständigkeit der Behörde erstellen und abspeichern, Bescheide, Anträge etc. erstellen, also Arbeitsvorgänge abschließen und sie dürfen Änderungen an bestehenden Daten vornehmen.

Die erforderlichen Rechteeinstellungen der 3 Stellen bzgl. Editierbarkeit bzw. Sichtbarkeit bestimmter Felder usw. sind im Plugin enthalten.

xplankonverter

Allgemeines

Konvertiert Raumordnungspläne, die in ESRI Shape-Dateien vorliegen in XPlanGML und INSPIRE-GML (PLU)

Ermöglicht

• das Hochladen von Shape-Dateien oder existierenden XPlan-GML-Dateien in die Postgres Datenbank von kvwmap,
• die Anzeige der Shape-Dateien in der Karte und der Sachdaten,
• die manuelle Eingabe von Angaben zu Plänen und Planbereichen,
• das Festlegen von Regeln zur Konvertierung vom Shape-Datenmodell in das XPlanung Schema,
• die Ausführung der Konvertierung,
• die Anzeige der GML-Tabellen in der Karte und der Sachdaten,
• das Validieren der Datensätze,
• den Export nach XPlanGML und
• den Export nach INSPIRE-GML.

Der Konverter wurde im Rahmen einer vom BBSR finanzierten MORO Studie erstellt.

Bei Fragen wenden Sie sich bitte an:

• Robert Krätschmer robert.kraetschmer (ät) gdi-service.de oder
• Peter Korduan peter.korduan (ät) gdi-service.de

Konvertierung nach XPlan-GML

Plandaten

Einleitung

Die Konvertierung von Ursprungsdaten der Bauleitplanung in das Format XPlanung ist ein komplexer Vorgang. Da die Datenstruktur und -angaben der Ursprungsdaten oft nicht den Vorgaben des Standards entsprechen, müssen diese angepasst und ergänzt werden. Dies ist mit der OpenSource Software XPlankonverter möglich. Eine Instanz der Software für Bauleitpläne in Mecklenburg-Vorpommern ist unter folgender URL aufrufbar: https://bauleitplaene-mv.de/konverter

Im folgenden soll eine beispielhafte Konvertierung von Basisdaten, in denen der Plan als PDF-Datei ohne vektorielle Fachobjekte vorgehalten wird dargestellt werden. Hierfür müssen Daten zum Plan und zum Bereich befüllt werden. Diese Daten müssen daraufhin validiert werden und eine GML beziehungsweise XPlanung-konforme Shape-Dateien erzeugt werden. Der Vorgang ist in Kapitel beschrieben.

Konvertierung

Das Konvertierungsformular

Nach Aufruf der Seite https://bauleitplaene-mv.de/konverter werden Benutzername und Passwort des Nutzers abgefragt. Falls diese noch nicht vorliegen, kann ein Administrator diese erstellen. Nach dem Login in die Software landet der Nutzer in der für ihn zugewiesenen Stelle. Diese kann z.B. eine der Ämter in Mecklenburg-Vorpommern (z.B. Amt Altenpleen) oder auch eine Administrationsstelle sein. Das dargestellte Kartenfenster erlaubt die Filterung und Darstellung der jeweils für die Stelle verfügbaren Pläne sowie eine Orka-MV Hintergrundkarte. Unter dem auf der linken Seite zu findenen aufklappbaren Menüpunkt Konvertierungen finden sich Unterpunkte zu BP-Plänen, FP-Plänen und SO-Plänen. BP-Pläne modellieren Bebauungspläne, FP-Pläne Flächennutzungspläne und SO-Pläne Sonstige Planwerke. Die Nomenklatur orientiert sich dabei an dem Aufbau von XPlanung. Weitere Informationen zum Aufbau von XPlanung finden sich unter http://www.xplanungwiki.de.

Nach Klick auf einen der Menüpunkte, z.B. BP_Plan wird eine Liste aller Konvertierungen der Stelle aufgezeigt. Diese enthalten eine Bezeichnung (z.B. Bebauungsplan Nr. 1 Gemeinde Mohrdorf), einen Status der Konvertierung (z.B. erstellt oder GML-Erstellung abgeschlossen), Icons für Funktionen (z.B. Konvertierung bearbeiten oder Xplan-Gml Datei erzeugen) und Downloadoptionen (z.B. als Xplan GML-Datei). Am unteren Ende der Seite findet sich gleichfalls ein Knopf zum Anlegen einer neuen Konvertierung.

Beim Klick auf den Knopf Neu öffnet sich ein Formular, dass eine neue Konvertierung erfassen kann. Diese benötigt einen Verweis auf den zu konvertiertenden Plantyp (z.B. BP-Plan). Weiterhin ist es sinnvoll eine Bezeichnung der Konvertierung zur besseren Wiedererkennung in der Software einzugeben. Das gewählte Koordinatensystem für die Eingabe kann das Koordinatensystem der Ursprungsdaten halten, das Ausgabesystem gibt das System der Geodaten innerhalb der konvertierten Daten an. Nach Eingabe und Prüfung aller Werte kann die Konvertierung über den Knopf Speichern gespeichert werden.

Nach der Speicherung der Konvertierung wird diese im Konvertierungsfenster aufgeführt. Das Konvertierungsfenster ist unter dem Menüpunkt der jeweiligen Konvertierungsklasse (z.B. BP-Pläne) wieder aufrufbar. Die nun erstellte Konvertierung kann im Folgenden bearbeitet werden. Falls für den räumlichen Geltungsbereich des Plans eine Shape-Datei zur Verfügung steht, kann diese über die Funktion „Shapefiles bearbeiten“ (ein blauer Pfeil nach oben, siehe Abbildung 1) hochgeladen und in der Konvertierung verwiesen werden.

Nach einem möglichen Shape-Upload unter Angabe des relevanten Koordinatensystems der Shape kann über die Funktion Konvertierung bearbeiten (ein blauer Stift) die Konvertierung bearbeit werden und ein Plan angelegt werden.

Das Planformular

Über die Funktion Konvertierung bearbeiten wird das Konvertierungsformular wieder aufgerufen. Hier kann im Menüpunkt „Plan“ ein neuer Plan hinzugefügt werden. Mit Klick auf den Punkt hinzufügen wird ein neues Formular für den Plan geöffnet. Dieses enthält Daten, die den Plan beschreiben und relevante Dokumente mit diesem vernetzen. Mehrere Daten im Planformular sind dabei Pflicht und zwingend zu befüllen. Ohne eine Befüllung dieser Daten kann der Plan nicht erfolgreich gespeichert werden. Pflichtelemente sind mit einem Stern hinter ihrem Namen gekennzeichnet. Es handelt sich dabei für BP-Pläne um:

• Name

• Nummerierung

• Die für den Plan zuständige Gemeinde

• Aktueller Rechtsstand des Plans

• Planart

• Die Geometrie des räumlichen Geltungsbereiches (Umrings) des Plans.

Eine Definition der einzelnen Attribut findet sich im orangenen Ausrufezeichen hinter jedem Attributnamen. Einge Attribute sind Datentypen und öffnen beim Neuanlegen Unterfenster. Auch können für einige Elemente mehr als ein Wert angegeben werden. Der genaue Aufbau ergibt sich dabei aus dem Xplanungs-Modell. Eine beispielhafte Befüllung einiger Elemente findet sich in Abbildung 2 und Abbildung 3.

Ein PDF des Plans kann über eine Externe Referenz auf den Server geladen werden (Gliederungspunkt Dokumente → Attribut externeReferenz → Unterattribut Referenz-URL → Auswahl der PDF-Datei) und mit dem Plan in Verbindung gesetzt werden. In ähnlicher Weise können z.B. auch Umweltberichte oder Satzungen an den Plan angehängt werden.

Nach dem Befüllen aller Pflichtelemente kann der Plan am Ende der Seite gespeichert werden.

Das Bereichsformular

Ein Bereich strukturiert in XPlanung einen Plan inhaltlich oder fachlich. In diesem Beispiel wird vom Fall eines Bereichs für einen Plan ausgegangen. Der Bereich enthält dabei weitere Metadaten zur Rechtslage des Planes und eine optionale Geometrie eines Geltungsbereiches des Bereichs. Die Angabe einer Geometrie ist jedoch nur bei Abweichungen zur Gesamtgeometrie des Plans (der räumliche Geltungsbereich auf Planebene) sinnvoll, ansonsten aber redundant.</p> Ein neuer Bereich kann bei Wiederaufrufen des Plans (Menüpunkt BP-Pläne → Konvertierung bearbeiten → Link des Plans → Spalte Bereiche am Ende des Plans → Neu Knopf) angelegt werden. Ein Bereich hat nur das Attribut nummer als Pflichtattribut. Nach dem Befüllen des Formulars kann dieses gleichfalls über den Speichern-Knopf am Ende der Seite gespeichert werden. Ein beispielhaft befüllter Bereich ist in Abbildung 4 zu sehen.

Konvertierung und Validierung

Nach dem Befüllen eines Plan- und Bereichformulars kann eine Konvertierung durchgeführt und validiert werden. Der Knopf hierfür sind 3 blaue Zahnräder im Konvertierungsfenster für die jeweilige Konvertierung. Daraufhin werden mögliche Validierungsfehler (z.B. eine Selbstüberschneidung der Geometrie des Plans), Warnungen und/oder gelungene Validierungsprüfungen gegen das XPlanung-Format angezeigt. Diese müssen für eine erfolgreiche Konvertierung zuerst behoben werden. Falls keine Fehler angezeigt werden ist daraufhin das Erstellen einer GML-Datei aus der Konvertierung möglich (öffnende und schließende blaue Klammern). Über den Button (das Auge) kann man einen Plan veröffentlichen. Siehe dazu die Doku im Wiki des Bauleitplanservers von MV.

GML und Shapes

Nach Erstellung der GML-Datei aus einer validen Konvertierung können eine XPlanung-GML und/oder XPlanung-konforme Shape-Dateien über die Spalte Downloads heruntergeladen werden. Der XplanGML-Download ist ein mit einem roten X markiertes Dokument-Icon. Die so erstellte GML-Datei kann über einen Browser, über einen Texteditor oder über ein GIS eingesehen werden. Über eine Schemavalidierung gegen das Modell (XSD-Validierung) kann über externe Softwares die Schemakonformität unabhängig verifiziert werden.

Zusammenfassung

Die Software Xplankonverter erlaubt die Erstellung von schemakonformen XML-Dateien und Xplankonformen Shapedateien über eine formularbasierte Erfasungsoberfläche. Die so erstellten GML-Dateien können für weitere Austauschvorgänge genutzt werden

Bereitstellung von WMS und WFS

Map-Datei erzeugen

Um die Daten der Pläne in einem WMS und WFS bereitstellen zu können erstellt das Plugin eine UMN-Mapserver Map-Datei. Diese kann über den Menüpunkt Landesdienst update erzeugt werden. Dahinter steckt der Case go='xplankonverter_create_geoweb_service'. Die Map-Datei wird an folgende Stelle geschrieben: INSTALLPATH.WMS_MAPFILE_REL_PATH.MAPFILENAME.map. Die Konstanten in diesem Pfad können alle in der Administration unter OWS-Metadaten gesetzt werden. Als Name für die Map-Datei wird der Wert aus der Konstante PUBLISHERNAME verwendet. Auch diese Konstante kann über die Administrationsseite geändert werden. Die Metadaten ows_title und ows_abstract werden aus den Einstellungen der Stelle entnommen in der der Anwendungsfall xplankonverter_create_geoweb_service aufgerufen wird. Die Einstellungen können im Stelleneditor unter der Gruppe Metadaten angepasst werden. Die restlichen Metadaten werden beim Laden des Map-Objektes in der Funktion GUI->loadMap() gesetzt:

 $map->setMetaData("ows_title", $this->Stelle->ows_title ?: OWS_TITLE);
 $map->setMetaData("ows_abstract", $this->Stelle->ows_abstract ?: OWS_ABSTRACT);
 $map->setMetaData("ows_accessconstraints", $this->Stelle->wms_accessconstraints ?: OWS_ACCESSCONSTRAINTS);
 $map->setMetaData("ows_contactorganization", $this->Stelle->ows_contactorganization ?: OWS_CONTACTORGANIZATION);
 $map->setMetaData("ows_contactperson", $this->Stelle->ows_contactperson ?: OWS_CONTACTPERSON);
 $map->setMetaData("ows_contactposition", $this->Stelle->ows_contactposition ?: OWS_CONTACTPOSITION);
 $map->setMetaData("ows_contactelectronicmailaddress", $this->Stelle->ows_contactelectronicmailaddress ?: OWS_CONTACTELECTRONICMAILADDRESS);
 $map->setMetaData("ows_contactvoicetelephone", $this->Stelle->ows_contactvoicephone ?: OWS_CONTACTVOICETELEPHONE);
 $map->setMetaData("ows_contactfacsimiletelephone", $this->Stelle->ows_contactfacsimile ?: OWS_CONTACTFACSIMILETELEPHONE);
 $map->setMetaData("ows_stateorprovince", $this->Stelle->ows_contactadministrativearea ?: OWS_STATEORPROVINCE);
 $map->setMetaData("ows_address", $this->Stelle->ows_contactaddress ?: OWS_ADDRESS);
 $map->setMetaData("ows_postcode", $this->Stelle->ows_contactpostalcode ?: OWS_POSTCODE);
 $map->setMetaData("ows_city", $this->Stelle->ows_contactcity ?: OWS_CITY);
 $map->setMetaData("ows_country", OWS_COUNTRY);
 $map->setMetaData("ows_addresstype", 'postal');
 $map->setMetaData("ows_fees", $this->Stelle->ows_fees ?: OWS_FEES);
 $map->setMetaData("ows_encoding", 'UTF-8');
 $map->setMetaData("ows_keywordlist", OWS_KEYWORDLIST);
 $map->setMetaData("ows_contactinstructions", OWS_CONTACTINSTRUCTIONS);
 $map->setMetaData("ows_hoursofservice", OWS_HOURSOFSERVICE);
 $map->setMetaData("ows_role", OWS_ROLE);
 $map->setMetaData("ows_srs", $this->Stelle->ows_srs ?: OWS_SRS);

In den meißten Fällen werden die Daten also aus den Einstellungen der Stelle entnommen falls vorhanden und wenn nicht aus den Konstanten der Admin-Einstellungen. Nach dem Ausführen des Anwendungsfalls werden die in der Map-Datei angelegten Layer angezeigt.

Als Layernamen werden die Namen der Layer verwendet. Wenn in der Stelle in der die Map-Datei erzeugt wird die Option Layer-Alias-Namen verwenden eingeschaltet ist, werden als Titel der Layer in den Diensten die Alias-Namen verwendet. Die Layernamen im WMS sind identisch mit den FeatureTypen im WFS und entsprechen immer dem Layer-Namen.

Die DATA Sektionen der Layer wird generisch an Hand des Datenmodells abgeleitet. Dafür wird die Funktion get_generic_data_sql() der Klasse Layer verwendet. Dort ist auch geregelt wie die Enumerations, CodeListen und komplexen Datentypen abgefragt werden sollen. Damit die SQL-Abfragen in den DATA Sektionen mit den Templates übereinstimmen ist in den Layern die Option write_mapserver_templates auf generic zu setzen. Im Layereditor im Abschnitt OWS-Parameter Schreibe MapServer Templates => von Haupttabelle ableiten.

Wenn die Mapserver-Templates dann mit der Funktion Schreibe Mapserver Templates geschrieben werden, stimmen die Templates mit dem SQL der Map-Datei überein, siehe Abschnitt Plugins#Template-Dateien_erzeugen.

Template-Dateien erzeugen

Damit die Template-Dateien zum DATA-Statement der Layer in der Map-Datei passen können auch diese automatisch erzeugt werden. Dazu müssen die Layer im Parameter write_mapserver_template den Wert generic haben. Einzustellen geht das im Layereditor unter Abschnitt OWS-Parameter Schreibe MapServer Templates von Haupttabelle ableiten. Von Haupttabelle ableiten bedeutet, dass in der Template-Datei für den Body alle Attribute aufgeführt werden, die auch in der Haupttabelle (maintable) des Layers enthalten sind. Für Aufzählungen, Code-Listen und komplexe Datentypen gibt es gesonderte Ausgaben die mit Datenbank-Funktionen formatiert werden.

• Bei Enumerations gibt es zusätzlich ein Datenfeld welches so heißt wie das Attribut mit dem Zusatz _text für die Anzeige der Nummer und der Beschreibung. (Funktion gdi_enum_json_to_text)
• Bei CodeListen wird ein zusätzliches Feld mit dem Zusatz _text ausgegeben mit Angaben zum Codelisten-Repository (falls vorhanden) dem Wert und der Beschreibung. (Funktion gdi_codelist_json_to_text)
• Bei Datentypen erfolgt die Ausgabe in einem zusätzlichem Feld im JSON-Format mit dem Zusatz _dt aber nur für Werte die auch befüllt sind. (Funktion gdi_datatype_json_to_text)

Diese gesonderten Datenfelder sollen der besseren Lesbarkeit und Auswertbarkeit der Daten dienen. Die Formatierungsfunktionen stehen im Schema public.

Die Funktion gdi_enum_json_to_text erwartet folgende Parameter:

• value json: Den Wert des Attributes als JSON-Typ, z.B. to_json(xb.rechtscharakter)
• schema character varying: Name des Schemas in dem die Tabelle steht. Hier immer xplan_gml
• type character varying: Name des Aufzählungs, Codelisten oder Datentyps. z.B. bp_rechtscharakter
• is_array boolean: Ob das Attribut ein Array-Typ ist z.B. false bei rechtscharakter

Die Funktion gdi_codelist_json_to_text erwartet nur den Wert des Attributes als JSON und gdi_datatype_json_to_text das Attribut als JSON und ob es ein Array ist.

Der Aufruf der Funktionen ist in den DATA-Sektionen der Map-Datei zu sehen. Hier 3 Beispiele für enum, codelist und datatype Enumeration

 xb.rechtscharakter,
 gdi_enum_json_to_text(to_json(xb.rechtscharakter), 'xplan_gml', 'bp_rechtscharakter', false) AS rechtscharakter_text,

CodeListe

 (xb.gesetzlichegrundlage).id AS gesetzlichegrundlage_id,
 gdi_codelist_json_to_text(to_json(xb.gesetzlichegrundlage)) AS gesetzlichegrundlage_text,

Komplexe Datentypen

 xb.externereferenz,
 gdi_datatype_json_to_text(to_json(xb.externereferenz), true) AS externereferenz_dt,

Bei den Code-Listen gibt es noch eine Besonderheit. Wenn das Code-Listen-Attribut vom Typ Array ist, wird im richtigen Attribut nur der erste Wert ausgegeben. Die vollständigen Werte des Arrays von Codelistenwerten werden in dem zweiten Attribut ausgegeben welches den Zusatz _text hat. Beispiel:

 (xb.detailliertezweckbestimmung[1]).id AS detailliertezweckbestimmung_id,
 gdi_codelist_json_to_text(to_json(xb.detailliertezweckbestimmung)) AS detailliertezweckbestimmung_text,

Wie die Ausgaben der Enumerations, CodeListen und Datentypen in 2D-Tabellen erfolgen soll ist noch Gegenstand von Abstimmungen mit den verschiedenen Nutzern der Dienste. Es handelt sich hier um das generelle Problem des Mappings von komplexen Objektmodellen (komplexe Feature) in relationale Datenstrukturen (simple Feature).