Modelling the Evolution of Frontiers

After having been to outer space, many astronauts expressed their feelings of what is called “The Overview Effect” by Frank White. Looking at the Earth from space and realising that there is only one planet we all live on, with a tiny layer of atmosphere and the total lack of frontiers makes politics seem so small and insignificant.
On earth, however, frontiers are extremely important. Not only do they specify ownership over land, they describe where cultures change, where language barriers exist and stand as an invisible landmark of a bloodthirsty past. The evolution of frontiers is thus crucial for understanding history.

A problem to solve

Currently, there are only few online tools that present the history of frontiers. It is still an area with much potential for expansion.
In order to make historical information about borders available for everyone, old maps need to be digitised, meaning converting data to digital form for the use in a computer. Digitising historical maps is a very cumbersome undertaking: After scanning, geo-referencing and rectifying a map, the objects to extract have to be traced accurately. Most of the latter has to be done manually. When the editing work is done by a team of experts an extensive tool like QGIS is most often used, but if a crowdsourcing solution is desired, a simpler web tool is preferred for easy access and low learning curve. Our goal was to create such a web tool.
This is not the first project in this direction. Our predecessor, Antoine Imboden, has already collected a big dataset on the frontiers of Venice. With it he has created a nice webapp with a time slider which makes it possible to browse through Venice’s history and visualise the evolution of its frontiers. Further he has included frontier related text based information about each of Venice’s regions. His work was based on:
  • the Euratlas data provided by Marc-Antoine Nüssli (Basis),
  • work on Venician colonies originally done by Dr. Mélanie Fournier (Domini da Mar),
  • his own work using various sources (Domini di Terraforma).
Our predecessor’s work has some details that can be improved. The polygons that create frontiers are not very exact (polygons overlap) and according to Isabella di Leonardo incomplete and partly incorrect. Further there was no database; all information of the polygons was hardcoded in the JavaScript code. Therefore it is the perfect sample database for our project: In order to improve it, data has to be edited, added and removed.

Our solution

There are several possibilities to create this web tool: The first  would be to design an entirely new website, a second to improve an existing website like the promising platform called OpenHistoricalMap (OHM). We chose a third solution: Olivier Dalang, our assistant, was at the same time working on an EPFL open source historical map solution, so he invited us to work with him. We reached this decision because creating an entirely new website would not fit into the courses time frame and the Open Historical Map solution is quite extensive and therefore difficult to work on.
Our task in Olivier’s project was to add the border data of our predecessor’s work and to provide the necessary graphical user interface to edit it.


When creating a website that will handle a lot of data, the underlying database has to be well thought-out. In the database schema that Olivier has developed, every object is represented by an entity. Information about an object are assigned to the entity as properties. These properties are for example the object’s shape (most important for us), but also its owner, its creator, its height, its successor-entity, etc. An entity is timeless, but each of its properties has assigned a date that determines when it was valid. By interpolating between all the dates of properties of the same type (e.g. all geometry properties of the entity ‘Frontier between Switzerland and France’), the system automatically calculates each property’s start and end date. We described the data model more closely in our second blogpost.
This structure allows us to very flexibly define entities (whatever they may be) and describe their changes in time in the way needed. If we want for example to study the evolution of a certain frontier (a certain entity), we can just browse through this entity’s geometry properties.

Graphical User Interface

During the design process of the GUI, we tried to imagine the workflow of historians when they are using the website.
First Scenario
In a first scenario, the historian might have found an interesting object, say a church, and wants to follow it through all of its history: He starts with exploring the building’s shape at a certain time and then wants to jump in time to the next step of the building’s evolution, e.g. when a new tower was built. For this case, we decided to include buttons that allow to browse through an entity‘s evolution, back and forth in time.
The difficulty thereby was that one entity can become multiple entities in the future or the reverse, multiple entities can merge into one. In the example above this would be the case, if the existing church and a nearby lying existing chapel (two different entities) would be merged into a cathedral (one entity). Another example, which is actually closer to our project’s topic, are frontiers: The frontier of a country is not saved as a whole, but is separated into border sections (as described above). Now, in case of a war, when countries annex land, it is easily imaginable that two border sections become one. For the GUI this means that the relationship from one time slice to the next is not always clearly defined. In the cases where it’s not, we simply allow to click on the properties of type ‘succession-relation’ for jumping to the respective entity.
Second scenario
A second scenario is that a historian would like to digitize an existing physical source. He uses the slider to choose the right time and localizes on the map the entity he wishes to edit, or the place where he wants to create a new entity. In the first case he clicks on the entity and can then create/edit its properties. In the second case, he clicks on the “create” button on the top right of his view for opening an ’empty entity‘ in the inspector, where he can create new properties:
Third scenario
In the third scenario the historian wants to edit existing data without a source. A good example is our particular situation: countries (or regions) are defined as polygons and frontiers overlap or form gaps in between. The historian wants to only have one border that separates two countries instead of two, just in the way the database is designed. This is made especially easy with the use of a feature that makes your mouse pointer “snap” to existing points. With this feature, gaps between objects are a thing of the past.

Final words

The project is a prototype trying to show what a digital historical map can do to improve the work of historians and to see what data models and user interfaces are necessary to do so.
The source code of our work can be found at Github, in a branch of Olivier’s repository.