The Cultural Heritage Response Unit (CHRU) is implementing a digital documentation system to document both the objects themselves and the measures carried out during response missions to protect cultural heritage. The unit is equipped with its own mobile IT infrastructure so that the documentation system can operate autonomously. The system described here is set up in cooperation between the Field Tech Support Unit (FTS) of the THW and the Department of Scientific Computing of the DAI.
Hardware
The central element of the entire system is a box in which a server (mini-PC / barebone) and a router are installed. The various units can use tablets or smartphones at the site to enter data in predefined masks. These devices can also be connected to the server via LAN or WLAN at a connected workstation. Additional SSD hard disks are plugged into the server, which can be quickly removed and backed up in an emergency.
Servers, routers and hard disks take up no more space than a standard PC tower and can be easily transported. Additionally, the equipment currently consists of two tablet cases with 20 mobile devices each and two notebooks, a very small webcam for taking photos on an illuminated table and several access points depending on the situation. Access to all devices is secured by updated VPN tunnels and rigorous firewall rules. The system therefore meets all IT security requirements. All of the hardware components are subject to constant updating and improvement.

Workspace of the IT-Expert with boxes of mobile devices | Photo: Bernhard Fritsch, DAI
Software
Data collection will be carried out via mobile devices using the QField app. QField is the mobile client of the QGIS geo-information system and was adapted to the needs of the CHRU mainly through the data model used. QGIS / QField are open-source programs and thus allow a great deal of control and the possibility to integrate other devices.
All data collected is stored in a PostgreSQL database installed on the central (mini) server. This makes it possible to synchronize the data live and thus track the progress of the work on all devices in use or to adapt the operation by quickly assessing the situation based on the current data.
Even if the program originally focused on geodata, a variety of data types can be recorded. This includes the possibility of adding audio, video, photos and textual information as core elements. The ICA predefined forms are designed for the documentation of buildings and damage to the building fabric, while the forms for MCA map a process chain following the rescue path of objects from salvage, cleaning and securing to packaging and temporary storage. The joint ID system guarantees the connection of both areas to map the locations of movable cultural assets in the buildings, and to document the procedures carried out on the objects independently of the geographical information.


Example of entry forms: (on the left) for movable cultural assets; (on the right) for immovable
cultural assets | Photos: Bernhard Fritsch, DAI
The special challenges of operating in an emergency entail a great effort in balancing the mix between (academic) accuracy in the documentation of cultural heritage and minimal data to be recorded under pressure, also with regard to a final data transfer in the sense of FAIR (Findable, Accessible, Interoperable and Reusable) data principles. From a technical point of view, it is best to use the flexibility of a PostgreSQL database to adapt the QField project depending on the situation without having to edit the database in the background.
The large number of images taken directly via mobile devices or in the photo station via an external camera are also copied to the server with the help of the AutoSync app and can be accessed from there via the NginX web service by all other connected devices for viewing. In addition, further external data, such as laser scan or Structure for Motion (SfM) data, can be stored and backed up in a Nextcloud instance installed on the server. Nextcloud Talk allows direct communication between the devices registered in the network.
For individual additional functions, apps can be installed on individual or all devices, such as apps for further image processing or for controlling GNSS devices.
Network and procedure
The use of the hardware and software can be adapted to the situation on site in terms of power supply and network connection.
The standard variant (variant A) provides for data recording in a local network without an Internet connection, but with a sufficient power supply. In this case, the router sets up a local network and all mobile devices located within this network save the data directly in the PostgreSQL database. The QField project must be set up for online recording. The decisive factor here is stable coverage of the deployment site with the local network. This can be achieved through the targeted installation of access points, which can be quickly relocated as required to cover a different area for data collection. Variant A is a closed system that enables parallel and fast data acquisition with a large number of mobile devices for one location within the local network.



Documenting immovable and movable cultural assets with a tablet | Marcel Pasternak, Constance Domenech, DAI
It is possible to use an existing WLAN or to supply the router or a second router with an Internet connection via 5G. For example, the documentation system, which is always synchronized live, can be extended to two or more remote locations (variant B). Communication and importing data to the server is then carried out via a 5G data connection. Individual tablets used at remote locations can directly connect with the overall project. In variant B, a connection could also be established to another server, e.g. in the operations center in Germany, and this second server could be used as a backup option. However, this data transfer can only occur upon authorization by the local host institution, and represents a safeguard for data preservation.
QField also offers the option of recording data offline (variant C). The data from the individual devices must be merged manually once data collection is complete. A project synchronized this way can become accessible to all the individual mobile devices the next day, so that all devices can access the same data again. Variants C and A can also be combined so that individual mobile devices no longer within range of the local network can also be used to record data. The data from these devices can then be added manually to the central PostgreSQL database.
Finally, in variant D neither the Internet nor sufficient power is available for offline recording by the tablets. In this case, the data can be entered on paper forms that are identical to the input masks in QField. Photos can be taken using external cameras. This variant makes data collation very laborious and error-prone, and it is applicable only in extreme emergency.
Data management
Most of the documentation from the field can be stored in a central PostgreSQL database. As photos are another central element of data collection, the database was supplemented with a NginX web server allowing photos taken by different mobile devices to be visible to all devices. Photos can be uploaded at a central location and the path is automatically changed accordingly in the PostgreSQL database. In this way, each tablet can access photos of the other devices via the link in the database.
In addition, a range of other data such as laser scans, inventory lists or photos from external cameras can be collected during a mission. This data is stored on external hard drives connected to the server according to the usual data management rules so that the hard disks can be quickly removed and backed up in an emergency without having to pack up the entire system.

Tracing the data documentation in the control room | Photo: Marcel Pasternak
Summary
This system for data acquisition in the field consists of several individual components, all of which are commercially available, Open Source and readily available. The configuration of the devices and the adaptation of the software can be carried out directly and independently by project members, so that the project itself can always exercise a high degree of control over the entire system. Adjustments can also be made quickly.
In September 2024, this IT architecture was tested during a full-scale CHRU exercise. In terms of the data recorded, the exercise was very successful and the digital documentation system fulfilled its purpose. The technical implementation in terms of setting up the local WLAN, secure access to the server and database and parallel data collection from several mobile devices with immediate synchronization could effectively work. The shortcomings mainly referred to very practical matters such as the size and cabling of the devices in the Base of Operations (BoO), but above all to the optimization of workflows and processes between the specific specialized units and IT.
The next goal must be to make the entire setup even more robust and stable to minimize potential sources of error when non-IT experts are recording data. The focus here is on supplying the area of use with stable WLAN so that variant A of the system can be implemented and manual data synchronization is avoided as much as possible. Only then will the advantages of digital documentation such as speed, accuracy and structure of the data or the low number of sources of error concerning data quality become apparent.

Daniel Lorenz, THW, und Bernhard Fritsch, DAI.
Extract from the article “IT infrastructure for cultural heritage response missions”, orginally published in Technical Bulletin #4 from PROCULTHER-NET 2.