Konfiguration DiPlanCockpit Pro: Unterschied zwischen den Versionen

Aus DiPlanung

Zeile 16: Zeile 16:
 
Das DiPlanCockpit wird beim Anlegen bzw. Verändern des Plannamens Validierungsprüfungen ausführen, um eine einheiltiche Qualität sicherzustellen, sofern entsprechende Validierungsregeln hinterlegt sind. Per Default sind keine Regeln vorgegeben, das heißt, es müssen Regeln hinzugefügt werden, wenn eine Validierung gewünscht ist. Hinterlegte Regeln können herunter- und hochgeladen werden. Sie greifen jeweils sofort nachdem sie in die Anwendung hochgeladen wurden. Der Download liefert eine XML-Datei, die angepasst und anschließend wieder hochgeladen werden kann. Bei der XML-Datei ist darauf zu achten, dass sie dem Schema plannameValidatorkonfiguration.xsd entspricht.
 
Das DiPlanCockpit wird beim Anlegen bzw. Verändern des Plannamens Validierungsprüfungen ausführen, um eine einheiltiche Qualität sicherzustellen, sofern entsprechende Validierungsregeln hinterlegt sind. Per Default sind keine Regeln vorgegeben, das heißt, es müssen Regeln hinzugefügt werden, wenn eine Validierung gewünscht ist. Hinterlegte Regeln können herunter- und hochgeladen werden. Sie greifen jeweils sofort nachdem sie in die Anwendung hochgeladen wurden. Der Download liefert eine XML-Datei, die angepasst und anschließend wieder hochgeladen werden kann. Bei der XML-Datei ist darauf zu achten, dass sie dem Schema plannameValidatorkonfiguration.xsd entspricht.
  
