Modelling the evolution of frontiers: Progress Report 2

Progress compared to project calendar
During a meeting with our assistent Olivier one week after our last blogpost, we have decided to again restructure our project, focusing on an EPFL open source historical map solution. We reached this decision because the open historical map project is quite extensive and therefore difficult to work on. Further Olivier has showed us what he is working on at the moment:
He is currently building his own cartographic time machine from scratch (only accessible from inside EPFL; Sourcecode here). His project suits very well with ours: thanks to the built in time slider it is possible to browse in time.

Further the way how he represents borders on the map is quite interesting: Every border is an entity on its own (e.g. “the border between Switzerland and France”). A country is then represented by the borders that surround it (e.g. Switzerland = {“the border between Switzerland and France”, “The border between Switzerland and Germany”, …}). This solution eliminates a problem that our predecessor had in his web app: He represented each region as a polygon and since the borders of two regions were not totally congruent, there were ugly gaps and overlappings between them.

Our task in Olivier’s project is to try to add the border data of our predecessor’s work and to provide the necessary tools (e.g. GUI to edit borders, script to import data) to do so. Additionally we want to keep an eye on the whole digital historical map field and connect it to our EPFL solution.

According to this new direction we redefined our goals for this second blogpost as follows:

  • A basic description and analysis of the database schema used
  • An estimate of what could be expected in the existing data import task
  • A mockup of the GUI that we will implement. It should show how we would allow to edit and enter borders into Olivier’s project.
We were able to finish all of these tasks thanks to regular meetings with Olivier and could (finally) clearly define reachable goals.
 
Intermediate Results
Database Schema and Documentation: A database analysis tool called schema spy helped us in generating a useful overview of the database that Olivier has been building and using. Here is the current relational structure:The Database Scheme of Olivier Dalang's Time Machine Map

The core parts of the DB are the entity and the properties table. An entity can be anything: it is just something that has properties. Properties are for example the entity’s shape (most important for us), but also its owner, its creator, its height, etc. Entities are timeless, but for each property the system calculates its start and end date, i.e. if a building was destroyed at some point in time, we just give it a new geometry property for that time (which would be empty in that case). This structure allows us to very flexibly define entities (whatever they may be) and describe their changes in time in the way needed.

Existing Data: The data of the frontiers in the work of our predecessor had been hardcoded in JavaScript. As we have access to this information, we can write a script that will parse the data of the frontiers and insert it into Olivier’s database.
The Website’s User Interface: As defined in the last goal for this blogpost, we thought about how to design an interface through which a user could edit existing entities or create something new on the map. We have drawn a series of mockups, which we have presented to Olivier. With his feedback we should now be able to implement a first version of the editor.
Mockup
An example view out of our mockup series
Next steps
We also redefine the next goals. Our timeline now looks roughly as follows:
  • Until 22.4 (the next progress report):

    • A first draft of the GUI and its features are implemented. The general structure stands and can be easily extended.
    • Our predecessor’s data has been inserted into Olivier’s database, such that we have frontiers to work with.
  • Until 13.5 (final report): Final version of a deliverable. Report written.
    • The GUI is functional, its code documented. The minimum funcitonality that the GUI should be able to provide is that a user should be able to create and edit the lines of a frontier.