Protocol

Our conservation procedures at this site include another change of footwear for accessing and moving around the site, as well as the use of nitrile gloves for handling the remains. Documentation begins with a photographic record of the remains to be studied, followed by a detailed study and photogrammetry when necessary, ensuring the relocation and conservation of the objects in their original location. Access to the materials is by means of a retractable aluminum walkway (with a maximum extension of 2 m and a width of 35 cm) with padded bases to protect the ground and the archaeological remains. This allows us to avoid direct contact with the floor and fully preserve the site (Figure 3). In addition, a strict protocol for time spent in the area, limited to four continuous hours of work three days a week, was in line with the environmental control criteria at La Garma (Arias and Ontañón Reference Arias, Ontañón, Menéndez and Corchón2014; Arias et al. Reference Arias, González-Sainz, Moure-Romanillo and Ontañón2000, Reference Arias, Ontañón, Álvarez-Fernández, Cueto, Elorza, García-Moncó, Gaudzinski, Jöris, Sensburg, Street and Turner2011).

Figure 3.

Researcher working with the La Garma work protocols during our digital data collection system in the cave. Photograph courtesy of Carlos García-Noriega.

Microsoft Surface Pro-8 and Pro-9 tablets were used for the fieldwork; they provide perfect adaptability for fieldwork and robustness to draw vector-layer geometries and perform complex analyses with large files or datasets. The process of working with those devices consisted of identifying the element to be documented, drawing its geometric representation in the vector layer, and completing all the values or attributes for accurate documentation, before returning the archaeological object to its original location (Figure 4). At the same time, the record photographs were associated with the geographic information system (GIS) project through programmed actions, allowing access to them for each recorded element.

Figure 4.

Field documentation process utilizing a system based on QGIS and PostgreSQL.

Digital Conservation

Finally, an enormous effort has been devoted to the creation of more than 500 photogrammetric models of the study area and its archaeological remains. These models allow subsequent analysis, for example in the reassembly of lithic pieces (both in digital format and in physical format through 3D printing). This procedure is crucial for the preservation of fragile remains and also facilitates future research without the need to physically access the site. The high-precision photogrammetric models include the Palaeolithic structure I-A, the adjacent floors, the cave walls near structure I-A, graphic expressions, remains of osseous industry, ornaments, and lithics. All of these are stored as supporting material for the data collected in our database.

Spatial Database Configuration

PostgreSQL version 12.2 is used for data management. This allows us to operate both with graphical user interface (GUI) applications, such as pgAdmin, which greatly facilitate the process, and with a programming language to predefine and streamline the replication process (Figure 6).

Figure 6.

Workflow process for creating and configuring a PostgreSQL database.

The creation of a PostgreSQL database through pgAdmin begins with setting up a “Server Group,” to which we assign a name. This serves as a logical collection of servers, facilitating the organization and management of the servers and their databases. To do this, we select the option to create a Server Group in the “Object” tab.

Next, we register a “Server,” defined as an instance of the database that provides access to our configuration, by assigning it a name in the general attributes window. Additionally, we establish the connection location. Since we are working locally, we enter “localhost” or, alternatively, the local IP in the “Host” field. Finally, in this same window, we enter a password for our server, with the option to save it, depending on our preference for controlled access to the server.

The next step is to create the database and its internal structure using “Schemas” and “Tables.” We select “create database” on our server and start by entering the name of the database. We leave the default owner set to “postgres” and ensure that in the “Definition” section, the “Encoding” is set to UTF-8.

Once the database has been created, we begin its configuration. The first recommended step is to create an extension that will allow us to connect our database to a GIS platform. To do this, in the “Extension” section we enter “postgis” as the name. This enables us to connect our spatial database to a new GIS project.

We then proceed with the internal configuration by initially creating a schema or multiple schemas depending on our needs. The “Schema” functions as a logical collection of objects, grouping the internal components of a database such as tables, views, functions, et cetera, facilitating data access and management. To create it, we set a name and leave the rest of the configuration as default. With the “Schema” created, we proceed to create the “Tables.”

