Ja, jetzt kommen wir zum letzten Vortrag in diesem Vortragsblock und nicht wie angekündigt geht das hier nochmal um X-Planung, sondern natürlich um Statistik, Kommen Monitor, kommunales Monitoring. Sebastian Drost wird uns das vorstellen von 52 North in Zusammenarbeit mit der Hochschule Bochum.

Und schauen wir mal, was wir hier so spannend zu hören jetzt. Genau, bin ich zu hören, ja. Ja, hallo zusammen, vielen Dank für die Einleitung. Ich möchte Ihnen gerne heute ein Tool vorstellen, was aus einem Forschungsprojekt entstanden ist.

Ein Tool für kommunales Monitoring, mit dem es möglich ist, Geodaten, aber auch statistische Daten auszuwerten, zu analysieren für die Raumplanung in Kommunen. Kurz zum Mai-Mintergrund. Ich bin Softwareentwickler bei der Firma 52° North. Wir haben den Sitz in Münster. Wir sind eine Non-Profit-Organisation.

Das heißt, alles, was wir im Bereich Forschung machen oder Dienstleistungen im Bereich Open Source Softwareentwicklung, kommt auch wieder der Forschung zugute. Wir dürfen per se keine Gewinne machen. Wir machen angewandte Forschung im Bereich der Geoinformatik, sind dort in vielen nationalen und EU-weiten Forschungsprojekten unterwegs und bieten eben Dienstleistungen an im Bereich der Open Source Softwareentwicklung.

Historisch sind wir entstanden aus einer Ausgründung vom Institut für Geoinformatik der Universität in Münster. Man könnte heutzutage sagen, wir sind so eine Art Start-up gewesen, mit dem Ziel, Forschungsergebnisse aus Forschungsprojekten zu verstetigen.

Unsere Tätigkeiten drehen sich rund um das Thema räumliche Daten mit den Kernthemen Geospatial Sensing, Spatial Analytics oder Geoprocessing und sind hier aber sehr querschnittsorientiert unterwegs in verschiedenen Anwendungsfällen. Die Software Commonitor ist entstanden aus einem Forschungsprojekt. Also Commonitor war auch

ein Forschungsprojekt, was jetzt seit knapp einem Jahr, anderthalb Jahren beendet ist. Das Projekt wurde gefördert im Rahmen des Förderprogramms Kommunen Innovativ und das Förderprogramm hatte damals das Ziel, Kommunen und Regionen zu stärken für eine nachhaltige Stadtentwicklung. Hauptsächlich wurden hier Forschungsprojekte gefördert, bei denen Forschungsinstitute zusammen mit Kommunen

gearbeitet haben, um nachhaltige Lösungen für eine nachhaltige Stadtentwicklung zu entwickeln. Die Stadt Essen und die Stadt Mühlheim waren hier kommunale Verbundpartner und die Hochschule Bochum und das Geografische Institut an der RUB waren hier die Forschungsentwicklungspartner.

Die Hauptentwicklung der Plattform des Tools Commonitor erfolgte an der Hochschule Bochum. Jetzt stellen Sie sich bestimmt die Frage, wie kommen wir als FIFE2N mit da rein? Ja, das Forschungsprojekt ist jetzt seit anderthalb Jahren vorbei. Es hat sich während des Forschungsprojektes schon herausgestellt, dass sehr viele Kommunen Commonitor nutzen wollten.

Unter anderem der Regionalverband Ruhr, der auch schon sehr früh mit dabei war, Kreis Viersen auch aktuell und mein Kollege, der Christian Hanofsky-Buhren an der Hochschule Bochum, der war eben der Hauptentwickler. Und dann war eben die Frage, wie kann man das Projekt, wie kann man das Tool, die Software nachhaltig weiter betreuen? Wir waren ja in der Vergangenheit schon in einigen Forschungsprojekten mit der

