We are finished the fieldwork for Fayum 2010! Today we are in the house packing up and most importantly backing up. We have built a GIS during the course of the season but there are always clean up jobs to do at the end of the season. We spent last night going over the structure of the GIS making sure that the symbols we use to represent the various types of data we have recorded are consistent. Kane established a symbol set for the codes that we used to describe the surface sediments on the transects that we recorded. Tash reset the photo names for the transects so that we can implement dynamic links in the GIS. Josh took photos every 20m across the transects both EW and NS before logging began. These are filed for each transect along with all the other data we recorded at that location. The dynamic link means that anyone using the GIS can view these photos just by clicking an icon. It helps when we are back in NZ, the US and the Netherlands (project members come from all three countries) and need to remember what the locations we recorded looked like.
Because team members will be working on the data we gathered throughout the year it’s important that the GIS and associated folders of data are very well structured otherwise it will be a continual headache finding where we put a particular record. We have adopted an ‘object orientated’ approach. We have a small set of types of units that we have recorded in the field: the survey transects, hearths, grindstones, geomorphic sections. These are individually numbered and the data is structured so that every data record (total station survey, photo etc.) relevant tot that object is stored within the object folder. We use the GIS to integrate the different data types that we have collected – exploiting the database management function of the GIS. Because we are dealing with such a large area (the X1 region we worked in this season was 3km wide EW) a GIS is also essential for understanding spatial distributions.
Photographs are a critical part of our data acquisition and are one of the reasons that we amass such a large quantity of data during the season. We save high resolution photos because sometimes it is necessary to look at images in detail. The downside is that data backup takes some time – the master data files for 2010 are around 20 gigs. We also keep copies of the data that was downloaded from the various instruments we use. This means that if for some reason we found an error we could track back to the original data file where the error occurred. But we hope that we have found and fixed any errors in the field!
We backup onto several different machines and portable disks. The danger of data loss is an issue but can be overcome by making sure that there are lots of copies. We send the data back on a variety of different machines with people flying in different directions. Back in our various home universities the data is backed up again onto servers. This minimizes the threat of data loss to acceptable levels. We really have little alternative – given the type of data requirements needed for this project a ‘paper record’ would be impossible to create.