These “Tables” can be defined as data structures that organize our information into rows and columns, with each row being an entry or record and each column representing a characteristic or attribute of that record. We create the tables by going to the corresponding section within our “Schema.” In the “General” window we enter the name of the table, and in the “Columns” tab we create, one by one, the records we want to characterize for each archaeological remain (i.e., for the documentation of the data). The procedure consists of “add row” to generate a new attribute, where we enter the name and type of data to be recorded, with the ability to select from a multitude of formats according to our needs, such as various numerical values, alphanumeric, Boolean, and JSON, among others. It is also recommended to select “Primary key” if the values of a specific row must be unique in each case. For example, when creating an inventory number, this practice is highly recommended, as a number can never be repeated. Additionally, a spatial index for each table is also recommended as a key factor to speed up calculations or analysis with large datasets (Video 1).

In our project, we have created a table for each type of archaeological element, with geometries varying between points, lines, and polygons: Fauna, Lithic, Malacofauna, Osseous Industry, Ornaments, Art, Human Remains, Metallic Objects, Stratigraphic Units, Displaced Elements, Structural Elements, Natural Elements, Samples, and Dating. The choice of each geometry is adapted to our needs. For example, while archaeological remains represented as polygons (e.g., Fauna or Lithics) enable greater interaction in the analysis, other categories such as dating samples (point-based geometry) may require less interaction. Each table is formed by a series of attributes based on the specific survey methods for each type of remain. In other words, each of them acts as a specialized database that ensures the correct cataloging and documentation of the remains and the archaeological context.

This whole system defines the general basis for configuring and making a spatial database functional for connection to a GIS project. We have pre-established the entire process in structured query language (SQL) code to provide a base model to work with. This strategy aims to simplify the reproduction of the procedure and the creation of new models, given the flexibility of the design and its adaptation to each context and preference. The integration is performed in a GIS platform, which allows us to work with and capture vector and geospatial data. The software used is QGIS version 3.22 Białowieża, a robust and growing open-source project with a large community of developers (Video 2). However, it is worth mentioning that this same system can be applied to any version of QGIS 3.x onward.

Improvements: Lists and Records and Transects

In this stage of the process, we implemented several improvements to reduce human error and standardize a uniform method for data recording. Initially, typographical errors can occur during data entry. For example, if we have an attribute to record the physical state of an archaeological remain, which can be either “whole” or “broken,” typographical errors may compromise the homogeneity of the data. This could lead to subsequent errors during analysis and slow down the documentation process by requiring manual correction of the same attribute in each record.

To facilitate this process, lists of predefined values are created in the GIS platform. These lists are written in a simple code that we will save in CSV format, representing a table composed of two columns with an index value and its associated key value. Finally, these lists must be configured in both PostgreSQL and the GIS platform to ensure their correct functioning (Figure 7).

Figure 7.

Functionality of the lists created for documentation.

Creating these lists is a simple process. First, in a notepad, write the columns and rows, separating them with tabs, commas, or any other delimiters you prefer. You must include an index attribute and a value attribute. In the first column, enter the key value, which in this case is numeric, and in the second column, the corresponding attribute. Following the previous example, the second column will contain the attributes “whole” and “broken” in each row. Once these lists are created, they are integrated into the GIS project, which optimizes the cleanliness and efficiency of data collection.

First, we import each list in CSV format into QGIS. Then, we open the “Layer Properties” option and in the “Attribute Form” section, we select the control-type option “Value Relation.” This allows us to select the previously imported CSV layers and set the corresponding field for the index and value attributes in the associated fields (Figure 8). This process must be repeated for each list we have (Video 3).

Figure 8.

Workflow for creating lists.

Another improvement in our procedures is a novel documentation system that involves creating points and transects to position the documented elements. During the process, these points will be connected to transects, allowing us to clearly track the geolocation of the documentation and study process of the archaeological remains. This new part of the procedure is included as a fundamental tool for fieldwork and may inspire future improvements based on our proposed procedure (Figure 9).

