## 2 Systematic Assessment of Innovative Crisis Management Solutions
### Applying KeepOperational and ZKI in the Trial
#### 2.3.1 Preparation of DLR's Techniques  
To apply the DLR solution in the simulated environment of the trial, it was connected to the TTI by using two separate adapters, one for KeepOperational and one for the ZKI module. The adapters were developed using the Java programming language. A library provided by the DRIVER+ project could be used to connect to the TTI. The TTI itself was based on Apache Kafka, a messaging system. Connected applications can produce and consume messages on certain topics. The messages were structured using Apache AVRO [5]. Each adapter connects with a unique identifier. KeepOperational was connected as a consumer, listening for updates regarding the flood situation. The ZKI module was connected as a producer, publishing updates of the recorded flooding to the TTI. Topics and adapter identifiers were defined during technical integration sessions with the DRIVER+ TTI team. During the trial, each adapter was also given an individual certificate to authenticate himself at the TTI to ensure security.  
In a data pre-processing step, a hypothetical disaster extent layer was prepared. The simulated test data were based on a pre-calculated flood prediction and transformed according to realistic characteristics of optical airborne data acquisition and processing techniques. During this process, the spatial resolution of the original data layer was resampled from 0.2 m to 1 m to reduce complexity and the amount of data, and thus to minimize calculation and transmission times. A binary mask was derived, which contained only one class (\"water\"). Additionally, a minimum mapping unit of 100 square meters was applied. Finally, the mask was converted to a vector layer. The resulting information layer was ingested to the geoserver component of DLR's EOC geoservice [21] and published conformable to the standards of Web Map Service [22] and Web Feature Service [23] of the Open Geospatial Consortium. The required services for the web-based tool KeepOperational were deployed on DLR servers for the purpose of the trial. Using Docker containers, however, it could easily be deployed in other server environments. The required street network was obtained from OpenStreetMap [24]. To be used in KeepOperational, the data were converted into an internal format by using the SUMO NETCONVERT tool [25].  
To compile simulated 2D and 3D damage assessment maps, ZKI obtained an aerial image mosaic [26] and additional geographic data (inland water, public transport stations, road transport [24], rail transport [27], building data/administrative boundaries [28], and points of interest [27; 29; 30]) from open data sources. The flood extent was intersected with this geo-information using ESRI ArcGIS software [31] to provide the damage assessment. The 2D GeoPDF was prepared with ArcGIS and the TerraGo Publisher extension [32]. The software Eternix BlazeTerra [33] was used to compose the corresponding 3D PDF. The scope of analysis, as well as the PDF output format, was chosen corresponding to ZKI's years of experiences in rapid mapping on data availability and limited technical resources of emergency responders to use geospatial products. The final map products were uploaded to the webserver of ZKI and made available as https-downloads.