Ja, hallo. Schönen guten Tag. Schön, dass ihr hier seid. Mein Name ist Thorsten Frivel. Ich bin einer derjenigen, die die Software, die wir zum Glück gerade vorher vorgestellt bekommen haben, die Xbox Box mitentwickelt hat.

Und ich werde euch ein bisschen was erzählen, sozusagen aus dem Maschinenraum, was wir da nämlich gerade machen. Aber bevor ich anfange, prüfe ich jetzt erstmal, ob noch alle da sind. Das ist die versprochene Frage. Wer hat denn schon mal was von X-Planung gehört? Ja, nur um zu wissen. Okay. Das ist schon ein Riesenunterschied zu den Jahren

vorher, denn wir haben das, das werden wir auf einer Folie auch gleich sehen, schon seit einigen Jahren immer hier wieder mal auch in die Foskis-Community versucht reinzutragen. Da war das nicht immer so eine hohe Resonanz wie heute. Das freut mich sehr. Dann kommt aber noch die nächste Frage. Wer hat denn schon mal die X-Plan-Box gesehen?

Also da müssen jetzt auch einige Finger hochgehen. Ja, okay. Gut. Ich bin beruhigt, sind alle noch da. Hervorragend. Super. Dann legen wir los. Ich sage kurz was zu mir. Das Übliche gehen wir ein bisschen ins Thema rein und am Ende natürlich Fragen und Antworten. Ich bin von der Firma Lattlon. Wir sind schon seit über 20 Jahren hier in der Foskis-Community mit anderen Open-Source-Themen tätig

und sind dort unter anderem für das OSG-Projekt Degree seit langer Zeit, auch seit über 20 Jahren tätig und unterstützen das OGC, das Standardisierungsgremium bei der Entwicklung der Side-Test.

Das ist also die Testmaschine, mit der man WMS oder WFS oder heute dann OGC-API-Dienste verifizieren und prüfen kann, ob die das tun, was sie laut Speck tun sollen. Das ist so unser Tätigkeitsbereich.

Und irgendwie sind wir dann vor langer, langer Zeit. Die ältesten archäologischen Funde sind aus dem Jahre 2005, 2004, wo der erste Code entwickelt wurde, zu dem Thema auch X-Planung gekommen, damals absolutes Nischenthema und daraus wurde dann irgendwann die Software X-Planbox.

Zum Glück bin ich in der privilegierten Situation hier den Sandwich-Vortrag halten zu dürfen, nämlich ich habe vor mir einen super einleitenden Vortrag gehabt. Ihr habt alles gesehen, was die X-Planbox kann. Da werde ich jetzt gleich ein bisschen schneller durchgehen und danach kommt auch noch ein ganz spannender Vortrag.

Da gibt es dann noch mehr Bilderchen zu sehen, die sind bei mir ein bisschen rar gesehen. Also X-Planung ist ein Standard, aus dem wurde irgendwann X-Plan-GML oder dazu gehört X-Plan-GML. Und was macht jetzt also die X-Planbox? Die ist dafür da. X-Planungsdaten, das könnte hier so ein schöner Bebauungsplan, das ist Wilhelmsburg hier in Hamburg.

Kann man damit validieren, kann man damit verwalten und kann man damit publizieren. Was das bedeutet, sage ich gleich noch. Und was ist X-Planung? Man muss mindestens eine Folie mit X-Plan-GML mal gezeigt haben. Das sind 0,1 Prozent von diesem Bebauungsplan, der Rest ist einfach nur XML. Ist ja auch nicht dafür geschaffen worden für Menschen, dass sie das lesen können, sondern für Maschinen.

Und deswegen haben wir eine Software geschrieben, die genau das machen kann. Also ein bisschen genauer gesprochen heißt, das haben wir gerade auch gesehen schon in dem vorhergehenden Vortrag. Man kann also damit X-Planungsdaten, die in X-Plan-GML vorliegen, prüfen, egal ob Teil- oder Vollvektorial.

Am Ende muss immer so ein X-Plan-GML vorhanden sein, mit zusätzlich geo-referenzierten Rastadaten zum Beispiel. Es können B-Pläne, vielleicht Nutzungspläne oder andere Pläne sein. Man kann diese, wenn sie denn valide sind, mit der Software wiederum in einer zentralen Datenbank speichern.