Figure 9.

Workflow for creating triggers and trigger functions and their interaction.

The process we call Records and Transects is as follows: in PostgreSQL, we create a table called “Record,” which establishes the points that will record each documentation made with the tables created for this purpose, such as lithics, fauna, et cetera layers. In addition, we create a second layer called “Transects,” with line features that will represent the connections of the remains as we process the data. For this to work, we must create a “Trigger Function,” which contains the execution code for a “Trigger,” defined for each data table. It is important to understand that a “Trigger” is a mechanism that allows us to execute an action automatically in response to events occurring in our tables, serving as a useful tool to automate processes and maintain data integrity.

The first function, called “insert_record,” will automatically insert each record in point format once we have drawn in one of the vector layers of the archaeological remains, also saving the type of remains documented in its attributes. Then, for the transects, we create a second function called “generate_transect,” which will systematically join the points created with lines, facilitating a better understanding of the locations where we are processing the data (Figure 10).

Figure 10.

Process of creating points and transects for positioning documented elements in the archaeological site.

Once these triggers and functions are ready in our database, we can work on the GIS project with the aforementioned documentation system. As with the other tables, we only need to import the record and transect layers into our project and update the layer as we record data. In this way, we achieve an efficient system for controlling the geospatial documentation of our data (Video 4).

Multiple Users

All data are managed on a local server, ensuring the security of our data and simultaneous communication or work between multiple users, from a network connection, in our case GARMANET (Arias and Ontañón Reference Arias, Ontañón, Menéndez and Corchón2014). This network allows multiple users to work within the same local connection, but, for this to function correctly, one device must be established as the host. The other users can then connect to the server and access the corresponding database. This procedure can be easily done in the pgAdmin application. To do this, the device that wants to connect must access its connection configuration and, in “Host,” change the attribute “localhost” to the IP address of the device acting as the administrator. With this simple change, users can connect to the database, start their QGIS projects, and work simultaneously with other users (Supplementary Text 1).

Python

Finally, our digital method has been developed using Python (Python 3 version), an Object Oriented Programming language. We chose this language because of its great potential for data analysis, specifically for geospatial and geostatistical analysis. In addition, it stands out as a language on the rise, with a large community and a relatively easy learning curve. Its main advantages are that it allows code reuse and extension, as well as the creation of complex systems that facilitate teamwork (Figure 11).

Figure 11.

Working structure using Python with our data stored in a PostgreSQL database.

We provide a base model of our work with Python, organized in an application for storing, saving, and basic analysis of our data. This set of scripts is openly available in a GitHub repository, allowing execution, modification, and adaptation to other contexts or needs.

To run the application, we use a command console. Since we work with a Windows operating system, we use the system’s own console. For correct operation, we must first create a virtual environment. This allows us to establish a unique and secure project that is not affected by previous installations of packages or libraries from other projects. This practice is essential for the correct functioning of our scripts and is a common and practically obligatory practice in the programming world.

Once the virtual environment for our project has been created, we proceed to install the necessary libraries using the “pip install” command. The first library to install is psycopg2 or SQLAlchemy, which will allow us to connect to and access the data in our PostgreSQL database. Next, we install other libraries necessary for data management and analysis. In our case, these libraries are: pandas, numpy, geopandas, matplotlib, openpyxl, and scikit-learn.

Now we can proceed to execute our application. To do this, we simply run the main script, which organizes and calls the rest of the functions. The predefined tasks include querying the database, creating and saving a backup, and monitoring the state of the database, as well as frequent and basic geospatial analysis, such as estimating Kernel densities and creating maps of distributions (Figure 12).

Figure 12.

Connection to PostgreSQL database with Python and creation of a tool for data management.

This model serves as a predefined configuration and starting point, but can be modified and adapted to each specific case. All lines of code are open-source, allowing flexibility, permanence, and improvement over time of the procedure discussed in this research work (video 5).