Hochschule Bochum unterwegs. Unsere Aufgabe, unser Ziel ist es, Forschungsergebnisse zu verstetigen. Wir haben eben das Know-how auch in der Open-Source-Software -Entwicklung, während demnächst auch eine offizielle Forschungskooperation mit der Hochschule Bochum eingehen. Und deswegen haben wir uns das dann eben zur Aufgabe gemacht, Commonitor weiter professionell zu

betreuen, indem wir eben interessierte Kommunen anbieten, die Software zu installieren, zu hosten, Support anbieten. Aber eben auch je nachdem, wie die Bedarfe gerade sind, auch neue Funktionen weiterentwickeln. Worum dreht sich jetzt die Software Commonitor an? Fokus des Projektes waren stets die Verantwortung von räumlichen Fragestellungen, Problemfragen, wie sie häufig in Kommunen auftreten.

Das alles wirklich querschnittsorientiert. Also Themen zu Gesundheit und Umwelt in Kommunen. Wo kann unsere Stadt grüner werden? Wo sind vielleicht Versorgungsendpässe bezüglich der Gesundheitsversorgung? Wo gibt es schlechte Anbindungen bezüglich des ÖPNVs?

Also das sind alles räumliche Problemfragen, mit denen sich Fachabteilungen, Raumplaner in Kommunen auseinandersetzen müssen. Und Abhilfe kann hier dann eben ein Monitoring-System bieten, was zum einen Geodaten, also räumliche Daten, visualisiert. Und diese Daten aber gleichzeitig auch mit klassischen statistischen Zeitreiendaten eben

zu bestimmten Themen aus einer Kommune miteinander kombiniert und analysieren kann. Und so ein Monitoring-System sollte dann eben für die Fachplaner, für die Fachexperten in den Kommunen möglichst Analysen auf Knopfdruck liefern. Also leichten Einstieg, leicht und intuitiv zu bedienen.

Und das können kombinierte Monitoring-Systeme schaffen. Und das ist auch die Projektidee hinter der Software Co-Monitor gewesen. Ein Ziel war es, das Beste aus den beiden giss und statistischen Analysen zu vereinen, indem eben zum einen Geodaten kombiniert mit statistischen Zeitreiendaten kombiniert analysiert werden könnten.

In Zentrum stehen natürlich immer noch giss, also die kartografische Darstellung von der räumlichen Daten. Das aber eben angereichert durch klassische statistische Diagramme, wie sie eben durch Raumplaner, Städteplaner oder Sozialplaner verwendet werden.

Wir haben auf der einen Seite eben giss-Software, da stehen dann eben räumliche Daten. Bevor es Co-Monitor gab, gab es klassische giss-Anwendungen, wie sie häufig in Kommunen verwendet werden, QGIS. Da stehen eben Geodaten im Fokus. Auf der anderen Seite gab es Fachanwendungen, die häufig dann eben von Raumplanern verwendet wurden und die statistische Analysen angeboten haben und auch schon umgesetzt haben.

Das Problem war eben, dass es keine Kombination dieser beiden Welten gab und das hat sich dann Co-Monitor zum Ziel gemacht, indem es eben möglich ist, auch Analysen auf variablen Betrachtungsebenen, auf variablen Raumebenen anzubieten.

Das Ganze sollte intuitiv und browsergestützt sein und natürlich dann eben auch eine Open-Source -Wendung werden, da viele Fachanwendungen, wie sie vorher schon existiert haben, teilweise eben kommerziell sind. Und deswegen sollte Co-Monitor hier wirklich dann eine Open-Source-Lösung für Kommunen bieten, eben ein kommunales Monitoring-System für Verwaltung, Politik und Bürger.

Das Thema variabler Raumbezug ist, damit ist gemeint, dass eben die Analysen, die Co -Monitor bieten soll, die das Monitoring bieten soll, eben auf unterschiedlichen Raumebenen erfolgen kann. Hier jetzt mal das Beispiel von der Stadt Essen. Also wenn ich Analysen mache zu bestimmten Thematiken, etwa Gesundheitsversorgung, dann sollte das nicht nur auf

