Repository	Link
Source code
Docker image
Standalone Docker image (demos only)

Damast

This repository contains code developed for the digital humanities project "Dhimmis & Muslims – Analysing Multireligious Spaces in the Medieval Muslim World". The project was funded by the VolkswagenFoundation within the scope of the "Mixed Methods" initiative. The project was a collaboration between the Institute for Medieval History II of the Goethe University in Frankfurt/Main, Germany, and the Institute for Visualization and Interactive Systems at the University of Stuttgart, and took place there from 2018 to 2021.

The objective of this joint project was to develop a novel visualization approach in order to gain new insights on the multi-religious landscapes of the Middle East under Muslim rule during the Middle Ages (7th to 14th century). In particular, information on multi-religious communities were researched and made available in a database accessible through interactive visualization as well as through a pilot web-based geo-temporal multi-view system to analyze and compare information from multiple sources. A publicly explorable version of the research is available at Humboldt-Universität zu Berlin. An export of the data collected in the project can be found in the data repository of the University of Stuttgart (DaRUS). A runnable Docker image can be found here. A runnable, standalone Docker image (contains its own configuration and PostgreSQL server) for demo purposes (do not use in production!) can be found here.

Publications

Damast has been used for and discussed in the following publications:

• Weltecke, Dorothea, Ralph Barczok, and Bernd A. Vest: Damast. Konzeptionelle Prinzipien und technische Methoden eines digitalen Projekts zur geotemporalen Visualisierung religiöser Pluralität. In preparation.
• Franke, Max, Guido Reina, and Steffen Koch. "Toward Reproducible Visual Analysis Results." In: Proceedings of the 16th Pacific Visualization Symposium, pp. 102–106. Seoul, Republic of Korea. April 18–21, 2023, IEEE. DOI: 10.1109/PacificVis56936.2023.00018
• Franke, Max and Steffen Koch. "Damast: A Visual Analysis Approach for Religious History Research" In: Proceedings of the 18th International Conference on Computer Vision, Imaging and Computer Graphics Theory and Applications - Volume 3: IVAPP, pp. 40–52. Lisbon, Portugal. February 19–21, 2023, SciTePress. DOI: 10.5220/0011609700003417
• Franke, Max, Ralph Barczok, Steffen Koch, and Dorothea Weltecke. "Confidence as a First-class Attribute in Digital Humanities Data" In: Proceedings of the 4th VIS4DH Workshop, VIS 2019, Vancouver, Canada. October 20–25, 2019, IEEE. https://vis4dh.dbvis.de/2019/papers/2019/VIS4DH2019_paper_1.pdf

Documentation

All parts of Damast are documented, and this documentation is split over different places, such as: this and other Markdown files in the repository, comments in the code and scripts, and HTML files hosted by Damast itself. All those documentation parts, as well as a general system description and explanation, are also collected in one LaTeX document in the repository, which is also checked in as a PDF file.

Database

The historical data is collected in a relational PostgreSQL database. For the project, we have used PostgreSQL version 10. Since the project also deals with geographical data, we additionally use the PostGIS extension. A suitable database setup is to use the postgis/postgis:10-3.1 Docker image. An SQL script for creating the database schema is located in util/postgres/schema.sql, and in DaRUS. An overview of the interplay between tables of the database, and a general explanation, can be found in the documentation.

Software

The server is programmed in Python using Flask. Functionalities are split up into a hierarchy of Flask blueprints; for example, there is a blueprints for the landing page, one for the visualization, and a nested hierarchy of blueprints for the REST API. The server provides multiple pages, as well as a HTTP interface for reading from and writing to the PostgreSQL database. The server is built and deployed as a Docker container that contains all necessary dependencies.

An overview and explanation of the different pages and functionalities is provided in the documentation. The web pages consist of HTML, CSS and JavaScript. The HTML content is in most cases served via Jinja2 templates that are processed by Flask. The JavaScript code is compiled from TypeScript source, and the CSS is compiled from SCSS.

Getting Started

Basic knowledge with build tools and Docker are required. The instructions below assume a Linux machine with the Bash shell are used.

Special Note of Forked Repositories

On forks, make sure that the tags from the upstream repository are also present in your fork. The tags (for git describe --tags) are required to run the deploy script. To get the upstream tags, run:

$ git remote add upstream git@github.com:UniStuttgart-VISUS/damast.git
$ git fetch upstream --tags

Installing Dependencies

On the build system, Docker and NodeJS need to be installed. If the Makefile is used, the build-essentials package is required as well. In the root of the repository, run the following code to install the build dependencies:

$ npm install

Building the Frontend

To build all required files for the frontend (JavaScript, CSS, documentation), the Makefile can be used, or consulted for the appropriate commands:

$ make prod

For the web build targets, the npm dependencies must have been installed first, see Installing Dependencies. For the documentation, a LaTeX distribution including latexmk and TikZ must be installed on the system. On a Debian or Ubuntu system, these can be installed via the packages texlive-pictures and latexmk.

Building the Docker Image

All frontend content and backend Flask code and contents are bundled within a Docker image. In that image, the required software dependencies are also installed in the correct versions. A few configuration options need to be baked into the Docker image on creation, which are dependent on the setup in which the Docker container will later run. Please refer to the deploy.sh shell script for details and examples, as well as to the section on running the server. The Dockerfile is constructed from parts from util/docker/, and then enriched with runtime information to ensure that certain steps are repeated when data changes. An exemplary creation of a Docker image (fictional values, please refer to deploy.sh before copying) could look as follows:

# calculate hash of server files to determine if the COPY instruction should be repeated
$ fs_hash=$(find damast -type f \
    | xargs sha1sum \
    | awk '{print $1}' \
    | sha1sum - \
    | awk '{print $1}')

# assemble Dockerfile
$ cat util/docker/{base,prod}.in \
    | sed "s/@REBUILD_HASH@/$fs_hash/g" \
    > Dockerfile

# build Dockerfile (warning: dummy parameters!)
$ sudo docker build -t damast:latest \
    --build-arg=USER_ID=50 \
    --build-arg=GROUP_ID=50 \
    --build-arg=DAMAST_ENVIRONMENT=PRODUCTION \
    --build-arg=DAMAST_VERSION=v1.0.0 \
    --build-arg=DAMAST_PORT=8000 \
    .

The resulting Docker image can then be transferred to the host machine, for example, using docker save and docker load. Of course, the image can be built directly on the host machine as well.

Running the Server

The server infrastructure consists of three components:

1. The Flask server in its Docker container,
2. the PostgreSQL database, for example in the form of a postgis/postgis:10-3.1 Docker container, and
3. a reverse HTTP proxy on the host machine that handles traffic from the outside and SSL.

The util/ directory contains configuration templates for an NGINX reverse proxy, cron, the start script, the systemd configuration, and the user authentication file. The documentation also goes into more details about the setup. A directory on the host machine is mapped as a volume to the /data directory in the docker container. The /data directory contains runtime configuration files (users.db, reports.db, as well as log files). The main Docker container requires some additional runtime configuration, for example for the PostgreSQL password, which can be passed as environment variables to Docker using the --env and --env-file flags. Alternatively, configuration values can be stored in a JSON file in the Docker container's /data directory (or any other mounted volume), and the path passed via the DAMAST_CONFIG environment variable. The following configuration environment variables exist, although most have a sensible default:

Configuration values can be passed in multiple ways. The precedence of configuration values is as follows (first entry has the highest precedence):

1. Environment variables passed to the Docker process via the --env or --env-file flags.
2. Environment variables baked into the Docker image (see [./util/docker/](the Dockerfile components)).
3. Configuration entries in the JSON configuration file.
4. The default value.

Overriding Pages

When running the server, it might be necessary to override some pages; for example, one might want a different home page, or a different impressum. The server uses the DAMAST_OVERRIDE_PATH environment variable to load such overrides. If it is set, the Flask server creates an extra blueprint, and the directory ${DAMAST_OVERRIDE_PATH}/templates/ is added to the Jinja2 template search path with precedence. Further, the files in the ${DAMAST_OVERRIDE_PATH}/static/ directory will be served without requiring any authentication under the URL ${DAMAST_PROXYPREFIX}/override/static/<file path> (use url_for('override.static', filename='<file path>') in templates).

An example how this could be used to use an own home page with a separate stylesheet is listed below. In this example, the /data directory in the Docker image is already mapped to the /www directory on the host. In the /www directory on the host, we create the directories override/static/ and override/templates/. Then, we can pass the environment variable DAMAST_OVERRIDE_PATH to the Docker container as /data/override.

Content of /www/override/templates/root/index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>New home page</title>
  <link rel="stylesheet" href="https://github.com/UniStuttgart-VISUS/damast/blob/main/{{ url_for('override.static', filename='home.css') }}">
</head>
<body>
  <h1>This is the new home page</h1>

  <p>
    There is not much content yet.
  </p>
</body>
</html>

Content of /www/override/static/home.css:

h1 {
  color: blue;
}

Now, when running the server and navigating to https://<host>/${DAMAST_PROXYPREFIX}/, the new home page should be served, and the stylesheet loaded.

Keep in mind that all contents of the static directory will be served without user authentication. For details on which paths templates must be put under for proper override, refer to the template/ directories of the blueprints in the repository. For details on how to inherit from the base template, refer to the base template and other, inheriting templates. Adding static files while the server is running should work without problems, but templates are not hot-loaded in production systems, so the server needs to be restarted if the templates change.

Overriding the Start Page Background Image

To use the default start page, but provide a custom background image visible behind the content, the following instructions must be followed: The background image can be added as an override static file, or referenced via an external URL. For the first variant, suppose the image is stored in the override folder in static/bg.jpg. The following contents must then be placed in the override folder in templates/override/background-image-url.html:

<style>
  :root {
    --home-bg-image: url({{ url_for('override.static', filename='bg.jpg') }});
  }
</style>

Alternatively, for an external URL, the contents of the url() statement would be the URL of the image (e.g., url(https://example.org/bg.jpg)).

Using the Shaded Relief Map Tiles

We have created a WebMercator tile set that only contains shaded relief, which is based on NASA SRTM topographic height data. This dataset is published on DaRUS under the CC BY 4.0 license. These tiles, alongside the public domain map data of water features provided by Natural Earth, can be used as the default map layer in Damast, suitable for screenshots (only attribution needed). To enable this map layer, the configuration variable map_tile_path (see table above) must be set. Our recommendation is to download and host the tiles using the nginx proxy that also handles TLS. A download script is provided in util/shaded-relief-map-tiles, alongside an amendment to the nginx configuration. If this nginx configuration is used, the configuration variable's value should be ${DAMAST_PROXYPREFIX}/tiles/{z}/{x}/{y}.png. The provided download script will download tiles down to zoom level 12 within the rough coverage area of the Dhimmis & Muslims project, and down to level 6 outside of it. This results in a tile dataset size of about 10GB. A different subset of tiles, or the entire set (ca. 100GB), can be downloaded using the scripts provided in the GitHub repository associated with the DaRUS repository.