Das ist also eine Datenbank, eine Postgres-Datenbank, auch das haben wir alles schon gerade gehört und gesehen. Und man kann wiederum über Geodatendienste, WFS und WMS, also die Standards, die es da gerade gibt, kann man diese Daten abrufen. Und damit erfüllt man dann auch bestimmte Anwendungsfälle im Bereich der Bereitstellungspflichten des Fachthemas X-Planung oder des europäischen Standards Inspire PLU.

Gucken wir uns ganz kurz die Komponenten an, weil zwei Komponenten sind die, die uns bei der Weiterentwicklung gerade so ein bisschen Probleme bereiten. Und ich will nur mal kurz erklären, damit das klar ist, was ist hier eigentlich die Komplexität da drin.

Der Validator. Der prüft halt, ist das X-Plan-GML in Ordnung. Das macht er in drei Schritten. Der prüft erst mal, ist das XML-Dokument halt schemakonform. Das geht relativ schnell. Das ist so Brot- und Buttergeschäft. Das kriegen die Bibliotheken schnell hin. Danach macht er eine geometrische Prüfung. Also das alles, was an Geometrien in dem X-Plan-GML drin steht, wird da geprüft.

Besondere Bedingungen, topologische Bedingungen, aber das geht dann auch ins Detail. Da muss dann geprüft werden. Oh, und das ist richtig crunchy. Also das dauert ein bisschen. Das erfordert CPU. Ich komme schon so der kleine erste Hinweis und brauche halt Rechenpower und auch Speicher.

Und dann haben wir noch die semantische Prüfung. Das sind X-Query -Regeln, die aus den natürlich sprachlich formulierten X-Planung-Konformitätsbestimmungen abgeleitet wurden. Die werden dann nochmal über das Dokument rübergejagt und geguckt, ob halt die Regeln, die halt in dem Standard festgeschrieben sind, erfüllt werden.

So, das ist nicht so der entscheidende Schritt. Da gibt es drei Schnittstellen. Eine WebUI haben wir auch gesehen. Eine Restschnittstelle und ein Kommandozahleninterface und damit kann man das nutzen. Soweit so gut haben wir uns gemerkt, aha, es gibt den validator. Wenn ihr seine Arbeit getan habt, kriegt man da so eine Auswertung, aha, was für eine Datei habe ich reingesteckt, welches Ergebnis hat die.

Ich kann hier übrigens den Pointer natürlich verwenden, muss ich den hier nicht im Bild stehen. Und ich sehe weitere Informationen. Ich kann auch eine Prüfung machen, sind die Flächen an der Stelle, wo ich sie erwartet habe. Ist das inhaltlich, fachlich okay?

Das ist die Leistung des Expanvalidators, dass er halt sagen kann, ist okay oder ist halt nicht okay. Wenn, wo sind die Probleme? Sind die auf der syntaktischen, geometrischen oder semantischen Ebene? Kann die Geometrien, die falsch sind, da auch abrufen, um sie dann in einem GISS-System, zum Beispiel QGIS, dann wiederum gegen mein GML zu prüfen und sagen,

ah ja, das ist genau die Geometrie, die falsch ist. Dann haben wir eine zweite wichtige Komponente, das ist der Manager, der verwaltet halt die Daten, also der ist dafür da, die Daten zu importieren, dass man sie suchen kann, man kann sie wieder auch exportieren, man kann sie auch ändern innerhalb der Datenhaltung.

Und auch da gibt es entsprechende Schnittstellen, also wieder eine Oberfläche, eine Restschnittstelle und ein Kommando-Zeilen-Interface. Auch hier passiert etwas, nämlich hier werden eben die Daten, Expan-GML, in die Datenhaltung eingespielt. Da muss auch ein bisschen was passieren und auch hier sind diese Prozesse CPU- und Speicher-intensiv.

Nur damit wir nochmal gesehen haben, so sieht die Oberfläche des Expan-Managers aus. Also man sieht alle Pläne, die man schon ins System importiert hat, nach Planversion, nach Rechtsstand oder so sortiert, wie man es gerade möchte.