einer bestimmten Raumebene erfolgen, sondern auf Knopfdruck eben auch für verschiedene oder für unterschiedliche Raumebene möglich sein. Das können Stadtbezirke sein, das können Stadtteile sein, Stadtviertel oder auch wirklich sehr kleinräumig auf Wohnviertel-Ebene. Also je nachdem, wo gerade die Anforderungen der Raumplaner und Städteplaner sind.

Co-Monitor ist eingebettet in einem Indikatoren-Framework. Indikatoren kann man verstehen als Zeigerwerte, mit denen bestimmte Zustände oder Prozesse in Kommunen quantitativ bewertet werden können. Ein Beispiel, die quantitative Bewertung etwa der Gesundheitsversorge in Wohnvierteln könnte zum Beispiel

durch den Indikator fußläufige Erreichbarkeit von Arztpraxen innerhalb von 15 Minuten erreicht werden. Das ist so ein klassischer messbarer Indikator, den man verwenden kann. Das Indikatoren-System, das Framework, ist hierarchisch angeordnet.

Auf der untersten Ebene haben wir die Basisdaten, das sind beliebige Sachdaten, die in den Kommunen vorliegen. Einwohnerdaten oder Geobasisdaten. Und mit diesen sehr vielfältigen Daten, zahlweise eben auch Zeitreinendaten, können Indikatoren abgeleitet werden. Durch Verschneidung, durch Klassifizierung von Daten. Indem man eben diese Sachdaten, diese reinen Anach-Informationen durch Berechnungsvorschriften bewertbar macht.

Quantitative Indikatoren eben. Dann lassen sich diese einfachen Indikatoren noch zu höherwertigen Indikatoren ableiten oder zusammenfassen zu sogenannten Leitindikatoren. Diese Leitindikatoren, das sind dann Indikatoren, die eine bestimmte Problemstellung oder eine Fragestellung beantworten sollen.

Zum Beispiel das Thema Attraktivität von Wohnvierteln für übende Familien. Indem man jetzt verschiedene Indikatoren, zum Beispiel Erreichbarkeit von Kindergärten, Erreichbarkeit von Grundschulen, Freiflächen miteinander kombiniert.

Und das dann eben zu einem höherwertigen Indikator diese Attraktivität aggregiert. Daneben gibt es noch themfeldübergreifende Entscheidungstools, die im Prinzip alle Indikatoren abdecken und auch Berechnungsergebnisse liefern. Mit denen weiter Indikatoren abgedeckt werden können, wie zum Beispiel Erreichbarkeitsanalysen.

Das sind so klassische Tools, die ebenfalls in so einem Monitoring-System abgedeckt werden sollten. Hier mal so ein Beispiel, wie so ein Indikatoren-System aussehen kann. Also klassischerweise nehmen wir hier das Beispiel des Themas Umwelt und Gesundheit.

Die haben wir dann als Rohdaten, beispielsweise Sensordaten, wie sie vielleicht in manchen Kommunen erfasst werden. Also Feinstaubwerte, Ozonwerte und so weiter, beliebige Sensordatenwerte. Das sind Rohdaten und diese Daten können nun verwendet werden, um Indikatoren abzuleiten. Etwa Gesundheitsrisiken durch Feinstaub, Gesundheitsrisiken durch Ozon, durch Klassifizierung oder eben durch andere Berechnungsvorschriften.

So kann man das immer weiter aggregieren, indem man dann diese einzelnen Indikatoren, diese Subindikatoren immer weiter zusammenfasst und einem übergeordneten Themenfeld dann eben zuordnet. Bis hin dann eben dem Leibindikator Gesundheitsrisiken der Bevölkerung dann zum Beispiel.

Und dieses Indikatoren-Framework ist jetzt eben nicht nur auf ein Themenfeld beschränkt. Wir sehen es hier, wir haben hier verschiedene Themenfelder, Wasser, Mobilität, Umwelt und Gesundheit. Also das, was gerade eben bei den Kommunen gefragt ist, kann durch das Indikatoren-System, durch dieses Framework abgedeckt werden. Also wir sind da sehr variabel unterwegs.

