EXPO Data Management History

Martin Green added the survtab.csv file to contain tabulated data for many caves around 1999, and a script to generate the index pages from it. Dave Loeffler added scripts and programs to generate the prospecting maps in 2004. The server moved to Mark Shinwell's machine in the early 2000s, and the version control system was updated to subversion.

Not all types of data could be stored in spreadsheets or survey files. In order a display descriptions on the webpage for an individual cave, the entire description, written in HTML, had to be typed into a spreadsheet cell. A spreadsheet cell makes for an extremely awkward HTML editing environment. To work around this project, descriptions for large caves were written manually as a tree of HTML pages and then the main cave page only contained a link to them.

A less obvious but more deeply rooted problem was the lack of relational information. One table named folk.csv stored names of all expedition members, the years in which they were present, and a link to a biography page. This was great for displaying a table of members by expedition year, but what if you wanted to display a list of people who wrote in the logbook about a certain cave in a certain expedition year? Theoretically, all of the necessary information to produce that list has been recorded in the logbook, but there is no way to access it because there is no connection between the person's name in folk.csv and the entries he wrote in the logbook.

The only way that relational information was stored in our csv files was by putting references to other files into spreadsheet cells. For example, there was a column in the main cave spreadsheet, cavetab2.csv , which contained the path to the QM list for each cave. The haphazard nature of the development of the "script and spreadsheet" method meant that every cave had an individual system for storing QMs. Without a standard system, it was sometimes unclear how to correctly enter data.

From " Troggle: a revised system for cave data management", by Philip Sargent and Aaron Curtis, CUCC [with some additions]. Original (2006) paper: " Troggle: a novel system for cave exploration information management", by Aaron Curtis.

This was a much bigger problem in the past than it is possible to imagine now (most of the early editing is done on an Acorn platform using !Zap). So much so that we have a separate page all about it: "Platform portability - making the website work widely".

Another important element of this system was version control. The entire data structure was stored initially in a Concurrent Version System repository, and later migrated to Subversion [now using git in 2020]. Any edits to the spreadsheets which caused the scripts to fail, breaking the website, could be easily reversed.

From the 2009 expo report:

This year's expedition also had a non-caving goal (not just drinking Gösser). Recently [since 2006] members of CUCC have started to develop a piece of software called Troggle, which aims to facilitate keeping track of logbook entries, typing up surveys, caves etc, and save time in a lot of the work that goes on behind the scenes when expo is over. This year was the first time Troggle would be tested "in the field" (well, spud hut).

After Expo 2009 the version control system was updated to a DVCS (Mercurial, aka 'hg'),

'because a distributed version control system makes a great deal of sense for expo (where it goes offline for a month or two and nearly all the year's edits happen)'.

The site was moved to Julian Todd's 'seagrass' server (in 2010), but the change from a 32-bit to 64-bit machine broke the website autogeneration code, which was only fixed in early 2011, allowing the move to complete.

By 2011 Troggle was under development with a wiki hosted on the CUCC server and we have a snapshot of the status in April 2011. As you can see, Troggle was still very incomplete in 2011.

The handbook was separate for a while until Martin Green added code to merge the old static pages and new troggle dynamic pages into the same site. This is now the live system running everything (in 2022). Work on developing Troggle further still continues (see Troggle intro).

The data was split into separate repositories: the website, troggle, the survey data, the tunnel data. 'Seagrass' was turned off at the end of 2013, and the site moved to a machine managed by Sam Wenham at the university computer service in Feb 2014.

Some text taken from " Troggle: a revised system for cave data management", by Philip Sargent and Aaron Curtis, CUCC [with some additions]. Original (2006) paper: " Troggle: a novel system for cave exploration information management", by Aaron Curtis.

In 2018 we had 4 repositories, 2 mercurial, 2 git

• loser - the survex cave survey data (hg)
• drawings - the tunnel and therion cave data and drawings (git)
• expoweb - the website pages, handbook, generation scripts (hg)
• troggle - the database/software part of the survey data management system - see notes on troggle for further explanation (git)

In spring 2018 Sam, Wookey and Paul Fox updated the Linux version and the Django version (i.e. troggle) to something vaguely acceptable to the university computing service and fixed all the problems that were then observed.

In early 2019 the university computing service upgraded its firewall rules which took the server offline completely.

Wookey eventually managed to find us free space (a virtual machine) on a debian mirror server somewhere in Leicestershire (we think). This move to a different secure server means that all ssh to the server now needs to use cryptographic keys tied to individual machines. There is an expo-nerds email list (all mailing lists are now hosted on wookware.org as the university list system restricted what non-Raven-users could do) to coordinate server fettling.

At the beginning of the 2019 expo two repos had been moved from mercurial to git: troggle and drawings (formerly called tunneldata).

The troggle software has been migrated to git, and the old erebus and cvs branches (pre 2010) removed. Some decrufting was done to get rid of log files, old copies of embedded javascript (codemirror, jquery etc) and some fat images no longer used.

The tunneldata repo has also been migrated to git, and renamed 'drawings' as it includes therion data too these days.

The loser repo and expoweb repo need more care in hg->git migration (expoweb is the website content - which is published by troggle). Loser should have the old 1999-2004 CVS history restored, and maybe Tom's annual snapshots from before that, so ancient history can usefully be researched (sometimes useful). It's also a good idea to add the 2015, 2016 and 2017 ARGE data we got (in 2017) added in the correct years so that it's possible to go back to an 'end of this year' checkout and get an accurate view of what was found (for making plots and length stats). All of that requires some history rewriting, which is best done at the time of conversion.

Similarly expoweb is full of bloat from fat images and surveys and one 82MB thesis that got checked in and then removed. Clearing that out is a good idea. I have a set of 'unused fat blob' lists which can be stripped out with git-gilter. It's not hard to make a 'do the conversion' script, ready for sometime after expo 2019 has calmed down.

Wookey has now moved 'expoweb' from mercurial to git largely "as-is". Mark Shinwell has said that he will help on the loser (survex files) migration to git.

In May we were on django 1.7 and python 2.7.17. Sam continued to work on upgrading django from v1.7 . We wanted to upgrade django as quickly as possible because old versions of django had unpatched security issues. [Upgrading to later django versions is a real pig - not helped by the fact that all the tools to help do it are now out of date for these very old django releases.]

• "Django 1.11 is the last version to support Python 2.7. Support for Django 1.11 ends in 2020." see: django versions. You will notice that we are really outstaying our welcome here, especially as python2.7 was declared dead in January this year.
• For a table displaying the various versions of django and support expiry dates see the django download page. Django 1.7 expired in December 2015. Django: full deprecation timeline.
• Ubuntu 20.04 came out on 23rd April but it does not support python2 at all. So we cannot use it for software maintenance (well be can, but only using non-recommended software, which is what we are trying to get away from).

We planned to upgrade from django 1.7 to django 1.11, then port from python2 to python3 on the same version of django, then upgrade to as recent a version of django as we could. But we have discovered that django1.7 works just fine with python3, so we will move the development version to python3 during June and then upgrade the server operating system from Debian stretch to buster before tackling the next step: thinking deeply about when we migrate from django to something else.

Enforced time at home under covid lockdown is giving us a new impetus to writing and restructuring the documentation for everything.