Sind die Plandaten nun in der Datenbank, kann ich sie über WMS und WFS abrufen. Auch hier, ich verweise wieder auf meinen Vorredner, haben wir ja gesehen, es gibt verschiedene, unterschiedliche, den SYN-WFS, den WFS, der halt Expan-GML versionspezifisch das Schema konform ausliefert oder in einem von uns ausgedachten Format den sogenannten SYN-Schema.

Zusätzlich eben noch die WMS-Dünste und, wenn man das möchte, dann noch Inspire PLU. Das Ganze ist Open Source seit Mai 2022 auf der Open-Code-Plattform. Das ist also eine Plattform, eine Austauschplattform, ähnlich wie GitHub, Bitbucket oder andere Plattformen,

aber von dem BMI für die deutsche Verwaltung geschaffen, also der richtige Ort, um halt so eine Software, die für die Verwaltung ist. Denn das muss man sagen, ich privat brauche X-Planung nicht. Das ist leider so, mich interessiert das privat auch gar nicht, aber ich bin irgendwie da involviert.

So, das kann man unter der Adresse sich angucken und den Quellcode studieren, ausprobieren, runterladen, kompilieren und zum Laufen bringen. So, jetzt kommen wir zu der Frage, und X-Planbox, wie sieht es aus mit der Cloud? Cloud, da würde ich sagen, haben wir heute Morgen schon einen Vortrag zugehört.

Da will ich jetzt auch nicht wieder ins Detail gehen, da schwirren immer so Begriffe, Platform as a Service, Infrastructure as a Service, da haben wir alle irgendwelche Bilder schon vor Augen. Wir wissen, was gemeint ist, und wenn wir über die X-Planbox reden, dann reden wir natürlich über Software as a Service, wenn überhaupt. Das ist aber jetzt nicht mein Thema, ich möchte euch zeigen, was wir da so in Detail machen.

Aber dazu gehören noch viele andere Themen, nämlich dazu gehört die Entwicklung der Software, also Development and Operations, der Betrieb der Software, auch da haben wir mal gehört, die Software, kleiner Spoiler, also ist cloudfähig schon, denn sie läuft in Kubernetes Umgebung,

aber dazu gehören auch Themen wie Monitoring und Security, und die Software muss dafür fit gemacht werden. Und warum das nicht ganz so einfach ist, hat ich schon eingangs erwähnt, die Software hat eine Historie, sie ist nämlich verdammt alt. Bevor ich weiter über Cloud rede, kurz mal so eine für mich Begriffsdefinition, was heißt eigentlich Cloud Ready oder Cloud Enabled?

Das bezeichnet einfach erstmal, dass eine Software, die nicht für die Cloud original entwickelt wurde, dazu schrittweise fit gemacht wird, dass sie in der Cloud-Infrastruktur läuft. Exakt das ist die Situation bei unserer Software gewesen, dagegen unterscheidet man sogenannte Cloud-Native oder Cloud-Born,

wenn man sagen, die sind schon als sowas geboren worden, die sind dann schon gleich so entwickelt worden, dass sie auf entsprechenden Cloud-Infrastrukturen laufen. Und die Situation liegt eben bei der Xpermox ganz offensichtlich auf der Hand, sie ist alt und hat eine Historie und war halt nicht Cloud-Native.

Was sind da die Herausforderungen, wenn man so eine Altaanwendung, und das muss man sagen, eigentlich ein klassischer Monolith, ein riesen Brocken, plötzlich Microservices, das macht man nicht über Nacht, und da sind so einige Probleme drin.

Ganz klare Probleme, an denen wir jetzt gearbeitet haben, sind erstmal drei Bereiche. Erstens die Datenhaltung. In der Vergangenheit immer alles schön ins Datei-System reingeschrieben. Das ist super, unter den meisten Betriebssystemen machen wir genau das, da liegen alle meine Dateien, meine Musikdateien, meine Office-Dokumente,

aber in der Cloud, nicht so eine gute Idee. Also da muss ich weg von der lokalen Datei-Ablage hin zu einer Alternative. Was bietet mir die Cloud da? Da nutze ich dann Platform as a Service, Angebote, zum Beispiel wie ein Objektspeicher, AWS bietet sowas wie S3 dann an.