Ja, hier mal so ein Beispiel, wie das jetzt in der Praxis aussehen würde. Das ist das Beispiel aus der Stadt Essen. Wir haben verschiedene Subindikatoren. Ich greife nochmal das Beispiel auf der Attraktivität für Familien könnte jetzt zum Beispiel abgedeckt werden, eben durch die Erreichbarkeit von Kitas, Erreichbarkeit von Spielplätzen, Erreichbarkeit von Grundschulen oder Erreichbarkeit von Supermärkten.

Das heißt, wir haben Subindikatoren, verschiedene Subindikatoren und diese Subindikatoren können nun zusammengefasst werden. Einfaches Beispiel ist durch ein einfaches, gewichtetes Mittel. Diese Daten, diese vier verschiedenen Subindikatoren werden dadurch zusammengefügt und so entsteht dann ein Leitindikator für die jeweilige Raumebene.

Hier in diesem Fall sind das glaube ich Stadtteile oder Wohnbezirke in Essen. Schauen wir uns an, wie wir das umgesetzt haben. Bevor wir uns anschauen, wie das Frontend aussieht, möchte ich so ein bisschen auf die Architektur eingehen, aus welchen Komponenten unser System besteht.

Das, was der User normalerweise sieht, ist eben der Webclient, also das gesamte System und die Analysen können über einen Browser aufgerufen werden und das ist das, womit der User arbeitet, aber dahinter steckt noch eine ganze Menge an anderen Komponenten. Wir haben eine serviceorientierte Architektur, besteht also aus verschiedenen Komponenten und diese Komponenten zusammen betrachtet.

Wir verwenden auch bereits bestehende Softwarelösungen, etwa Open-Route-Service für Erreichbarkeitsanalysen oder Geo-Server. Und alles zusammengenommen kann man als so eine Art kleine Geodateninfrastruktur betrachten. Also wir haben auf der untersten Ebene haben wir so die Datenverwaltung,

Ressourcenverwaltung, indem wir Daten aus den Kommunen eben in das Commonitor Schema bringen. Das sind Geodaten etwa für Raumeinheiten oder eben die zeitreihenbasierten Indikatordaten. Dann haben wir auf der mittleren Ebene unsere Prozessierungsdienste für die Berechnung eben von Geodaten oder für andere Geodatenprozessierungen.

Das können beliebige Dinge sein. Und auf der obersten Ebene eben die darstellungen, webbasierte Darstellung mit Auswertungstools. Und alles zusammen ist dann eben oder bildet dann so eine Art Entscheidungsunterstützungssystem eben für Anwender aus der Stadtentwicklung. Also alles zusammen bildet dann unser Monitoring-System.

Gucken wir uns die einzelnen Ebenen nochmal an. Also auf unterster Ebene haben wir eben die Ressourcenverwaltung, das ist das Kernstück unseres Systems. Wir haben dort eine Data Management API, eine REST basierte API, mit dem dann die Geodaten und Fachdaten verwaltet werden können. Nun möchte natürlich nicht jeder mit so einer REST API arbeiten, um bestehende Daten in unser System zu bekommen.

Deswegen gibt es zusätzlich noch eine Importer-API, mit der beliebige Datenformate und Datenquellen angebunden werden können. Klassischerweise eben GeoJSON oder WFS-Dienste, aber eben auch CSV-Dateien, in denen häufigerweise dann eben Indikatorzeitreihen vorliegen. Wir haben bestimmte Datenformate bereits angebunden, wir haben Importer dafür geschrieben, aber die Importer-API ist relativ generisch gehalten.

Das heißt, wenn Kommunen bestimmte Anwendungsfälle haben, bestimmte Datenformate haben, dann können hierfür diese Importer-API weiterentwickelt werden und angepasst werden. In der mittleren Ebene dann eben unsere Prozessierungsdienste gebildet durch eine Processing Engine,

