Das NexSIS Projekt: Ein Open-Source GIS für den Zivil- und Katastrophenschutz
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 88 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/56765 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
16
20
32
34
45
46
67
75
78
79
80
85
00:00
Meeting/Interview
01:01
Open sourceSoftwareGeoServerSineWorld Wide WebFeature structureMaximum (disambiguation)DigitizingHigh availabilityInformation systemsScalabilityModularityPostgreSQLRoutingInstallable File SystemConfiguration spaceServer (computing)InternetdienstGeographic information systemFocus (optics)Lösung <Mathematik>Zusammenhang <Mathematik>Route of administrationProcess (computing)InformationDigitizingHigh availabilityConfiguration spaceSystems <München>Web serviceModularitySoftware repositoryComponent-based software engineeringScalabilitySoftwareProduct (category theory)FunktionalitätInternetdienstPoint cloudPostgreSQLBlack boxComputer animation
10:51
InternetdienstServer (computing)RoutingSQLAlgorithmDijkstra's algorithmVerkantungGraph (mathematics)Computer programmingOpen sourcePostgreSQLRouter (computing)Function (mathematics)VelocitySoftware testingAlgorithmModule (mathematics)FRAMEWORK <Programm>Computer programmingComponent-based software engineeringGraph (mathematics)KanteOpen sourceVersion <Informatik>Set (mathematics)Constraint (mathematics)Traffic reportingDiagram
20:22
Open sourceSet (mathematics)JSONXMLMeeting/Interview
21:07
InternetMeeting/Interview
21:51
RoutingSoftware testingMittelungsverfahrenDirection (geometry)PerimeterMeeting/Interview
23:59
High availabilityMeeting/Interview
24:43
AlgorithmEvent-driven programmingCommunications protocolMeeting/Interview
26:56
Meeting/Interview
Transcript: German(auto-generated)
00:07
Ja, hallo und herzlich willkommen zurück aus der Mittagspause hier am Donnerstag auf der Vosges-Konferenz. Hier geht es weiter mit Praxisberichten, tatsächlich viele spannende Themen.
00:22
Wir starten hier gleich mit Andreas Jobst und Felix Sommer und haben gerade schon darüber gesprochen, ob wir das brauchen oder nicht, das werden wir dann sehen. Wir hoffen mal, dass es nicht zu viele Katastrophen gibt in nächster Zeit. Auf jeden Fall wird es auf jeden einen spannender Vortrag, das Nexus-Projekt, ein
00:40
Open-Source-Giz für den Zivil- und Katastrophenschutz von Andreas Jobst und Felix Sommer. Und da hören wir jetzt mal gespannt zu. Wenn Sie Fragen haben, wie immer in den Fragen-Tab oben rechts neben Chat, die werden wir dann im Anschluss danach beantworten. Und jetzt wünsche ich Ihnen viel Spaß.
01:07
Hallo, mein Name ist Felix Sommer und ich freue mich euch heute das Projekt Nexus vorstellen zu dürfen, ein Open-Source- Geoinformationssystem für den Zivil- und Katastrophenschutz.
01:21
Wie gesagt, ich heiße Felix Sommer und bin seit ca. neun Monaten bei Camp2Camp als Software-Entwickler in Paris tätig. Kurz noch zu Camp2Camp. Camp2Camp gibt es seit 20 Jahren mit einem großen Fokus auf Open-Source.
01:41
Wir bieten Lösungen in den Bereichen Geospatial, Business und Infrastructure. Wir sind außerdem in Frankreich, Schweiz und Deutschland vertreten. Unser Kunde ist die ANSC, die Agence de Numérique de la Sécurité Civile.
02:04
Sie untersteht dem französischen Innenministerium und ist für den Bau von digitalen Lösungen zuständig. Sie entwickelt in diesem Zusammenhang besonders Lösungen, die die Digitalisierung des Zivilschutzes,
02:21
also Feuerwehr, Polizei und auch Journalierie vorantreiben sollen. Die Nutzung von Open-Source-Modulen steht vor allem im Fokus und wird wo auch immer möglich eingesetzt. Nexus ist bereits das zweite Projekt, an dem die Agentur beteiligt ist und es
02:42
ebenfalls der Fokus auf Open-Source gelegt. In dem Projekt Nexus geht es konkret darum, ein Alert-Management-System zu erstellen. Dabei kann der Anwender Notrufe, die an die 1-8 oder auch 1-1-2 ankommen, entgegennehmen.
03:04
Zusätzlich können Alarme, welche zum Beispiel über eine Smartphone-App oder auch die sozialen Netzwerke kommen, angenommen und bearbeitet werden. Die Informationen aus diesen Anrufen werden dann gespeichert und an das Operation-Management-System
03:21
weitergeleitet. Hier kann der Anwender sich alle verfügbaren Ressourcen ansehen und entscheiden, welche Fahrzeuge mit welchen Personen losgeschickt werden sollen, um diesen Einsatz dann auszuführen. Die Einsatzleitung wird empfangreich von der Feuerwehr übernommen, allerdings
03:43
macht sie das natürlich nicht alleine, sondern muss sich auch mit anderen Einsatzkräften absprechen und kommunizieren. Deswegen soll Nexus auch dabei helfen, dass untereinander die gleiche Sprache gesprochen wird und jeder auf dem gleichen Kenntnisstand des Einsatzes ist.
04:06
Um euch einen kleinen Einblick in das Aussehen und die Funktionalitäten des Produkts zu geben, habe ich euch ein paar Screenshots mitgebracht. Hier sehen wir das Alert-Management-System, in dem die Anrufe angenommen werden können.
04:28
Und hier können sie dann zum Beispiel bearbeitet werden, das heißt der Anwender kann den Ort und die Art des Notfalls angeben, um alle wichtigen Informationen des Anrufers an die Einsatzkräfte weiterleiten zu können.
04:42
Also zum Beispiel auch ob es verletzte Personen gibt und um welche Verletzungen es sich handelt. Wenn dann jetzt so eine Operation geteilt wurde, kann ein Anwender im Operation-Management-System diese Operation in ihrem System sehen und auch auf der Karte nachverfolgen,
05:05
wo wie viele Einsätze gerade stattfinden. Der aktuelle Stand des Einsatzes ist ebenfalls sichtbar und hilft den Anwendern zu wissen, wo es noch etwas zu tun gibt.
05:21
Wenn der Anwender dann eine Operation auswählt, können einzelne Fahrzeuge mit Personen an diesen Einsatzort geschickt werden. Außerdem sind alle bisherigen Informationen und Aktionen ebenfalls einsehbar.
05:40
Nächstes soll die gegenseitige Unterstützung zwischen den Landkreisen deutlich vereinfachen. Momentan ist es nämlich so, dass jeder Landkreis ein eigenes System nutzt und diese Systeme wurden von verschiedenen Firmen erstellt und kommunizieren leider nicht miteinander.
06:00
Dies soll jetzt verändert werden, indem Ressourcen und auch die Prozesse selber vereinheitlicht werden. Dies macht dann aus vielen kleinen Systemen ein einheitliches nationales System. Nächstes soll auch die Werkzeuge modernisieren und digitalisieren sowie die Prozesse automatisieren.
06:26
Somit gibt es neue Möglichkeiten wie das Teilen und Erhalten von Real-Time-Informationen wie zum Beispiel den Standort einzelner Fahrzeuge. Diese Informationen und Nächstes im Allgemeinen sollen dann auch den Anwendern bei der
06:44
Entscheidungsfindung helfen. Um die eben angesprochenen Ziele zu erreichen, müssen einige Herausforderungen gemeistert werden, denn Nächstes ist ein Software-as-a-Service-Informationssystem, welches wirklich Leben
07:02
retten soll. Als Herausforderungen haben wir die Sicherheit und die hohe Verfügbarkeit, da es sich um ein kritisches System handelt und welches auf keinen Fall für ein paar Stunden ausfallen darf. Die Software soll dann natürlich auch modular aufgebaut sein und moderne APIs nutzen.
07:26
Eine große Herausforderung ist es dann auch die Anwendung für bis zu 250.000 gleichzeitig Nutzer zu skalieren, ohne an jeglicher Performance einzubüßen.
07:42
Bereits in der Planung des Projekts war es klar, dass man nicht auf proprietäre Lösungen setzen möchte, da sie in vielen Fällen eine Blackbox sind. Dies wollen wir eben nicht, da die Software sich einfach anpassen und weiterentwickeln lassen soll.
08:01
Somit haben sich Open-Source-Lösungen durchgesetzt, da das meistens die Zwecke sind, zu der sie eben entwickelt wurden, das heißt Modularität und Interoperabilität, dazu wurden sie konzeptiert und deswegen eignen sich diese Art von Lösungen perfekt für
08:23
unser Projekt. Im Bereich Geospatial setzen wir vor allem auf die folgenden Open-Source-Komponenten. Postgres SQL und PG-Routing nutzen wir zur Routenplanung, darauf komme ich später dann auch nochmal zu sprechen.
08:42
Wir nutzen Open-Layers für die Web-Kartografie sowie den Geo-Server, von dem wir eine hohe Verfügbarkeit benötigen. Um diese hohe Verfügbarkeit zu bekommen, können wir uns erstmal den klassischen Geo-Server anschauen.
09:02
Hier wird die Konfiguration im Datalsystem gespeichert und dies kann einem dann vor die Herausforderung stellen, diese Konfiguration in einem Cluster-Betrieb synchron zu halten. Skalierbarkeit ist hier auch eher schwierig, es geht eben entweder alles oder nichts.
09:23
Im Projekt Nexus legen wir, wie schon erwähnt, viel Wert auf die Ausfallsicherheit und die Skalierbarkeit. Außerdem wird die Anwendung in der Cloud betrieben und somit sollten alle Komponenten in diese Cloud-Infrastruktur passen.
09:42
Dadurch, dass die Ziele von Nexus nicht hundertprozentig mit dem klassischen Geo-Server vereinbar waren, wurde im Rahmen des Projekts der Cloud-Native Geo-Server entwickelt. Somit gibt es jetzt eine Geo-Server-Micro-Services-Architektur.
10:01
Er kann mit jeglichem Container-Orchestrator genutzt werden und wurde bisher schon mit Docker Compose, Docker Swarm und Kubernetes getestet. Ihr könnt euch auch gerne das Repository auf GitHub dazu anschauen.
10:21
Aus dieser neuen Microservice-Architektur ergibt sich der Vorteil, dass die Gesamtheit der Services nicht beeinträchtigt wird, falls ein Service mal ausfallen sollte. Außerdem kann die Anzahl der jeweiligen Services dynamisch bestimmt werden und die Konfiguration der einzelnen Dienste ist einfacher teilbar.
10:44
Dadurch, dass Nexus auf einer Cloud-Umgebung aufgebaut ist, kann der Geo-Server auch einfacher und natürlicher in dieses System integriert werden. Und somit erhält man auch all die anderen Vorteile wie zum Beispiel das Monitoring.
11:02
Falls ihr auch noch mehr Fragen oder noch mehr über den Cloud-Geo-Server erfahren wollt, könnt ihr euch gerne die Talks von der FOSS4G und FOSSGIS 2021 zu diesem Thema anschauen.
11:21
Jetzt möchte ich noch über die Routenplanung sprechen, da das für uns eine der wichtigsten Komponenten ist. Sie wird dazu genutzt, um herauszufinden, welches Fahrzeug am besten zum und für Ort geschickt werden sollte. Dafür muss die Planung performant sein, da jede Sekunde zählt und es ungefähr
11:44
einen Einsatz alle sieben Sekunden gibt, aber die Routenplanung wird vor allem eher für kurze Strecken innerhalb eines Landkreises genutzt. Flexibilität ist für uns das Wichtigste, da die Einversatzfahrzeuge nicht alle Verkehrsregeln
12:03
wie Geschwindigkeitsbeschränkungen oder auch das Überfahren weißer Linien beachten müssen. Zusätzlich gibt es immer lokale und temporäre Besonderheiten, wie zum Beispiel den Markt am Sonntag, wo am besten kein Fahrzeug durchfahren sollte oder auch
12:23
Bergstraßen, die nur für kleinere Fahrzeuge befahrbar sind. Mit Industrietauglich ist gemeint, dass sich diese Routenplanung zum Beispiel auch in Docker umsetzbar sein sollte und stabil laufen sollte.
12:43
Wartbar sollte sie natürlich dann auch sein und wenn möglich von einer großen Community kontinuierlich gepflegt werden. Wir haben dann geschaut, welches Framework oder Modul wir nehmen sollten und haben uns letztendlich für PG-Routing entschieden.
13:03
Zur Auswahl stand sonst auch noch zum Beispiel Valhalla oder Graphupper. Ein Grund, warum PG-Routing gewonnen hat, war, dass es sehr flexibel ist. Mithilfe von Joins kann man die Kosten der Kanten auf der Basis von Verkehr, Geschwindigkeit oder auch Sperren anpassen.
13:24
Natürlich ist es nicht besonders performant, allerdings ist das eben der Trade-off mit der Flexibilität. Und bei relativ wenigen Knoten und auch Kanten kann es trotzdem recht performant sein. PG-Routing verfügt über viele bereits implementierte Algorithmen und Funktionen
13:45
wie den Shortest Path, One-to-One oder One-to-Many, welcher für uns besonders wichtig ist. Außerdem gibt es auch den Turn Restriction Shortest Path Algorithmus. Des Weiteren kann der Graph mithilfe von Graphkontraktion optimiert werden, welches
14:05
bei der Performance helfen kann. Bezüglich der kontinuierlichen Pflege können wir uns bei PG-Routing auch teilweise auf die Postgres SQL und Postgres Community verlassen. Und letztendlich ist auch das Load Balancing, welches im Cluster Postgres SQL bereits
14:25
möglich ist, ein großer Vorteil. Wie sieht jetzt eine typische Anwendung bei Nexus aus? Es gibt zum Beispiel einen Notfall in Moulin, jetzt ist die Frage, welches
14:40
Fahrzeug dort hingeschickt werden sollte. Momentan wird dieses Problem so gelöst, dass auf einer sogenannten Abwehrliste nachgeschaut wird, im territorium-westen Feuerwache dieser Notfall sich befindet. Falls dann diese Wache keine geeigneten Fahrzeuge oder Personen bereitstellen kann,
15:01
wird von dieser statischen Liste die nächste Feuerwache, wie in diesem Fall Meso-San, alarmiert. Im Fall von Nexus wollen wir jetzt aber Dynamic Transit Times nutzen, das heißt, dass wir mithilfe von PG-Routing direkt die Zeit berechnen, die es dauern würde, vom Standort der
15:23
jeweiligen Fahrzeuge zum Einsatzort zu kommen. Wenn zum Beispiel ein Fahrzeug der Feuerwache Meso-San bereits in der Gegend unterwegs ist, ist es viel schneller dort, als wenn erst ein Fahrzeug von einer Wache Moulin alarmiert
15:41
werden muss. Das kann wichtige Zeit sparen, die bei Notfällen wie zum Beispiel eines Herzinfarkts essentiell sein kann. Jetzt ist noch die Frage, mit welchem Algorithmus wir diese Route berechnen. Es gibt mehrere zur Auswahl, wie zum Beispiel den Turn Restriction Shortest Path, welcher
16:07
die realistischste Angabe liefern kann. Dieser Algorithmus nutzt Verkehrsinformationen wie den Standort von Weißen Linien zum Beispiel oder auch Kreisverkehr, um dann trotz dieser Einschränkungen eine realistische
16:24
Route für normale Fahrzeuge zu liefern. Die Routenplanung für Feuerwehrfahrzeuge könnte dann einige dieser Einschränkungen ignorieren und ein zuverlässiges Ergebnis berechnen.
16:43
Allerdings benötigt der Algorithmus sehr viele Daten, welche nicht in allen Fällen und Bereichen vorhanden ist. Somit können wir ihn leider nicht unbedingt nutzen. Der performanteste Algorithmus wäre der Bidirectional A-Star, welcher als generell
17:04
beste Lösung gilt. Es ist ein guter Kompromiss zwischen Performance und Relevanz, da es nicht immer der kürzeste bzw. der schnellste Weg ist, der ermittelt wird. Zu Beginn haben wir uns auch für diesen Algorithmus entschieden, allerdings haben
17:23
wir dann durch einige Tests und Experimente gemerkt, dass teilweise sehr schlechte Ergebnisse gefunden wurden. Und deswegen nutzen wir jetzt den Dykstra-Algorithmus, welcher garantiert den kürzesten Weg berechnet. Dieser benötigt zwar generell auch mehr Zeit zur Berechnung, vor allem wenn viele
17:45
Knoten und Kanten vorhanden sind, liefert aber das beste Ergebnis. Da wir uns erstmal für den Dykstra-Algorithmus entschieden haben, geht es jetzt im nächsten Schritt darum, dass wir die Anzahl an Knoten und Kanten verringern, um die Performance
18:04
zu verbessern. Diese Optimierung basiert darauf, dass wir die Vorselektierung der genutzten Kanten für die Routenfindung deutlich optimieren wollen. Dies tun wir, indem wir ein dichtes Verkehrsnetz am Start- und Ankunftsort nehmen, d.h.
18:25
hier betrachten wir alle Straßen, egal ob klein oder groß. Dazwischen allerdings werden nur die großen Straßen genommen, wie Landstraßen oder auch Autobahnen. Dies führt somit zu einem Bild wie hier, leicht lila sind alle Straßen, die es
18:46
gibt und blau sind die vorselektierten Straßen. Rot ist schlussendlich die Route, die mit Hilfe von Dykstra gefunden wurde. Wir sehen, dass nur Kanten in einem quadratischen Bereich um den Start- und Ankunftsort
19:03
ausgewählt wurden. Hier sehen wir keine lila Kanten, da alle in der ausgewählten blauen Menge enthalten sind. Zwischen diesen sind einige kleine Straßen in lila sichtbar, welche eben nicht in der Routenplanung berücksichtigt werden. Es gibt natürlich noch viele weitere Optimierungsansätze, die je nach Bedarf im Projekt umgesetzt
19:26
werden können. Zusammenfassend kann man sagen, dass Open Source, Geo- und Formationssystem Komponenten zeigen, dass sie hohen technischen Anforderungen entsprechen können und an Kunden und
19:43
Projekte wie Nexus angepasst werden können. Durch diese Art von öffentlichen Projekten kann die Entwicklung der Open Source Anwendung wie zum Beispiel eben des Geo-Servers vorangetrieben werden. Dieses Jahr soll noch das Go Live der ersten Version von Nexus gelingen und vollkommen
20:04
einsatzbereit dann 2024 für die Olympienspiele in Paris sein. Damit bedanke ich mich für eure Aufmerksamkeit und wünsche euch noch eine weitere schöne Konferenz.
20:25
Ja, danke Felix für diesen sehr informativen und interessanten Vortrag. Wirklich sehr spannend da mal ein Einblick zugelangen. Es gibt auch jede Menge Fragen, die wir jetzt mal ein bisschen abarbeiten werden.
20:44
Müssen wir gleich mal gucken, vielleicht können wir auch ein, zwei zusammenfassen. Genau, was wir zusammenfassen könnten, ist zum Beispiel einmal wird nach der Mehrsprachigkeit gefragt, inwieweit die Anwendung in Mehrsprachigkeit ausgelegt wurde und dazu passt, glaube
21:00
ich auch, kann es grenzüberschreitend mit Nachbarländern eingesetzt werden. Also momentan ist es nicht vorgesehen, andere Sprachen noch hinzuzufügen. Das heißt, das ist nicht möglich. Auch für die Grenzländer gibt es momentan noch keine Pläne, das voranzubringen.
21:25
Es könnte allerdings sein, dass es eben dann für diese Grenzgebiete, die besonders wichtig sind an großen Städten, dass da noch etwas gemacht wird. Wie sieht das aus? Hier wurde nach der Internetverbindung gefragt, die kann ja im Katastrophenfall
21:41
mal weg sein. Gibt es eine Offline-Variante oder muss quasi immer Internet verfügbar sein? Also soweit ich weiß, läuft das alles über ein internes Netz. Wie gut das jetzt wirklich gegen große Katastrophen abgesichert ist, kann ich
22:01
jetzt nicht sagen. Allerdings, es läuft auch nicht alles hundertprozentig über das Internet, sondern die Fahrzeuge zum Beispiel haben auch zum Beispiel Radiosender und so weiter. Das heißt, manche Sachen könnten auch eventuell über andere Mittel laufen.
22:27
Kannst du noch was zur Sicherheit sagen? Hier wurde nämlich auch gefragt, inwieweit Sicherheit gegenüber Hackerangriffen sichergestellt wurde, analog des Deutschen BSI. Gibt es da Überprüfungen oder gibt es da, da du dir sagst, es ist ein
22:42
eigenes Netz, hat sich das dann eh vielleicht erledigt? Kannst du da was zu sagen? Dazu kann ich nur wenig sagen. Ich weiß, dass es Tests gibt, die das auch abprüfen. Allerdings kann ich jetzt nicht deren vollen Umfang sagen. Das weiß ich leider nicht. Genau, dann haben wir hier noch so zwei, drei Fragen zum Thema Routing.
23:07
Da wird einmal gefragt, ob Verkehrsdaten oder Verkehrsfluss berücksichtigt wird, zum Beispiel wenn Baustellen etc. quasi vorhanden sind. Wird das berücksichtigt bei der Planung?
23:20
Momentan noch nicht. Das ist aber auf jeden Fall geplant. Das soll dann noch zukünftig kommen. War auf der Prio-Liste einfach noch nicht so weit oben. Noch eine Frage Richtung Routing. Wird beim Routing berücksichtigt, wenn sich die Fahrzeuge gegebenenfalls in die andere Richtung bewegen? Das bezieht sich sicherlich auf eine der letzten Folien,
23:42
wo es dann um das dynamische Routing ging quasi. Ich bin mir nicht ganz sicher, wie das in die gesetzte Richtung gemeint ist. Naja, also Fahrzeug A fährt quasi vom Brand weg, sag ich mal. Vielleicht ist es gerade unterwegs, auf dem Weg zurück zur Wache. Ah, ok.
24:01
So hätte ich das jetzt verstanden. Ich denke, momentan wird eben eher nur die Position berücksichtigt. Also nicht die Richtung, in die es fährt. Dann, ich weiß nicht, ob das eine Rolle spielt.
24:22
Kann auch ein Belegungsgrad der Fahrzeuge bei freiwilligen Feuerwehren modelliert werden, also wie viele Leute verfügbar sind. Ich weiß gar nicht, ob das jetzt quasi ähnlich ist wie in Deutschland, wo es ja diese freiwilligen Feuerwehren gibt. Ob das überhaupt für euch in Frage kam, kommt.
24:40
Also generell gibt es das schon. Es gibt auch ein ganz eigenes System, um die Verfügbarkeit von den jeweiligen Fahrzeugen, allerdings auch der einzelnen Einsatzleute zu managen. Das heißt, es ist immer bekannt, wer zu welcher Zeit anwesend ist und einsatzbereit ist.
25:01
Das heißt, dazu gibt es eigentlich genügend Daten und kann gut angezeigt werden. Ok, dann machen wir jetzt noch eine letzte Frage. Werden Protokolle erstellt, die dann auch gerichtsfest sind? Also ist das quasi vorgesehen, dass da irgendwelche Protokolle geschrieben werden? Ja, es werden auf jeden Fall viele Sachen gelockt.
25:22
Und die sind dann auch eben dafür da, dass eben in solchen Gerichtsfällen die eingesetzt werden, um solche Fragen zu klären, ob irgendwas zu spät war oder wer vielleicht Mist gebaut hat oder sowas. Genau da. Ich gucke mal auf die Uhr. Da wir jetzt noch eine Minute Zeit haben, machen wir die letzten
25:42
beiden Fragen auch noch, damit wirklich alle glücklich sind, wenn du denn dazu was sagen kannst. Thema Grenzüberschreitungen hatten wir eben schon. Ich glaube, das ist eine Anschlussfrage darauf. Vielleicht sind eVTZ eine Möglichkeit für die grenzüberschreitende Anwendung. Ich persönlich weiß leider nicht, was das ist. Vielleicht kannst du da was mit anfangen.
26:03
Ich kenne leider eVTZ auch nicht. Gut, dann wahrscheinlich irgendwas mit europäisch für die Zusammenarbeit. Gut, aber wenn du es quasi auch nicht kennst, spielt es ja aktuell da keine Rolle.
26:21
Und dann letzte Frage. Könnte der Algorithmus bei großflächigen Ereignissen an seine Grenzen kommen, zum Beispiel ein Waldbrand? Ich denke auf jeden Fall, wenn zum Beispiel bei Waldbränden dann auch Fahrzeuge von anderen Städten oder von anderen Departments angefordert werden, können es auf jeden Fall Probleme geben.
26:42
Das wird aber allerdings nur ein kleiner Fall sein und eher relativ selten auftreten. Das heißt, da könnte man auch ein paar mehr Sekunden Bearbeitungszeit, denke ich, erlauben. Alles klar. Gut, dann Felix, danke dir für deinen Vortrag.
27:01
Danke, dass du für Fragen und Antworten hier zur Verfügung standest. Danke auch ans Publikum für die interessanten Fragen.