Aber auch bei der Ressourcen-Zuteilung muss ich den Code oder die Anwendung anders betrachten, denn statt CPU und Arbeitsspeicher in der Vergangenheit fix zuzuordnen, das muss on-demand passieren, das muss flexibel werden, da muss ich auch wieder was dran tun.

Das ist also das Thema Skalierung, nämlich auf Bedarf entsprechende Ressourcen bereitzustellen. Und was sind denn so die Bedarfe? Wo knallt es gerade oder wo knallt die Software? Das sind die B-Pläne. Nicht, sondern die anderen Pläne.

In der Entwicklung der Software haben wir, ich sage mal, neun von zehn Plänen waren in der Vergangenheit B-Pläne. Die waren einfach als erste da, die haben wir als Testdaten genommen. Die sind einfach, die sind klein, die sind meistens eher im kleineren, einstelligen Megabyte-Bereich und können mit dem Validator und dem Manager ruckizuck, sage ich mal, verarbeitet werden.

Also das schmerzt noch nicht, wenige Sekunden, selten mehr. Wenn man aber jetzt einen FNP-Plan anschleppt, den hat man dann vielleicht nur einen von zehn oder vielleicht einen von 100, man muss sich das nur vorstellen, selbst große Städte wie Hamburg, die haben 3500 B-Pläne und nur einen Flächennutzungsplan,

dann waren die Testdaten einfach so verteilt. Und so ist die Software auch entwickelt worden. So ein FNP, der ist manchmal mehr, also eher im zweistelligen Bereich schon ein bisschen größer und der dauert. Das liegt einfach auch, kann man auch sagen, an der Programmierung, nämlich wie semantisch, syntaktisch, geometrische Validierungen passieren.

So in letzter Zeit sind aber auch Regionalpläne dazugekommen und die wären mal gerne so 100 Megabyte groß und das sind große Probleme, die müssen wir verarbeiten können, aber mit unserem bisherigen Ansatz wird das sehr, sehr schwierig, weil wir eben bei großen Planwerken dann so verdammt lange brauchen, dass uns die

IT, also der Betrieb sagt, 30 Minuten für ein Request, da fliegt ihr raus. Also, was stand an? Kurzer Blick in die Vergangenheit. Als die Software entwickelt wurde, warum ist sie so, wie sie ist,

haben wir das Ganze auf Windows oder Linux-Servern zur Ausführung gebracht und ein Dateisystem, eine Datenbank. Das sah sehr übersichtlich aus, so war die erste Version, 2005, Xpambox, ganz übersichtlich. In den darauffolgenden Versionen haben wir die Anzahl der Tomcat-Server, also der JVMs erhöht, um mehr Speicher den einzelnen Komponenten zuzuweisen.

Also wir haben versucht, eine Skalierung zu machen, aber das war auch noch nicht so der Hit. Das war dann so die 2014, 2019 die Version und wir haben dann wiederum daran gearbeitet,

noch mehr wieder die einzelnen Web-Apps zu zerlegen und waren aber immer noch erstens daran festgehalten, dass wir ein Dateisystem hatten, wir hatten immer noch eine Single Application Database, konnten dann aber, weil jetzt schon die, wir werden es gleich sehen, kommt ein schönes Wimmelbild,

die Komponenten zu viele wurden, um das einfach mal so schnell per Hand zu installieren, denn das war schon ein bisschen mehr. Da haben wir dann Docker Compose genutzt, aber immer noch ein Dateisystem und die Datenbank. Der nächste Schritt und da sind wir heute erst, jetzt ist sie so langsam cloud-ready,

können wir eben die Software in der Kubernetes-Umgebung als Services laufen lassen. Wir haben mittlerweile zwölf Service-Container, wir haben mehrere sogenannte Sidecasts, die dafür da sind, Datenbank und andere Initialisierung oder auch Aktualisierungsschritte durchführen zu können.

Wir bleiben immer noch bei einer Application Database, das haben wir noch nicht abgeschafft, das ist aber auch in der Mache, aber sie kann jetzt managed sein, das heißt, es kann auch wieder eine PaaS-Software sein, also nicht etwas, was wir installieren oder was der Betreiber installiert, sondern was genutzt werden kann bei Azure, wo auch immer es läuft.