mit der eben neue Indikatoren aus vorhandenen Fachdaten berechnet werden können, abgeleitet werden können. Das sind eben diese Indikatorberechnungen, diese Beispiele, die ich eben gerade genannt hatte, indem eben aus einfachen Basisdaten, zum Beispiel Sensordaten oder einfach Bevölkerungsentwicklungsdaten, neue Indikatoren abgeleitet werden können.

Das Ganze kann automatisiert werden durch einen Processing Scheduler, der automatisiert eben vorhandene Indikatoren fortführen kann. Indem eben geschaut wird, liegen in irgendeinem Bereich neue Daten vor, neue Fachdaten vor, gibt es neue Zeitschritte und dann werden vorhandene Indikatoren, die auf diesen Daten basieren, eben automatisch fortgeschrieben.

Das heißt, hier ist keine manuelle Interaktion notwendig. Vervollständig wird das Ganze durch einen Open-Route-Service, das ist eine vorhandene Lösung, die wir hier nutzen, um Erreichbarkeiten ermitteln zu können. Und ganz oben aufgesetzt gibt es dann unsere Dienste und Anwendungen für Analyse und Darstellung der Daten.

Benutzernsschnittstelle ist ein Webclient. Im Fokus steht hier die kartografische Darstellung der Geodaten, angereichert eben mit Diagrammen für die Analyse von Geodaten und statistischen Daten.

Daneben gibt es noch so eine kleine Config-Komponente, mit der dieser Webclient dann eben auch vom Aussehen her angepasst werden kann. Optional ist, dass dann noch Geo-Servers angeboten werden, also es könnte noch ein Geo-Server daneben betrieben werden, in dem alle Daten, die im Comunitor vorliegen, Indikatordaten, Zeitreindaten, dann eben auch nochmal als interoperable Geodienste bereitgestellt werden, etwa zur Anwendung in QGIS, Darstellung in QGIS.

Dann hatten wir von Anfang an auch schon die Anforderung der Umsetzung eines Rollenmodells, weil eben Daten, die in einer Kommune vorliegen, aus verschiedenen Fachabteilungen kommen, nicht unbedingt auch jedem zugänglich gemacht werden sollen.

Es gibt da immer noch teilweise eben das Konkurrenzdenken, dass eine Fachabteilung sagt, die Daten, die wir verwalten, soll jetzt die andere Fachabteilung nicht sehen. Deswegen mussten wir uns überlegen, wie wir das Nutzer- und Rollenmodell umsetzen können. Wir nutzen hierfür KeyClock, um eben die Zugriffskontrolle umzusetzen.

KeyClock bietet eben Möglichkeiten der Authentifizierung. Wir können Rollen vergeben an die Nutzer, und wir haben so eine Art organisationsspezifische Zugriffskontrolle eben umgesetzt, mit der so ein Organigram aus einer Kommune eben auch umgesetzt werden kann, in dem den Nutzern eben organisations- oder fachbereichsspezifische Rollen zugewiesen werden kann und somit ist sichergestellt, dass

diejenigen, die bestimmte Daten sehen, auch nur diese Daten sehen und nicht andere aus anderen Abteilungen zum Beispiel. Hier mal diese Folie zu verdeutlichen, was wir alles an Open Source Frameworks und Tools verwendet haben. Natürlich so klassisch die Entwicklungsframeworks Spring Boot oder Angular oder Bootstrap.

Aber wir haben ja auch eine ganze Reihe an Giz-Frameworks verwendet und Giz-Tools verwendet, Leaflet at Love für die webbasierte Darstellung, kartographische Darstellung, Geotools, womit wir in Java die Geoprozessierungen implementiert haben. Oder Terf, kennt vielleicht auch der ein oder andere. Terf ist eine Bibliothek, mit der dann in

Node.js dann eben Geoprozessierungsroutinen umgesetzt werden können. Also wir haben hier eine ganze Vielzahl von Tools verwendet. Bevor ich zum Ende komme, nochmal so ein paar Einblicke in unserer Software, wie das Tool aussieht. Das ist so die Startseite, wenn man Community aufruft.