−
Für die Validierung werden Regex ausgeführt. Diese sehen beispielsweise aus wie folgt und können je Planart vergeben werden:
+
Weitere Informationen befinden sich auf der separaten Seite zum Thema [https://wiki.diplanung.de/Plannamenvalidierungsregeln%20aktualisieren Plannamenvalidierungsregeln aktualisieren].
−
[[Datei:ImagePlannamenvalidierungXML.png|verweis=https://wiki.diplanung.de/Datei:ImagePlannamenvalidierungXML.png|zentriert|rahmenlos]]
 
−
Erläuterung der Regex aus dem Beispiel, die pro Planart vergeben werden können:
 
−
 
 
−
* "[A-Z]{1}" = Ein Großbuchstabe (Eckige Klammern enthalten das, worum es geht; geschweifte Klammern geben an, wie viel.)
 
−
* "[a-z&&[^öüäß ]]" = direkt anschließend Kleinbuchstaben mit Ausnahme von Umlauten, "ß" und Leerzeichen
 
−
* "+" = Kombination mehrerer Vorgaben in eckigen Klammern "[''beliebiger Inhalt'']"
 
−
* "[0-9]{1,3}" = direkt anschließend 1 bis 3 Zahlen
 
−
* "[-]{1}" = Bindestrich bzw. Minus z.B. zur Verbindung mehrerer ORT-Angaben
 
−
 
 
−
=== Zur Vertiefung ===
 
−
 
 
−
==== Generelles ====
 
−
Folgende Zeichen sind unkritisch und im Plannamen verwendbar:
 
−
 
 
−
* Groß- und Kleinbuchstaben
 
−
* Zahlen
 
−
 
 
−
Zusätzlich Sonderzeichen, die im EfA DiPlanCockpit nun möglich sind:
 
−
 
 
−
* Umlaute als Groß- und Kleinbuchstaben wie "Öäß"
 
−
* Weitere Zeichen: ",:§" und Römische Ziffern
 
−
 
 
−
Zeichen mit besonderer Bedeutung in Regex:
 
−
 
 
−
* .()^*/
 
−
* Diese Zeichen müssen mit einen vorangestellten \ maskiert werden, um sie von ihrer Sonderrolle zu entbinden.
 
−
 
 
−
==== Details zur Konfiguration des Plannamenvalidators ====
 
−
Die Default-Konfiguration beinhaltet keine Validatorregeln, d.h. der Planname wird in diesem Fall nicht validiert.
 
−
<code><nowiki><?xml version="1.0" encoding="UTF-8"?>
 
−
<plannamenValidatorKonfiguration>
 
−
<!--Definition der plannameSyntaxRegel(n)-->
 
−
</plannamenValidatorKonfiguration></nowiki></code>
 
−
Enthält die XML-Konfigurationsdatei Validatorregeln, muss das zu prüfende Verfahren mindestens einer Validatorregel entsprechen, andernfalls wird der Planname als ungültig abgelehnt.
 
−
 
 
−
Die Validatorkonfiguration wird in XML beschrieben und basiert auf einem XML-Schema:
 
−
[[Datei:ImagePlannamenValidatorSchema.png|verweis=https://wiki.diplanung.de/Datei:ImagePlannamenValidatorSchema.png|zentriert|rahmenlos|623x623px]]
 
−
Innerhalb der XML-Datei können mehrere Validatoren konfiguriert werden. Ein Validator wird durch eine Planname-Syntax-Regel beschrieben. Dieses Element besteht aus 1-n Bedingungen und 1-n regulären Ausdrücken (Regex). Die Bedingungen beziehen sich auf Verfahrenseigenschaften und dienen dazu, den gültigen Validator für den Plannamen eines Verfahrens zu ermitteln. Folgende Verfahrenseigenschaften lassen sich in den Bedingungen abbilden:
 
−
 
 
−
* planart ** Planart des Verfahrens ** Datentyp: string
 
−
* hatBeschlussBuergerschaftSenatssitzungFnp ** optionale Zusatzprüfung für FNP-Verfahren: *** Sitzung "senatssitzung" hat stattgefunden UND politisches Sitzungsergebnis ist zugestimmt *** Sitzung "beschlussBuergerschaft" hat stattgefunden UND politisches Sitzungsergebnis ist zugestimmt ** Datentyp: boolean
 
−
* hatBeschlussBuergerschaftLapro ** optionale Zusatzprüfung für LaPro-Verfahren: *** Sitzung "beschlussBuergerschaft" hat stattgefunden UND politisches Sitzungsergebnis ist zugestimmt ** Datentyp: boolean
 
−
 
 
−
Die einzelnen Bedingungen einer Planname-Syntax-Regel sind ODER-verknüpft, d.h. bezogen auf das Verfahren muss mindestens eine Bedingung erfüllt sein, um den entsprechenden Validator anzuwenden. Der Planname wird dann anhand der regulären Ausdrücke geprüft. Diese regulären Ausdrücke sind ebenfalls ODER-verknüpft, d.h. der Planname ist valide, wenn seine Syntax mindestens einem regulären Ausdruck entspricht.
 
−
 
 
−
Beispiel:
 
−
<code><plannameSyntaxRegel>
 
−
    <bedingung>
 
−
        <planart>Baustufenplan</planart>
 
−
    </bedingung>
 
−
    <!--BSAltenwerder-->
 
−
    <regex>[B]{1}[S]{1}[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+</regex>
 
−
    <!--BSAltenwerder-Moorburg-->
 
−
    <regex>[B]{1}[S]{1}[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+[-]{1}[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+</regex>
 
−
</plannameSyntaxRegel>
 
−
<plannameSyntaxRegel>
 
−
    <bedingung>
 
−
        <planart>EinfacherBebauungsplan</planart>
 
−
    </bedingung>
 
−
    <bedingung>
 
−
        <planart>QualifizierterBebauungsplan</planart>
 
−
    </bedingung>
 
−
    <!--Hummelsbuettel7-->
 
−
    <regex>[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+[0-9]{1,3}</regex>
 
−
    <!--Hamburg-Altstadt26-->
 
−
    <regex>[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+[-]{1}[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+[0-9]{1,3}</regex>
 
−
    <!--Hamburg-Altstadt34-HafenCity2-->
 
−
    <regex>[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+[0-9]{1,3}[-]{1}[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+[0-9]{1,3}</regex>
 
−
    <!--Sonderfall Ort-minus-Ort-zahl-minus-Ort-zahl-->
 
−
    <regex>[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+[-]{1}[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+[0-9]{1,3}[-]{1}[A-Z]{1}<nowiki>[a-zA-Z&amp;amp;&amp;amp;[^öüäß]</nowiki>]+[0-9]{1,3}</regex>
 
−
    <!--Sonderfall „HafenCity“, „HafenCity11“-->
 
−
    <regex>[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+[A-Z]{1}<nowiki>[a-z&amp;amp;&amp;amp;[^öüäß ]</nowiki>]+[0-9]{1,2}</regex>
 
−
</plannameSyntaxRegel></code>
 
  
 
== Zeiträume eingeschränkter Verfügbarkeit hinzufügen ==
 
== Zeiträume eingeschränkter Verfügbarkeit hinzufügen ==

Version vom 6. Juni 2025, 11:44 Uhr

> Zurück zur Hauptseite DiPlanCockpit Pro für Mandanten-Administratoren (M-A)

Verfahrenskonfiguration[Bearbeiten | Quelltext bearbeiten]

Die Verfahrenskonfiguration definiert die Grundlagen für Verfahren, die im DiPlanCockpit zur Verfügung gestellt werden. Die als Default ausgelieferte Verfahrenskonfiguration kann Mandanten spezifisch angepasst werden. Sie besteht aus einer bzw. mehreren Dateien im XML-Format - je nach dem, wie viele verschiedene Verfahrenstypen konfiguriert sind.

Für die Verfahrenskonfiguration stehen ein Up- und Download zur Verfügung. Eine neu hochgeladene Verfahrenskonfiguration gilt für alle anschließend neu angelegten Verfahren, bereits vorhandene Verfahren werden dadurch nicht verändert.

Das Herunterladen der Verfahrenskonfiguration erfolgt in Form einer ZIP-Datei. Darin sind die XML-Dateien für jeden Verfahrenstyp.

Detaillierte Informationen finden sich auf der Seite zur Verfahrenskonfiguration.

Hinzufügen von Verfahren[Bearbeiten | Quelltext bearbeiten]

Verfahren lassen sich hier hochladen. Für den Upload muss das Verfahren in einer XML-Datei vorliegen und dem XÖV-Standard xPlanverfahren entsprechen. Es ist sowohl das Hochladen eines einzelnen Verfahrens als auch mehrerer Verfahren gleichzeitig möglich. Die maximale Anzahl an Verfahren, die gleichzeitig hochgeladen werden können, wird mittels des Systemparameters XPLANVERFAHREN_IMPORT_VERFAHRENSANZAHL festgelegt und kann darüber bei Bedarf angepasst werden. Dabei ist zu beachten, dass der Upload sehr vieler und großer Verfahren einige Zeit beansprucht. Außerdem werden die Verfahren vor dem Import automatisch auf Konformität mit dem XÖV-Standard validiert. Werden dabei Fehler festgestellt, bricht der gesamte Import ab. Detaillierte Informationen finden sich auf der Seite zum Thema "Verfahren hinzufügen".

Kontakteliste aktualisieren[Bearbeiten | Quelltext bearbeiten]

Hier lässt sich die Kontakteliste im XML-Format herunterladen, sodass Anpassungen daran vorgenommen werden können. Anschließend kann die angepasste Datei wieder hochgeladen werden. Details zur Anpassung finden sich auf der Seite zur Kontakteliste.

Plannamenvalidierungsregeln aktualisieren[Bearbeiten | Quelltext bearbeiten]

Das DiPlanCockpit wird beim Anlegen bzw. Verändern des Plannamens Validierungsprüfungen ausführen, um eine einheiltiche Qualität sicherzustellen, sofern entsprechende Validierungsregeln hinterlegt sind. Per Default sind keine Regeln vorgegeben, das heißt, es müssen Regeln hinzugefügt werden, wenn eine Validierung gewünscht ist. Hinterlegte Regeln können herunter- und hochgeladen werden. Sie greifen jeweils sofort nachdem sie in die Anwendung hochgeladen wurden. Der Download liefert eine XML-Datei, die angepasst und anschließend wieder hochgeladen werden kann. Bei der XML-Datei ist darauf zu achten, dass sie dem Schema plannameValidatorkonfiguration.xsd entspricht.

Weitere Informationen befinden sich auf der separaten Seite zum Thema Plannamenvalidierungsregeln aktualisieren.

Zeiträume eingeschränkter Verfügbarkeit hinzufügen[Bearbeiten | Quelltext bearbeiten]

Hier können Termine festgelegt werden, die bei der Zeitplanung nicht berücksichtigt werden sollen (Blacklist). Üblicherweise handelt es sich um Wochenenden und lokale Schulferien. Per Default ist keine Datei hinterlegt.

Für den Import von Blacklists ist das Format iCalendar-Format (.ics) erlaubt. iCalendar-Dateien aus Outlook können exportiert und ohne manuelle Anpassung im Cockpit hochgeladen werden.

IGC Template aktualisieren[Bearbeiten | Quelltext bearbeiten]

Hier kann das Template für die Bereitstellung von Planmetadaten im IGC (InGrid®Catalog) Format aktualisiert werden. Das Template kann im XML-Format herunter- und hochgeladen werden.

CSW-Template aktualisieren[Bearbeiten | Quelltext bearbeiten]

Hier lässt sich das CSW-Template im XML-Format herunterladen, sodass Anpassungen daran vorgenommen werden können. Anschließend kann die angepasste Datei wieder hochgeladen werden.

DCATAP PLU Template aktualisieren[Bearbeiten | Quelltext bearbeiten]

Hier lässt sich das DCATAP PLU Template im XML-Format herunterladen, sodass Anpassungen daran vorgenommen werden können. Anschließend kann die angepasste Datei wieder hochgeladen werden. 

Für die Anzeige und Überarbeitung der Templates sollte kein Browser sondern eine professionelle XML-Anwendung verwendet werden. Wenn eine solche nicht vorhanden ist, können Sie behelfsweise einen Texteditor wie Notepad++ nutzen.

Sitzungstermine[Bearbeiten | Quelltext bearbeiten]

Hier können feststehende Sitzungstermine für Verfahren (Whitelist) in Form einer .ske oder iCalendar (.ics) Datei hochgeladen werden. Hierfür können ICalendar-Dateien aus Outlook exportiert und ohne manuelle Anpassung im Cockpit hochgeladen werden. Beim Hochladen müssen die Zuständigkeit und die Sitzung, für die der Termin gesetzt werden soll, ausgewählt werden.

Die Whitelist umfasst die einzig möglichen Sitzungstage für entsprechende Sitzungen. Bei der Berechnung eines Sitzungsdatums wird geprüft, ob es eine Whitelist für die Kombination Zuständigkeit + Sitzungscode gibt.

Wenn es eine Whitelist gibt und die Daten nicht in der Vergangenheit liegen, dann wird diese Whitelist benutzt, d.h. das Sitzungsdatum fällt auf das nächstmögliche Datum aus der Whitelist.

Beispiel:

  • Prognostiziert: 20.5.25
  • Whitelisttermin: 22.5.25
  • Termin findet statt am 22.5.25

Wenn es keine Whitelist gibt oder alle Daten in der Vergangenheit liegen, dann werden für das Sitzungsdatum die prognostizierten Daten genutzt.

Beispiel:

  • Prognostiziert: 20.5.25
  • Whitelisttermin: 14.5.25
  • Termin findet statt am: 20.5.25
Abgerufen von „https://wiki.diplanung.de/index.php?title=Konfiguration_DiPlanCockpit_Pro&oldid=1677“