Und wir sind das Dateisystem endlich losgeworden, die kompletten Datenhaltung erfolgt über einen Objektspeicher, das kann S3 sein, was sowas wie der De facto-Standard da ist.

Hier ein kurzes Bild, um mal so eine Idee zu bekommen, was das eigentlich bedeutet. Das andere Bild konnte ich da nicht mehr einbringen, das wäre zu viel geworden. Also was wir geschafft haben, ist jetzt erst mal hier die Raster- und die Vektor-Datenhaltung erst mal so zu abstrahieren, dass wir darunter eine Infrastruktur nutzen können, wo wir eben Cloud-Services nutzen können.

Also das heißt, sie ist jetzt in der Cloud. Sie kann dort betrieben werden, zum Beispiel eben auf Kubernetes erfolgt das heute. Was wir jetzt sozusagen angehen, und das ist auch ein bisschen die Warnung für all diejenigen, die jetzt sagen, ah, habt ihr einen Dienstleister gehabt, der euch bei der Installation geholfen hat.

Das ist sozusagen der falsche Ansatz. Es geht hier nicht um Handarbeit, sondern es geht alles um Vollautomatisierung. Das ist die Geschichte. Nicht irgendwie ein Dienstleister, der hier schwere Arbeit machen muss, sondern wir wollen es vollautomatisieren. Das heißt, ausrauen, automatisch. Wir haben jetzt für die Entwicklung, nutzen wir Minikube, um die Software auch bei uns

sehr nah an dem Kubernetes-Cluster lokal testen zu können. Wir haben eigentlich an den Komponenten und an den Ports haben wir jetzt erstmal nicht viel gemacht, aber jetzt geht es sozusagen ans Herz, nämlich die Zerlegung des alten Monolithen für die Validierung und für den Import der Daten, dadurch dass wir eine Q-Komponente einführen werden,

mit denen halt erstmal in den Schnittstellen asynchrone Kommunikation unterstützt wird und dann innerhalb der Anwendung auch asynchron kommuniziert wird. Das heißt, wir zerlegen jetzt, also diesen alten großen Monolithen, immer mehr in weitere kleine Teile. Jetzt kommt ein Wimmelbild, das ist einfach nur dafür da, dass es bunt ist, ist ein Entwurf,

ist eine Diskussionsstand und soll einfach zeigen, welche Auswirkungen genau dieser Schritt hat, nämlich jetzt, um Umbau zu machen, weg von gedachter Applikationskomponenten, die alle irgendwie auf eine Datenbank zugreifen, nämlich hin zu einer verteilten

wirklich Microservice-Architektur, die es ermöglicht, auch andere Komponenten zu integrieren, nämlich über eine Q und dadurch Erweiterungspunkte zu schaffen, die es uns dann ermöglichen, auch schwere, harte Arbeit, wie zum Beispiel eben die Validierung so auszulagern,

dass halt kleine B-Pläne, die laufen einfach durch, aber wenn so ein Regionalplan kommt, nicht dann alle anderen Validierungsprozesse erst mal für eine halbe Stunde stillstehen. Das wollen wir nicht. Also das erst wird uns das ermöglichen, dass wir auch diese nicht-funktionalen Anforderungen dann erfüllen können.

Und somit beantworte ich die von mir selber gestellte Frage, ist die Xpambox ready für die Cloud? Ja, sie ist es heute schon in der Version 7, aber in der Version 8 werden ganz entscheidende Dinge denn noch dazu kommen. Wir haben also gesehen, aus einer alten, sehr monolithisch entwickelten Software

konnte über mehrere Schritte eine Cloud-Fähigkeit hergestellt werden. Wir sind dabei, den Xpam Malidator die Performance zu verbessern. Das ist möglich, das geht. Wir haben aber weiterhin große Herausforderungen im Bereich der Skalierung, vor allem der horizontalen Skalierung.

Wir müssen weg. Es gibt noch einige sogenannte Singleton-Container. Da darf es immer nur einen geben, nicht mehrere. Und da müssen wir weg von. Und dann ist sozusagen das Versprechen, dass die Software erst mal nicht funktional die Anforderungen erfüllt.

