EFS Blog

Bisher wurden die Hydranten in einer Liste verwaltet, bei Eingabe einer UTM-Koordinate wurde nach Entfernung zu diesem Punkt sortiert. Die einzelnen Hydranten wurden als Zeilen einer Tabelle mit Beschreibung und Ort dargestellt. Mehr als 15 Jahre später sind die Möglichkeiten inzwischen deutlich vielfältiger. Dank der Bibliothek der Marble-Projekts ist die Darstellung einer Karte aus einem Qt-Programm heraus einfach und kostenlos möglich. Dank OpenStreetMap gibt es auch entsprechende Karte kostenlos und in ausgezeichneter Qualität zu haben.

Auf diese Weise entstand eine einfache Hydrantenkarte, die neben Unterflur- (UF) und Überflurhydranten (pillar) auch Löschwasserbehälter (Z) sowie Rettungspunkte (EAP) anzeigen kann. Die Daten werden derzeit jeweils zum Zeitpunkt des Abrufens direkt aus der weltweiten Datenbank geladen. Es ist aber genauso einfach möglich, die Daten lokal in einer Datei vorzuhalten. Der Quelltext des Programms ist frei zugänglich und ausdrücklich für eigene Experimente gedacht.

Die Eintragung der Hydranten in die OpenStreetMap-Datenbank hat auch ohne dieses Programm schon Einsatzmöglichkeiten, neben der normalen Karte von OpenFireMap existiert z. B. auch schon eine mobile Version.

Ein paar freie Stunden an den Ostertagen habe ich investiert um den Fahrzeugdatenbankeditor nach Qt zu portieren. Da das Programm bis auf die Funktion zum Laden der Fahrzeugdatenbank nahezu keine Überschneidung mit dem EFS selbst besitzt war das schnell gemacht. Zur Zeit fehlen noch ein paar Kleinigkeiten, wie z. B. das Setzen der Normbeladung oder das Hinzufügen und Löschen von Fahrzeugen. Gleichzeitig hat das Programm ein paar neue Features gewonnen, so kann in Zukunft mit einer Datei StandardBeladung.fzg im aktuellen oder Programmordner die Normbeladung um weitere Fahrzeugtypen ergänzt werden bzw. die Beladungsvorschläge des Programms überschrieben. Die Liste der Fahrzeugtypen entsteht einfach aus der Liste der so bekannten Normfahrzeuge. Wenn man mit der Maus über die Fahrzeugliste fährt werden Typ und Standort des Fahrzeugs als Tooltip angezeigt. Ein Filter für die Listenansicht wird auch noch kommen, das Eingabefeld dafür ist oberhalb der Fahrzeugliste bereits sichtbar. Der Filter wird ebenfalls die Suche mit Regulären Ausdrücken unterstützen.

Sobald das Programm in vollem Umfang zur Verfügung steht werde ich Versionen für Linux und Windows sowie den Quellcode auf der Webseite zum Download zur Verfügung stellen. Die Quelltexte werden unter GPL 2 und 3 stehen, so das Verbesserungen ausdrücklich möglich und erwünscht sind.

Wer das EFS schon mal in Aktion gesehen haben wird sich bei diesem Bild sicherlich zuhause fühlen. Und das ist nicht nur eine GUI-Demo, sondern ein durchaus schon funktionierender Ansatz. Die beiden zusätzlichen Seiten für den Bereitstellungsraum können hinzugefügt und wieder entfernt werden, das Verschieben der Fahrzeuge klappt sowohl über die Buttons als auch per Drag&Drop und im Protokoll tauchen die entsprechenden Meldungen auf.

Der nächste Schritt nach dem Laden des Einsatzortes war das Laden der UTM-Koordinaten. Eigentlich weniger das Laden als vielmehr das Interpretieren und arbeiten damit. Nach 3 weiteren Stunden Arbeit habe ich nun eine UTM-Klasse die mit Angaben in Meter- und 10-Meter-Genauigkeit zurechtkommt, sich in Text und zurück umwandeln lässt und mit der man die Entfernung zwischen zwei Koordinaten berechnen kann. Und das ganze ist gleich mit einer ganzen Reihe automatischer Tests unterlegt die mir bei zukünftigen Änderungen gleich Alarm schlagen wenn ich irgendwas kaputt mache.

Das Laden der gespeicherten Einsätze war mein Programm für dieses Wochenende. Dank QDomDocument war das auch gar nicht so schwer. Alle Häßlichkeiten von XML, wie die Prüfung auf Wohlgeformtheit, die verschiedenen Möglichkeiten Attribute zu umschließen und ähnliches, werden einem von diesen Klassen bereits abgenommen. Am Ende musste ich "nur" noch durch den XML-Baum laufen und prüfen ob die Knoten die erwarteten Attribute haben und diese in die entsprechenden Daten überführen. Aber wohin eigentlich?

