Since the 1980s, the computerization of archaeological projects has been pivotal in the evolution of the discipline. Initially, this process focused on the use of databases and statistical analysis. However, advancements in computing technology have led to the development of specialized workflows, encompassing everything from data collection to analysis (Dibble and McPherron Reference Dibble and McPherron1988, Reference Dibble and McPherron1997; McPherron and Dibble Reference McPherron and Dibble1987, Reference McPherron and Dibble2002). The adoption of free and open-source software (FOSS) has played a key role in this transformation, with initiatives such as Open-archaeo (Batist and Roe Reference Batist and Roe2023) facilitating the reuse and adaptation of tools and code within archaeological practice. Nevertheless, the lack of standardization in data management remains a significant methodological challenge, particularly regarding the preservation and accessibility of archaeological data (Colleter et al. Reference Colleter, Romain and Barreau2020; Gencheva Reference Gencheva2023; Reed et al. Reference Reed, Barr, McPherron, Bobe, Geraads, Wynn and Alemseged2015).
Technological advancements have significantly improved archaeological techniques, tools, and outcomes, steering the discipline toward noninvasive methods that safeguard heritage for future generations while ensuring research reproducibility (Arias and Ontañón Reference Arias, Ontañón, Menéndez and Corchón2014; Boyd et al. Reference Boyd, Campbell, Doonan, Douglas, Gavalas, Gkouma and Halley2021; Ellis Reference Ellis, Averett, Gordon and Counts2016; Galeazzi Reference Galeazzi2016; Rayne et al. Reference Rayne, Bradbury, Mattingly, Philip, Bewley and Wilson2017; Vandenbulcke et al. Reference Vandenbulcke, Van Ackere, Decock, Stal and De Wulf2016; Wallrodt Reference Wallrodt, Averett, Gordon and Counts2016). However, data management practices continue to vary considerably between research teams. Despite ongoing efforts to create and standardize these processes through FOSS-based systems (Reed et al. Reference Reed, Barr, McPherron, Bobe, Geraads, Wynn and Alemseged2015), the absence of a widely adopted universal solution continues to pose challenges (Ducke Reference Ducke2012; Holdaway et al. Reference Holdaway, Emmitt, Phillipps and Masoud-Ansari2019).
One of the main issues is that each research team tends to establish its own system for data collection, storage, description, and analysis. While this allows for adaptation to the specific needs of each team, it complicates the integration and long-term preservation of data for future use (Kansa and Kansa Reference Kansa and Kansa2021; Mandolesi Reference Mandolesi2009; Trimmis Reference Trimmis2018). Additionally, data digitization is often performed inconsistently or without consideration for long-term preservation, increasing the risk of losing valuable information (Reed et al. Reference Reed, Barr, McPherron, Bobe, Geraads, Wynn and Alemseged2015).
Free and open-source software introduces a new form of collaboration that, as Ducke (Reference Ducke2012) points out, promotes transparency, modification, and tool reuse. In today’s era of data science, it is crucial for archaeology to adopt large-scale data management practices that prioritize transparency and collaboration (Kansa and Kansa Reference Kansa and Kansa2021; Katsianis et al. Reference Katsianis, Tsipidis, Kotsakis and Kousoulakou2008). The goal is to maximize data reuse and facilitate collaboration among researchers by adopting open-source practices that emphasize transparency and adaptability throughout the workflow (Dibble and McPherron Reference Dibble and McPherron1988). Projects like Open-archaeo, which promote the use of free tools and software designed specifically for archaeologists, represent a key step toward democratizing data management (Batist and Roe Reference Batist and Roe2023, Reference Batist and Roe2024).
In this context, we propose a practical and accessible workflow that allows any researcher, regardless of technical expertise, to manage the digital data of their project. Our approach advocates for noninvasive archaeology and the use of free and open-source software, with the aim of establishing a standardized method for data collection and storage. This method seeks to minimize human error while prioritizing the conservation of archaeological remains. The proposed standardization does not aim to unify all procedures but rather to create a common foundation that facilitates interoperability and collaboration, as evidenced by recent FOSS initiatives (Batist and Roe Reference Batist and Roe2024; Dibble and McPherron Reference Dibble and McPherron1988).
We illustrate the effectiveness of this approach through its application in a specific case study: the Lower Gallery of La Garma (Cantabria, Spain). This site is ideal for the development of new digital techniques for the study, conservation, and dissemination of archaeological heritage. The case study provides an opportunity to create and test a standardized and accessible system. By applying our model at La Garma, we aim to evaluate its adaptability and applicability in a specific archaeological context, marking an important step toward fostering greater collaboration and advancement in this field.
The Lower Gallery of La Garma: Conservation and Noninvasive Methods
La Garma Hill, described as an elevation reaching 186 m asl, is located near the Bay of Santander, in the town of Omoño (Ribamontán al Monte, Cantabria). The karst complex in the hill is characterized by 13 sites that reveal a succession of occupations from the Lower Paleolithic to the Middle Ages (Arias and Ontañón Reference Arias, Ontañón, Bergsvik and Skeates2012; 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, Reference Arias, Gutierrez Cuenca, Hierro Gárate, Etxeberria, Herrasti, Uzquiano, Bergsvik and Dowd2018; Cueto et al. Reference Cueto, Camarós, Castaños, Ontañón and Arias2020). The record includes a set of rock art with more than 500 graphic expressions, floors full of archaeological artifacts, and remains of anthropic structures, the result of the activities carried out at the site. Given its scientific and cultural relevance, La Garma was included in the UNESCO World Heritage List in 2008 (Arias and Ontañón Reference Arias, Ontañón, Menéndez and Corchón2014; Ontañón et al. Reference Ontañón2008).
The most outstanding part and central object of this methodological case study is a section of the karst system currently known as the Lower Gallery. This site, at an altitude of 55–58 m, is a cave passage 300 m long. The particularity of this site is that its original entrance was closed at the end of the Pleistocene, in about 14,500 cal BC in the Middle Magdalenian (Arias Reference Arias2009; Arias et al. Reference Arias, Ontañón, Álvarez-Fernández, Aparicio-Alonso, Chauvin-Grandela, Conte, Cueto, Bicho and Corchón Rodríguez2005; Ontañón Reference Ontañón2003), so that all the prehistoric remains were left on the surface in an excellent state of preservation, thanks to the cessation of sedimentation and postdepositional processes (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; Cueto et al. Reference Cueto, Camarós, Castaños, Ontañón and Arias2020; Ontañón Reference Ontañón2003). At present, access to this part of the system is via two 7 and 15 m shafts, located in other sections of the karst complex called La Garma A and the Intermediate Gallery (Figure 1).
Figure 1. Location and mapping of the La Garma karst complex (Spain).
La Garma is an exceptional example of a unique conservation context. Since its discovery in 1996, the team has worked to protect the archaeological area, facing a double challenge: documenting an extensive set of archaeological remains and ensuring their conservation (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; Cueto et al. Reference Cueto, Camarós, Castaños, Ontañón and Arias2020). This project integrates research, conservation, and dissemination, working with noninvasive techniques to minimize the impact on archaeological floors, remains, and structures (Arias and Ontañón Reference Arias, Ontañón, Menéndez and Corchón2014). The goal is to avoid remanipulating the archaeological remains, site, or its context once it has been properly documented.
A fundamental conservation protocol begins at the entrance to the site, where sterilized footwear is used to prevent the entry of organic matter or microorganisms. In addition, a narrow path, walkways, and other facilities have been marked to protect the prehistoric floors, and these measures are complemented by sensors for climate and environmental monitoring (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; Martin-Pozas et al. Reference Martin-Pozas, Fernandez-Cortes, Cuezva, Jurado, Gonzalez-Pimentel, Hermosin and Ontañon2024; Sanchez-Moral et al. Reference Sanchez-Moral, Jurado, Fernandez-Cortes, Cuezva, Martin-Pozas, Gonzalez-Pimentel, Ontañon and Saiz-Jimenez2021).
Our documentation work prioritizes in situ study to minimize the manipulation or extraction of remains and protect their archaeological context, although this implies a slower process (Arias and Ontañón Reference Arias, Ontañón, Menéndez and Corchón2014). Therefore, the need to develop an efficient data collection, storage, and analysis system has led us to create an integrative model, which takes advantage of digital technologies such as photogrammetry, laser scanning, total station, and GPS, among others. The current challenge is to integrate these data into an accessible management system that facilitates their use by any researcher in the field or in the laboratory (Galeazzi Reference Galeazzi2016; Kansa and Kansa Reference Kansa and Kansa2021), while maintaining our goal of minimizing intervention at the site once an archaeological element has been documented.
Digitization and Conservation in the Context of the Study
In the Lower Gallery of La Garma, our case study focuses on Structures I-A and I-C (Figure 2). Both are located in Zone 1, about 40 m from the original entrance to the cave. I-A, with a surface area of 5 m2, is a Paleolithic habitation structure, with a subcircular floor plan, formed by speleothems and limestone blocks, located under an overhanging roof 1.6–1.7 m high. Its floor is covered by very dense concentrations of archaeological remains dating from the Magdalenian period. In turn, Area I-C is a natural chamber of about 11 m2, which houses vestiges of activities, with a notable predominance of graphic expressions, such as paintings and engravings (Arias et al. Reference Arias, Ontañón, Álvarez-Fernández, Cueto, Elorza, García-Moncó, Gaudzinski, Jöris, Sensburg, Street and Turner2011; Ontañón Reference Ontañón2003).
Figure 2. Orthomosaics of structures I-A (left) and I-C (right) for analysis.
The documentation of these spaces has been carried out cooperatively by three members of the team, using a shared server that allows multiple users to work simultaneously on the same project. In this sense, La Garma presents enormous technical challenges, as it is a cave. However, the problem of setting up a network connection that allows access to the server was solved with the installation of the GARMANET communications system in 2007–2008, facilitating the creation of a LAN network that allows connections both inside and outside the cave (Arias and Ontañón Reference Arias, Ontañón, Menéndez and Corchón2014).
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.
Workflow
The main challenge at La Garma is the preservation of the archaeological context, which limits freedom of movement and complicates work and data collection. Our solution, which adopts noninvasive techniques, begins with the construction of a raster archive documenting the entire site. Since 2012, in collaboration with the firm GIM Geomatics, we have produced a high-resolution giga-orthoimage. This was achieved through a combination of photogrammetry and terrestrial laser scanning, using a FARO Photon 120 3D laser scanner and two cameras, a Hasselblad CF-39 and Sony NEX-7. The whole process was performed with a system of poles and cranes that avoided direct contact with the archaeological floors (Arias and Ontañón Reference Arias, Ontañón, Menéndez and Corchón2014).
The information was processed with our own software, developed by GIM Geomatics, which grants full freedom over the rights of our products. The result is a product of the highest quality for the documentation and study of the archaeological remains on the surface, reaching a resolution of 200 microns (Figure 5). This has allowed us to accurately characterize a vast extension of Paleolithic surfaces, resulting in a reliable document for the conservation and dissemination of the archaeological heritage in the cave (Arias and Ontañón Reference Arias, Ontañón, Menéndez and Corchón2014). The objective of this photogrammetry is to provide a reference raster layer for a GIS platform to identify the archaeological remains recorded in the field. On this layer, we draw the vector geometries and record each analyzed remain, obtaining a georeferenced product that allows precise field location. Additionally, this procedure accurately locates each piece and allows us to extract XYZ coordinates when integrated with other products, such as a digital elevation model (DEM).
Figure 5. Giga-orthoimage with 200-micron resolution of Zone 1 in the Lower Gallery of La Garma.
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).
Video 1. Creation of PostgreSQL database in pgAdmin.
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.
Video 2. Connectiong PostgreSQL database to GIS system (QGIS).
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.
Video 3 Creation and configuration dropdown lists for QGIS.
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).
Video 4. Records and transects.
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).
Video 5. Connecting PostgreSQL database with Python and execution scripts.
Toward Standardized Data Collection
Technological innovations have transformed archaeology, allowing for the storage and analysis of large datasets and prompting a rethink of both field and laboratory practices (Boyd et al. Reference Boyd, Campbell, Doonan, Douglas, Gavalas, Gkouma and Halley2021; Calzado-Martínez et al. Reference Calzado-Martínez, García-Fernández, Ortega-Alvarado and Feito-Higueruela2023; Stamnas et al. Reference Stamnas, Kaimaris, Georgiadis and Patias2021). These advances have improved documentation and conservation management by offering a new approach to efficient data storage and collection, while also adapting tools from other disciplines to archaeological work (Batist and Roe Reference Batist and Roe2024; Galeazzi Reference Galeazzi2016; Neubauer Reference Neubauer2004; Rayne et al. Reference Rayne, Bradbury, Mattingly, Philip, Bewley and Wilson2017). Despite the progress, significant challenges remain regarding standardization and process integration within digital archaeology (Colleter et al. Reference Colleter, Romain and Barreau2020; Reed et al. Reference Reed, Barr, McPherron, Bobe, Geraads, Wynn and Alemseged2015).
One of the most significant efforts in this regard is the Open-archaeo project (Batist and Roe Reference Batist and Roe2023, Reference Batist and Roe2024), which has driven the creation and reuse of open-source tools and code specifically designed for archaeology. This approach fosters collaboration between developers and users, allowing these tools to be adapted to varied archaeological contexts. In this sense, FOSS solutions in archaeology offer an alternative development model that emphasizes the reuse and adaptation of tools to meet specific needs (Reed et al. Reference Reed, Barr, McPherron, Bobe, Geraads, Wynn and Alemseged2015). Although progress has been made in creating applications and plug-ins that address particular needs (Brovelli and Magni Reference Brovelli and Magni2003; Cosmas et al. Reference Cosmas, Itegaki, Green, Joseph, Van Gool, Zalesny, Vanrintel, Arnold, Chalmers and Niccolucci2003; Couillet et al. Reference Couillet, Rougier, Todisco, Marot, Gillet and Crevecoeur2022; Eichert Reference Eichert, Börner and Uhlirz2014; Gencheva Reference Gencheva2023; Martínez-Carrillo et al. Reference Martínez-Carrillo, Ruiz-Rodríguez, Mozas-Martínez and Valderrama-Zafra2009; Nigst et al. Reference Nigst, Viola, Antl-Weiser, Neugebauer-Maresch and Owen2010; Sauer Reference Sauer2023), the inherent lack of flexibility in many of these solutions can limit their long-term applicability.
A notable example of this issue is OpenDig (Vincent et al. Reference Vincent, Kuester and Levy2013, Reference Vincent, Kuester and Levy2014), a tool designed for the recording, editing, and publication of archaeological data. Despite its functionalities, its popularity has been limited, probably due to a lack of updates and the emergence of more adaptive and modular alternatives. Similarly, pyarchinit (Cocca and Mandolesi Reference Cocca and Mandolesi2016; Mandolesi Reference Mandolesi2009; Montagnetti and Mandolesi Reference Montagnetti and Mandolesi2020), a plug-in that represents a methodological approach closely aligned with our proposal, addresses the problem of coordination in data management methods, promoting integration, stability, and ease of updating within a predefined model. While we recognize the value of this solution, unlike its authors we believe that the diversity of procedures should not be seen as a barrier but rather as an opportunity to enrich methodologies applied in different archaeological contexts. Each case study has unique needs, as do the researchers. Rather than imposing a unification of procedures, we propose developing a common base that allows for interoperability and data exchange (Batist and Roe Reference Batist and Roe2023, Reference Batist and Roe2024; McPherron et al. Reference McPherron, Harold L., Deborah, Posluschny, Lambers and Herzog2008). Our methodology therefore is based on the principles of flexibility and adaptability, as demonstrated by Batist and Roe (Reference Batist and Roe2024), enabling users to modify and expand tools according to emerging needs.
With this objective, we have developed a methodology that prioritizes collaborative work, allowing multiple researchers to participate simultaneously in the investigation. At the same time, human errors are minimized through the automation of data recording via lists, ensuring the homogenization and consistency of information for future use. The implementation of real-time documentation systems based on data geopositioning (Records&Transect) not only simplifies a complex problem but also allows for continuous improvements, such as the use of GPS positioning systems, which increases the accuracy and adaptability of the system over time (Dibble and McPherron Reference Dibble and McPherron1988; Ducke Reference Ducke2012).
Instead of developing libraries or plug-ins that tend to become obsolete, we propose a protocol and an open-source application that facilitate the management and analysis of archaeological data. This approach ensures the reproducibility, extension, and permanence of the procedure over time, supported by an active community of users and developers (Batist and Roe Reference Batist and Roe2024). The ultimate goal is to provide methodological tools that allow users to create their own systems, tailored to their specific needs, promoting the permeability of knowledge and the adoption of open digital techniques (Batist and Roe Reference Batist and Roe2024; Holdaway et al. Reference Holdaway, Emmitt, Phillipps and Masoud-Ansari2019). This simple yet flexible methodology guarantees the longevity and efficiency of the procedure (Colleter et al. Reference Colleter, Romain and Barreau2020; Dibble and McPherron Reference Dibble and McPherron1988), consolidating itself as a robust and adaptable alternative to proprietary and less flexible solutions. It offers an economically and technically accessible solution to any researcher, regardless of their level of expertise, allowing for the complete integration of existing data and its adaptation to new research contexts.
Conclusions
The process we have described in this work shows remarkable efficiency in the task of documentation and conservation of archaeological remains, obtaining accurate and fast results in the capture, storage, and analysis of data. Although we have used both SQL and Python in our project to streamline the processes of database creation and configuration, connection, access, and data analysis, these technologies are today accessible owing to the development of intuitive interfaces. This allows us to fully reproduce the project described here without the need for extensive computer or programming knowledge.
The increasing utility and cost-effectiveness of generating high-precision, high-quality raster products from photogrammetry or laser scanning makes this approach viable for any researcher or team. In addition, the availability of creating a database and connecting it to a GIS platform with open-source software significantly reduces costs, as there is no need for often expensive licences.
The fact that this approach is based on open-source software with strong and active communities, such as QGIS, PostgreSQL, or Python, creates sufficient confidence that our digital data will endure over time. It also allows for continuous improvement and adaptation of the method to different cases and contexts. This case study represents a first step toward an open-source methodological community in the archaeological discipline, focused on data collection and storage.
We conclude with an analogy that summarizes our work: the previous approaches use tools to generate a finished product that the user can consume, while we provide the tools necessary for users to create their own consumer products. This subtle difference underlines the importance of true permeability of knowledge and the application of digital techniques in archaeology. The essence of open source lies precisely in this democratization of knowledge, as well as in the ability of users to actively participate in the creation of content that contributes to collective growth.
Acknowledgments
We would like to thank Luis C. Teira for his assistance with the preparation of the figures and Peter Smith for his help with the translation and review of the manuscript.
Author Contributions
Carlos García-Noriega (Conceptualization: Lead; Formal analysis: Lead; Investigation: Lead; Methodology: Lead; Software: Lead; Visualization: Lead; Writing – original draft: Lead; Writing – review & editing: Lead) Rodrigo Portero (Formal analysis: Equal; Investigation: Equal; Writing – review & editing: Supporting) Alba Ruiz-Cabanzón (Formal analysis: Equal; Investigation: Equal; Writing – review & editing: Supporting) Roberto Ontañón (Writing – review & editing: Supporting) Pablo Arias (Writing – review & editing: Supporting)
Funding Statement
This work was supported by the Ministry of Culture and Sport of Spain under Grant PID2020-112832RB-I00.
Data Availability Statement
The code used for the development and implementation of the digital methods described in this article is currently hosted in a private GitHub repository: https://github.com/Garmaproject/Garma.git. The repository will be made publicly available upon publication of this article. Until then, access can be granted upon reasonable request to the corresponding author.
Competing Interests
All the authors certify that they have no affiliations with or involvement in any organization or entity with any financial interest or nonfinancial interest in the subject matter or materials discussed in this manuscript.
Supplementary Material
The supplementary material for this article can be found at https://doi.org/10.1017/aap.2024.44.
Supplementary Text 1. Details on setting up connection parameters, securing remote connections, and best practices for managing multiple users accessing the same PostgreSQL database.
Open access