Auch große Planwerke, Regionalpläne von mehreren, 100 MB schnell und performant, ohne zu crashen, verarbeiten zu können, dann hoffentlich hergestellt. Was das aber auf der anderen Seite bedeutet und damit nochmal Bezug auf die Aussage, brauche ich einen Dienstleister jetzt für die Xpam Box? Nö, braucht man nicht. Man braucht aber eine entsprechende Infrastruktur, also man sollte nicht mehr auf die Idee kommen.

Und ich weiß, es laufen noch irgendwo Xpam Boxen noch auf Windows- oder Linux-Servern, die per Hand installiert wurden. Davor würde ich jetzt sozusagen Abstand raten, mach das nicht mehr. Nutzt sowas wie Kubernetes, nutzt solche Infrastrukturen, dafür wird die Software weiterentwickelt.

Und all diejenigen, die noch so einen schönen Windows-Server haben oder so einen Linux-Server, die sollten dann sich überlegen, da vielleicht was anderes drüber zu legen. Damit geht es dann auch. Und dann gibt es, wie gesagt, viele Automatismen im Bereich DevOps, die da mit hinzugehören

und die es ermöglichen, auch die Software selber zu installieren. Somit würde ich sagen, für mich ist Mission irgendwie angekommen. Ja, sie ist cloud ready, aber es ist noch viel zu tun. Damit war es und vielen Dank. Ja, danke Thorsten. Ich glaube, du hast alles vollumfänglich erklärt.

Es gibt keine Fragen im Renewless. Gibt es denn hier direkt Fragen aus dem Publikum? Da hinten, da gibt es eine. Dann müssten wir mal ein Mikrofon durchreichen, warte es noch kurz.

Ja, also das, was ich mich gefragt habe jetzt gerade, diese Prozesse, die so lange dauern bei großen Planwerken, das ist doch eigentlich nur beim Import oder nicht? Ich importiere einen Landschaftsplan in die X-Plan-Box und das dauert dann 30 Minuten.

Kann ich mitleben, würde ich meinen. Die Dienste, die doch hinter der Bauauskunft sind ja schneller. Die nehmen ja immer nur einen kleinen Ausschnitt. Das ist richtig, genau. Also es sind genau die beiden Prozesse des Validierens und des Imports. Und da, wie gesagt, kommen, das ist dann eine Anforderung aus dem Betrieb, die dann sagen, aber hat die TP-Verbindung, die länger als,

ich weiß jetzt gar nicht mehr, sind es 5 Minuten, 10 Minuten, dauern, die werden gekappt. Und das ist eher die nicht funktionale Anforderung, die aus dem Betrieb rauskommt. Ist das im Produktivsystem dann so gedacht, dass möglicherweise nächtlich solche Pläne aus der Erfassungssoftware herausgeschoben werden

in die X-Plan-Box und diesen Automatismus, den möchte man halt performant hinkriegen, oder? Genau. Gut, danke schön. Soll ich gleich nach hinten geben, genau. Ja, ich habe eine Frage. Im Vorgängervortrag vom kommunalen Rechenzentrum Niederrhein hieß es,

dass die X-Plan-Box keine fachliche Prüfung, nur eine formale, syntaktische Prüfung vornimmt. Sie haben auch von der fachlichen Prüfung gesprochen. Wie verhält es sich damit? Mit der fachlichen meinte ich das Bild, wo man raufgucken kann. Also da weiß ich, liegt die grüne Begrünungsfläche, die Baufläche an der richtigen Stelle.

Das ist die grafische Darstellung. Also es ist nicht alt nur. Da gibt es auch einen guten Artikel bei der Leitstelle. Zudem, was ist das Ergebnis des X-Plan-Validator? Also der X-Plan-Validator der Leitstelle ist die gleiche Software. Und dazu gibt es mehrere zeilen, seitenlange Erklärungen,

wie man dieses Ergebnis eines baliden Plans interpretieren kann. Danke. Gerne. Gut, gibt es noch weitere Fragen? Wenn das nicht so ist, vielen Dank, Thorsten. Und wir sehen uns gleich zum nächsten Vortrag hier wieder.

Perfekt.