DIMAG

The main goal of the long-term project is the development of the Digital Interactive Maritime Atlas of History (DIMAG). This is a web-based research tool, which is implemented as a WebGIS (geographic information system). With the help of the tool, on the one hand, maritime links can be simulated with considerable precision by combining routing algorithms, weather data, and performance data from the 1:1 Laurons II reconstruction, among others. These calculated routes will be displayed on WebGIS via a georeferenced map (similar to Google Maps), with space and time limited to the Mediterranean and Roman Imperial periods in the first funding phase. On the other hand, the route simulation data can be displayed and linked by historians or interested laymen with the geo-referenced research data such as lighthouses, amphora finds, navigation points, raw materials, goods or products deposited in a geo-database or the database environment FuD and collected by the project area “Historical Research” for further analysis. Based on the collected research data and route information, further studies on the Roman economy, maritime connectivity and especially the Roman maritime trade can be carried out. Thus, DIMAG represents a comprehensive research tool that significantly exceeds previous approaches such as ORBIS in its precision.

Rough structure of DIMAG as a research tool

WebGIS

The WebGIS represents the visible area of the research tool. Here, users of DIMAG can request maritime connections depending on the starting point and destination, the ship to be used, and the starting time of the voyage. When a user submits a request for a route connection, WebGIS first asks the geodatabase whether the corresponding route simulations are already available, i.e. whether .gpx files are already available for this request. If these are available, they are immediately output and visualized for the user on the WebGIS interface. If the routes have not yet been calculated, WebGIS passes the parameters to the route simulation software, which forms the backend of the research tool. The simulation program calculates all routes and then passes them to the geodatabase, which in turn transfers the information to the WebGIS.

In addition to the route simulations, users of the research tool use WebGIS to select the historical research data they want visualized on the GIS interface for further analysis. Depending on the category requested, the data is then loaded into the GIS from the separate FuD research database and displayed. By clicking on the data points or by selecting the list displayed in parallel, further specific information can be retrieved.

The WebGIS is developed using the Angular framework and OpenStreetMaps.

Route simulation

The route simulation software is an essential component of the DIMAG tool. This is where the research results from data collection and analysis, reconstructions, and historical background research converge. The simulation software runs in multiple instances for parallel user access on a server environment and is connected to the geodatabase and WebGIS through scripts. Queries from users in WebGIS, which have not already been simulated, are passed as parameters to the simulation software. The simulation software then calculates all available routes (i.e. all route variants that reach the destination) based on the polar diagram of the selected ship type, the weather data from the years 1990-2010 provided by NOAA – these come closest to those of the imperial period due to the climatically similar conditions – as well as the selected sailing time and transfers the data saved as a .gpx file to the geodatabase.

The core of the route simulation is the OpenCPN program written in C++, which has been and is being adapted from the ground up. Originally developed by passionate sailors as a desktop client, the program was first thoroughly analyzed and all unneeded program components were removed. The most important included component is the routing function of OpenCPN, which was separated from the GUI of the program in the next step and ported for Linux as a command line program. Since the route simulation software in DIMAG will run on a Linux server, this step was essential for the planned automation of route requests by users of DIMAG.

Exemplary representation from OpenCPN for route calculation with isochrones of the route Marseille – Alexandria

The calculation of the sailing routes and sailing times is done by the simulation program by using so-called isochrones. This means that the program runs from the starting point for a fixed time interval, for example for one hour, all courses that can be run from the virtual ship (i.e. depending on the polar diagram of the ship and the existing wind conditions at the time). In the next iteration, from the outer points reached in time, all possible courses are calculated again. This procedure is executed until the target is “inside” an isochron – or the procedure is aborted beforehand due to lack of feasibility of the connection, for example due to bad wind conditions.

By this approach one gets on the one hand all actually possible routes at this time mapped, at the same time a strong filtering of the route is necessary to avoid unnecessary and time-consuming isochronous connections (see picture for an exemplary representation of the route calculation). For the connection from Marseille – Alexandria, isochronous connections, which in the end lead to Mallorca, Croatia or Turkey, are certainly not purposeful.

The isochronous connections that have reached the target point are exported by the program as a collected .gpx file and transferred to the geodatabase. In this way, all routes that can be sailed during a query period are stored together and are available. If another DIMAG user requests the same route connection again for the same query period, a query logic within WebGIS recognizes that the data is already available in the geodatabase – so a new calculation is no longer necessary. In this way, DIMAG’s geodatabase of calculated routes is constantly enlarged by user queries; the calculation and thus waiting time for users is thus constantly reduced.


Exemplary representation of the isochronous process, here in the second iteration. Only those points that are farthest from the first iteration or the starting point are of interest for the route calculation. Image source: https://routing.luckgrib.com/intro/isochrones/img/iso second as iso.jpeg

Database design

DIMAG uses two different databases for data provisioning, which are hosted together with the rest of the DIMAG architecture on the same server environment. A distinction can be made between the research database FuD, in which mainly georeferenced data from the project area of historical research are provided, and a geodatabase, in which the route simulations are stored.

Research database FuD

The database “Research Network and Database System (FuD)”, which has been in existence at the University of Trier since 2004 and is funded by the German Research Foundation DFG, provides a virtual research environment for the humanities and social sciences. The modular software maps the complete research process and supports time- and location-independent collaborative research work. FuD offers a variety of tools for data collection, annotation, analysis, and preparation, up to publication and archiving.

The core of FuD is a MySQL database, which can be accessed by means of JSON interface (Elastic Search Index) communicates with the WebGIS. In DIMAG, numerous georeferenced datasets are stored and made available in FuD, including ports, commodities, products, amphora data, lighthouses, and more.

For more information on FuD, please visit: https://fud.uni-trier.de/

Geodatabase

DIMAG stores the precalculated and requested route simulations in a specially configured geodatabase. This is based on PostgreSQL. An interface between the database and WebGIS ensures that routes that have already been calculated and stored in the geodatabase are not transferred again to the simulation software as a job, but are transferred directly from the database to WebGIS.