Man sieht schon, hier ist die kartographische Darstellung eines bestimmten Raumgebietes dann eben im Vordergrund. Hier jetzt dargestellt die Stadtteile der Stadt Essen und per Default ausgewählt dann auch immer ein bestimmter Indikator. Wir haben jetzt hier den Indikator Einwohner, genau Bevölkerung, Einwohner in den Stadtteilen. Das ist aber

jetzt beliebig wechselbar, indem man jetzt sagen kann, okay, ich interessiere mich jetzt nicht für die Einwohner in Stadtteilen, sondern für die Einwohner in Wohnbezirken und kann dann die Raumebene eben wechseln. Daneben dann ganz klassische statistische Diagramme, die die meisten kennen, Verteilungsdiagramme oder Zeitreihen-Diagramme, etwa um die

Entwicklung der Bevölkerung oder beliebigen Indikatoren dann in den Stadtteilen zu visualisieren und miteinander vergleichen zu können. Oder ein Indikatorenradar, auch nochmal zu Vergleich von mehreren Indikatoren, gleichzeitig wie die Ausprägung mehrer Indikatoren in verschiedenen Stadtteilen vorliegt.

Erreichbarkeitsanalysen können durchgeführt werden über die Anwendung, indem man sagt, okay, wie liegt jetzt die Erreichbarkeit, fußläufige Erreichbarkeit etwa aus zu bestimmten Infrastruktureinrichtungen, Praxen können das sein, Supermärkte, wirklich beliebige POIs.

Das Ganze kann man auch nochmal umkehren, indem man sagt, okay, ich definiere mir jetzt ein beliebiges Einzugsgebiet und schaue dann, wie viele Arztpraxen oder beliebige POIs ich denn jetzt zum Beispiel innerhalb von zehn Minuten per Fahrrad erreichen kann. Das kann dann eben geschaut werden, wenn wirklich die Fragestellung auftritt, wo möchte ich jetzt hinziehen in

eine Kommune, dann kann ich mir mein Einzugsgebiet definieren und dann eben schauen, okay, ich habe jetzt den Anspruch, möglichst viele Kindertagesstätten zu Fuß zu erreichen und kann diese Analysen dann eben mit Comunitor dann durchführen. Wir haben außerdem ein templatebasiertes Reporting implementiert, oftmals besteht die Anforderung, dass man mal eben schnell Analysen, Auswertungen

eben mitnehmen muss in einen Ausschuss, das kann man hier drüber machen, indem automatisiert dann bestimmte Dinge erstellt werden. Es gibt ein Management-Dashboard, grobe Übersicht über alle möglichen Daten, die bei uns verwaltet werden und die Möglichkeit dann eben auch Daten anzulegen, indem hier Daten registriert werden können, Metadaten verwaltet

werden können, aber auch eben neue Prozessierungen angestoßen und definiert werden können, wenn neue Indikatoren berechnet werden sollen. Ja, das war es auch fast schon, hier nochmal so eine Folie, wo man Infos zu Comunitor herbekommt, falls der eine oder andere interessiert

ist. Es gibt eine Website Comunitor.de mit einem Forum, unser Quellcode steht bei GitHub, dort ist auch ein Wiki mit allen möglichen Informationen. Sie können auch auf uns oder die Hochschule Bochum zukommen, wenn Sie Fragen zu Comunitor haben, wenn Sie Comunitor installiert haben wollen und Selbstlernkurse sind in Planung.

Diese Kurse sind dann in Form von Videotutorials aufbereitet. Es gibt ja eine Plattform demnächst und dort kann jeder dann eben sich selber Informationen dann zu Comunitor holen. Wenn Sie noch weitere Fragen haben, dann gerne jetzt oder an unserem Stand draußen, wenn Sie

rauskommen direkt rechts, da kann ich Ihnen auch eine kurze Live-Demo zu Comunitor zeigen. Vielen Dank. Ja, Dankeschön für den interessanten Vortrag. Es gibt auch Fragen im Chat. Die erste Frage ist, zahlreiche Kommunen und Statistikstellen nutzen den schwerfälligen und kostenpflichtigen Instant Atlas.