Dank Model/View gibt es eine zentrale Stelle an der die am Einsatz beteiligten Fahrzeuge abgelegt sind. Dorthin werden die Elemente der einzelnen Listen aus dem EFS geladen, die einzelnen Listen äußern sich dabei nur am Wert einer Eigenschaft. Für mich heißt das in Zukunft das die Bewegung eines Fahrzeugs von einer Liste in die andere nur einen Wert innerhalb dieses Fahrzeug-Objekts ändert und ich die Anzeigekomponenten darüber informiere das sich dieser Wert geändert hat. Festzulegen was jetzt neu gezeichnet werden muss und wo übernimmt Qt für mich.

Für den ganzen Rest des Einsatzes (Einsatzleiter, Koordinaten des Einsatzorts, Alarmzeit, Abschnitte usw.) gibt es jetzt einen schönen neuen Datencontainer, der vom XML-Parser gefüttert wird. Das funktioniert schon sehr zufriedenstellend, auch wenn ich viele Dinge (wie z.B. die Unterteilung in Abschnitte) im Moment noch nicht implementiert habe. Alarmzeit, Einsatzleiter und die am Einsatz beteiligten Fahrzeuge hingegen funktionieren bereits.

Das Laden von Einsätzen nimmt weiter Gestalt an. Die Listen der Funkkanäle und die Fahrzeuge lassen sich inzwischen erfolgreich wiederherstellen. Einige Details fehlen noch, aber gegen Ende des Tages wollte ich dann doch noch was sehen. Also habe ich ein kleines GUI von betörender Hässlichkeit zusammengeklickt, das die im Einsatz befindlichen Fahrzeuge darstellt. Im Moment nur 4 von vielen möglichen Standorten der Fahrzeuge, aber es ist ja ohnehin nur zum Testen. Beim Hinzufügen von neuen Fahrzeugen werden diese automatisch dargestellt, ohne das ich speziellen Code dafür geschrieben hätte. Sehr praktisch ;)

Auch wenn es in letzter Zeit recht still um das EFS geworden ist: es lebt. Und es steht nichts weniger als eine komplette Neuimplementierung ins Haus.

Die Anfänge des EFS reichen zurück bis ins Jahr 1996. Begonnen hat alles noch mit einer Testversion von Delphi 3, die überzeugte und deshalb gegen eine Vollversion von Delphi 5 getauscht wurde. Darauf basiert das EFS bis heute. Wichtigstes Argument für Delphi war die gute Unterstützung von strings, das heißt die Verarbeitung von Text im Programm. Und der Editor für die grafischen Formulare war einfach gut.

Inzwischen ist mit Qt aber ein für viele Betriebssysteme kostenloses, extrem leistungsfähiges Toolkit verfügbar. Das ganze basiert auf C++, der Programmiersprache die quasi von jeher der Konkurrent von Delphi war. Zu dem Zeitpunkt, als das EFS entstand, war Delphi in meinen Augen die absolut richtige Wahl. Die Welt um C++ herum ist inzwischen jedoch gigantisch. Dazu gehört nicht nur das wirklich hervorragende Toolkit Qt, sondern dazu gehören auch Dinge wie Codeanalysatoren, die automatisiert Fehler suchen. Dazu kommen noch drei Dinge die für mich inzwischen wichtiger denn je sind: für jede Komponente, die zum Erstellen der Programme benötigt wird, gibt es mindestens eine Alternative, es ist mindestens eine dieser Komponenten kostenlos zu haben und trotzdem wirklich gut und zu guter letzt ist die Linux-Unterstützung mindestens genauso gut wie die Windows-Unterstützung.

Das EFS läuft seit vielen Jahren mit Hilfe von Wine auch unter Linux, aber mit Qt kann ich endlich eine wirklich echte Linux-Version erstellen. Hätte Borland damals Kylix nicht so furchtbar in den Sand gesetzt wäre das alles vielleicht schon viel früher und mit Delphi möglich gewesen. Jetzt kommt es anders.

Das neue EFS wird dabei zunächst nichts revolutionär neues sein. Es wird die gleichen Funktionen enthalten wie bisher, an manchen Stellen vielleicht um Kleinigkeiten verbessert. Aber unter der Haube wird es runderneuert sein, so das neue Funktionen mit wesentlich geringerem Aufwand hinzugefügt werden können. Es gibt noch keinen Zeitplan, aber die Arbeiten haben schon begonnen.