Modelling the evolution of frontiers: Progress Report 1

Reconsidering our project

In the first week of the new semester, we tragically discovered that our project as planned does not make much sense. Our predecessor Antoine Imboden has already collected a big dataset on the frontiers of Venice.  He has created a nice web app with a time slider which makes it possible to browse through Venice’ history and visualize the evolution of its frontiers. Further he has included frontier related text based information about each of Venice’ regions. His work was based on:

  1. the Euratlas data provided by Marc-Antoine Nüssli (Basics),
  2. work on venician colonies originally done by Dr. Mélanie Fournier (Domini da Mar),
  3. his own work using various sources (Domini di Terraforma).

Under discussion with Prof. Frédéric Kaplan we concluded that it would not make sense to redo this work and creating the same data by automating the digitization of historical maps. Dropping our original project forces us of course to find a new  idea and throws us back quite a bit in the project phase.

Searching for new ideas

Together with Professor Kaplan we brainstormed for new ideas on what to do. He was quite enthusiastic about Antoine’s existing work and especially about several ideas that were shaped on top of it. The big idea was to create a website out of the existing web application, where any user could log in and add new borders or cities to the map. This website could then be linked to Wikipedia, first to reference the GIS data to text information and second to attract more contributors. However, we didn’t come up with any concrete idea in this first week. We spent the remaining time of the semester’s first week and the second week searching for possible new projects:

  • Checking the accuracy of the data and improving details. The polygons that create frontiers in Antoine’s web app are not very exact (polygons overlap) and according to Isabella di Leonardo incomplete and partly incorrect. We would therefore check Antoine’s data, compare it with information from other sources and correct it. The product would be similar to the existing web app.
  • Migrating the existing information. Complying with Prof. Kaplan’s suggestions could be done in two ways:
    1. Setting the project up on its own website. We shortly brainstormed about creating a new website from scratch. We came though to the conclusion that this is too much work for the scope of this course.
    2. Using an existing historical map platform. The most prominent and most promising such platform is OpenHistoricalMap (OHM). The advantage of working with OHM instead of creating a page from scratch is that almost all the functionality is already implemented.
  • Research on Digital Historical Maps: Since we spent quite some time finding solutions to salvage our project plan, we got a good picture on digital historical maps and what their challenges are. One could imagine writing an overview paper on the state of the art in digital historical mapping.

New project proposal

After mail conversations with the OHM community and after our own discussions, we have decided to migrate the existing data to OpenHistoricalMap and to implement missing components in this promising open source project. In the next weeks we are going to focus on:

  1. Adding the existing information to the OHM database,
  2. Reviewing what has been done on the time slider,
  3. Documenting our experiences and findings online, so others can follow more easily,
  4. Maybe further deliverables as to be discussed with our TA.

Our timeline looks roughly as follows:

  • Until 1.4 (the next progress report): Have all available data imported into OHM. Have started working on OHM code that would be useful to us (e.g. slider).
  • Until 22.4 (the last progress report): Beta-Version of the code we supply to the OHM project is ready. Have a concept on what to present in the final presentation (since we can’t just show 2000 lines of code).
  • Until 13.5 (final report): Final version of a deliverable. Report written.