Können Sie sagen, inwiefern der durch den Comunitor abgelöst werden könnte? Der Instant Atlas ist bekannt. Ich bin mir gerade gar nicht mehr sicher, bei wem der Instant Atlas jetzt gerade in Verantwortung liegt.

Ich habe von der einen oder anderen Kommune auch gehört, dass der Instant Atlas nicht mehr ganz so gepflegt wird und unser Ziel ist es im Prinzip, eine Alternative zum Instant Atlas zu bieten, der eben auch langfristig gepflegt wird und eben auch eine Open Source Alternative bietet, weil der Instant Atlas ist nicht Open Source.

Die nächste Frage ist der Webclient. Ist das eine Eigenprogrammierung oder geht das auf irgendwelche anderen Tools zurück? Nein, der Webclient ist eine Eigenprogrammierung. Wir nutzen hier natürlich verschiedene Frameworks und Bibliotheken, Leaflet eben für die kartografische Darstellung, E-Charts für die Diagramme, aber im Prinzip ist es eine komplette Eigenprogrammierung.

Und dann gibt es noch eine dritte Frage, nämlich ob die Nutzer die Möglichkeit haben, Farben und Symbolisierungen zu ändern. Zum Teil. Es gibt Konfigurationsarteien bzw. es gibt auch einen Web-Service, der die Konfiguration bereitstellt.

Hier können bestimmte Farbgebungen auch angepasst werden, das aber im Vorfeld nicht on the fly, das ist aber eine Anforderung, die wir schon von verschiedenen Kommunen auch bekommen haben und was wir für die Feature-Entwicklung jetzt eben auch auf unserer Agenda haben und demnächst auch umsetzen werden. Okay, gibt es noch weitere Fragen aus dem Publikum hier?

Ja, meine Frage bezieht sich auf die Indikatoren. Du hast ja gezeigt, dass aus den Rotdaten Indikatoren berechnet werden.

Meine Frage ist, passiert das on the fly oder werden die vorberechnet? Ich stelle mir speziell für diese einzelnen Raubeinheiten eventuell schwierig vor, das on the fly immer zu berechnen, weil da doch immer verschiedene Aspekte reingehen müssen. Also Frage, sind die vorberechnet und werden dann nur angezeigt oder werden die tatsächlich immer on the fly aus den Rotdaten berechnet?

Ja, danke schön für die Frage. On the fly nicht, also diese Indikatoren müssen vorberechnet werden. Das heißt, wenn sie die Rotdaten haben, dann müssen daraus dann die Indikatoren schon berechnet werden oder sie bringen die Rotdaten dann eben ins System und definieren dann ihre eigenen Berechnungsvorschriften. Also wir haben eben diese Processing Engine, mit der können dann eben beliebige Berechnungsvorschriften umgesetzt werden.

Es gibt da eine Vielzahl von bereits implementierten Berechnungen. Das ist aber eben so gestaltet, dass sie auch ein eigenes kleines Java-Skript schreiben könnten, um ihre eigene Berechnungsvorschrift dann eben umzusetzen.

Aber on the fly ist das eben nicht. Wenn diese Berechnungsvorschrift umgesetzt wurde, dann wird sie eben ausgeführt. Das ist dann auch regelmäßig. Also wenn sich die Grunddaten dann ändern, dann kann es auch automatisch fortgeführt werden. Gibt es noch weitere Fragen? Das scheint nicht der Fall zu sein. Dann vielen Dank für den Vortrag.

Gerne. Noch zur Info. Wer schon öfter auf Afoskis war, weiß sicher, dass wir auch nochmal ein Gruppenfoto machen. Das findet in der Pause heute Nachmittag statt. 15.15 Uhr fängt die glaube ich an. Also in der Nachmittagspause vorne bei den Plakaten, bei den Fahnen draußen wird das Foto gemacht. Bitte alle da sein. Schön frisiert. Rasiert.

Und das Mittagessen aus dem Gesicht gewischt. Und ansonsten wünsche ich Ihnen jetzt eine gute Pause und weiterhin gute Vorträge.