Open Digital Data on Funerary Landscapes and Settlement Organisation in Pre-Roman Apulia: Monte Sannace and Vaste

Context

This paper presents the complete archaeological research data underlying the book chapter “Intra muros et extra: Funerary landscapes and settlement dynamics at Monte Sannace and Vaste in the fourth century BCE” [1]. It makes the “Intra muros et extra” (IMEE) dataset openly available and shares the project’s digital methodology.

The project examined the transformative period of late Classical and early Hellenistic Apulia through a detailed analysis of residential and burial spaces. In the late fourth to early third centuries BCE, rapid settlement growth, urbanization, the construction of fortification walls, and the infilling of the countryside reshaped the landscape of southern and central Apulia. These developments redefined relationships between residential and burial areas, producing significant yet locally varied changes in funerary landscapes. Focusing on Monte Sannace and Vaste as case studies, the book chapter [1] analyzed a qualitative and quantitative spatial dataset of 379 funerary features, contextualized within their settlements and broader surroundings through a comprehensive review of related scholarship [2] (Figure 1).

Figure 1

The selected sites are ideal for analysis, given their rich archaeological record, extensive documentation, and high-quality publications. As the communities in Apulia followed diverse, locally specific patterns when reshaping their residential and funerary landscapes, the sites only serve as test cases. They are considered a pilot study for scaling the analysis up to more than 40 fortified sites in the region which have a very heterogeneous state of research and are sometimes primarily known from grey literature.

The dataset presented here records 379 funerary features from Monte Sannace and Vaste, combining individual tombs and clustered funerary contexts in a single reusable table. Each record is identified by a unique numerical identifier (ID) and includes information on site, deposition type, tomb type, spatial setting, chronology, burial counts, mapping method and quality, notes, and bibliographic references. Of these records, 347 represent individual funerary features and 32 represent clustered features; 290 records belong to Monte Sannace and 89 to Vaste. The dataset further records 367 burials where dedicated counts are known, representing at least 474 buried individuals. These include 286 funerary features (at least 379 individuals) at Monte Sannace and 81 features (at least 95 individuals) at Vaste. 12 records (Monte Sannace: 4; Vaste: 8) have unknown counts because no values are published. In most cases, anthropological analyses, such as those concerning the minimum number of individuals buried, are missing. This is particularly problematic given the widespread reuse of tombs in the region. Spatial information is provided for 340 records, while the remaining 39 records are retained with NULL values to preserve the full evidentiary base. Supporting files include a data and value dictionary, CRS metadata table, KML derivative for visualization, and bibliography.

Spatial coverage (EPSG:4326)

Description: Monte Sannace and Vaste are both major archaeological sites in southern Italy, located in Apulia. Monte Sannace lies near Gioia del Colle in the Metropolitan City of Bari, while Vaste, also known as Vaste di Poggiardo, is situated near Poggiardo in the province of Lecce.

Temporal coverage

Both archaeological sites cover multiple periods from the region’s pre-Roman and Roman phases, with most of the residential and funerary data originating from the fourth and third centuries BCE. The presented dataset covers archaeological features from around 700/600 BCE to around 300/250 BCE. During this period, the region was inhabited by Italic communities known as the Peucetians in central Apulia and the Messapians in the south of the region. The dates provided are mostly based on typochronologies, primarily of pottery, and are taken from the excavation publications of the sites (for full references see the bibliography in the dataset).

Steps

We systematically collected cultural data based on the secondary literature and structured it in Excel/Microsoft 365 tables (in XLSX file format). To ensure sustainable data management, we established a well-organized file folder structure. In addition to our own data collection, we incorporated archaeological datasets from previous studies on Monte Sannace and Vaste. These datasets were kindly provided by the respective authors [6, 7] and served as valuable secondary data sources (infra). After documenting all identifiable tombs based on the secondary literature, we mapped these tombs as point data in QGIS using the qualitative data we had generated. Finally, we joined the spatial and qualitative data to generate the full IMEE dataset which has then been uploaded to Zenodo in CSV (and KML) format.

Quality Control

To ensure the accuracy and reliability of our dataset, we implemented rigorous quality control measures: We conducted repeatedly thorough checks and validations to examine the consistency and coherence of the data. We also repeatedly reviewed the cultural-qualitative tables to ensure that the information was accurately recorded and categorized appropriately. Throughout the process, we maintained detailed documentation of our quality control procedures and any adjustments made to the dataset.

Constraints

As secondary data [8], this dataset offers several benefits. It has already been collected, saving time and resources. It provides a broad geographic and temporal scope, enabling analyses that might not initially be feasible with primary data collection. However, users of this secondary data should also be aware of potential limitations: They have no control over how the data was initially collected, so they must trust the accuracy and reliability of the original source as mapped and analyzed by the respective authors.

Object name

1. README.md – overview of the dataset package, spatial data, conventions and recommended use.

2. IMEE_dataset.csv – consolidated primary table containing 379 funerary feature records from Monte Sannace and Vaste.

3. IMEE_dataset.kml – derivative KML file for visualizing the 340 spatially located records.

4. IMEE_data_dictionary.csv – field-level documentation for the primary table.

5. IMEE_value_dictionary.csv – explanations of controlled values and missing-value convention.

6. IMEE_coordinate_reference_systems.csv – metadata for the coordinate reference systems used in the dataset.

7. IMEE_references.bib – bibliography in BibTeX format.

8. IMEE_references_readable.csv – human-readable bibliography table.

9. IMEE_references_readable.txt – human-readable bibliography text file.

Data type

The central file is IMEE_dataset.csv, a CSV table containing the consolidated analytical dataset. It brings together in one main table the individual and clustered funerary contexts of Monte Sannace and Vaste. Each record is identified by a unique ID. The main table contains spatial, qualitative and quantitative archaeological information. The recorded fields include the site, deposition type, excavation or discovery year, feature number, tomb count, tomb type, spatial zone, sector and location, location quality, coordinate values, chronological information, dating method, burial count, burial-related notes, mapping method and bibliographic references.

Spatial coordinates are included directly in IMEE_dataset.csv. The source coordinate pair is provided in EPSG:3004, Monte Mario/Italy zone 2. To improve interoperability, the dataset also includes transformed coordinate pairs in EPSG:4326, WGS 84, EPSG:32633, WGS 84/UTM zone 33N, and EPSG:25833, ETRS89/UTM zone 33N.

The CRS names, datums, units, axis order and explanatory notes for these coordinate columns are documented in IMEE_coordinate_reference_systems.csv, another CSV file. The derived coordinate pairs were calculated from EPSG:3004 with pyproj/PROJ EPSG operations; numerical coordinate precision should therefore not be confused with archaeological location certainty, which is documented separately through the Location_quality and Mapping fields.

For missing data, the value NULL is used throughout the CSV files [9]. It marks values that are unknown or not applicable and should be treated as a literal missing-value marker, not as a textual observation.

IMEE_dataset.csv contains the following fields:

1. ID is the stable unique integer identifier assigned to each record. It harmonizes the former tomb, cluster and feature identifiers and allows each record to be referenced consistently across the dataset package.

2. Site identifies the archaeological site to which the record belongs. The values used are Monte Sannace and Vaste.

3. Deposition_type defines the analytical granularity of the record. It distinguishes between individually recorded funerary features and clustered features.

4. Year records the excavation, discovery or publication year as reported in the relevant source. The field is retained as text because some entries include approximate values, ranges or source-specific chronological formulations.

5. Feature_no records the original tomb number, feature number or label assigned in the source documentation or secondary literature. Where no such number is available, the value is recorded as NULL.

6. Tomb_count gives the minimum number of tombs represented by the row. Individually recorded features are counted as one, whereas clustered features retain the reported minimum number of tombs where this information is available.

7. Tomb_count_qualifier qualifies the value in Tomb_count. The value at least indicates that the recorded number is a minimum count rather than a complete or certain total. NULL is used where no qualifier is required or applicable.

8. Tomb_type describes the tomb or deposition type, where this information is available. The field records controlled textual values derived from the archaeological sources and may include values such as sarcophagus, cist grave, pit grave or other source-specific tomb forms.

9. Tomb_zone records the broadest spatial unit within the site. It is used for larger spatial divisions and is – within a simple hierarchical structure – treated as broader than Tomb_sector.

10. Tomb_sector records a more detailed, named sector, property, excavation area or sub-area within the broader zone. It provides a more precise spatial attribution where such information is available in the source material.

11. Tomb_location provides a specific location information either within a sector or zone, usually in the form of a descriptive reference to a particular place, plot, excavation context, street, building, property or mapped area.

12. Location_quality evaluates the spatial accuracy of each record according to a simple hierarchical structure. The value exactly located indicates a high level of accuracy, where the available source information allows the feature to be placed at or very close to its recorded position. Contextually located indicates a medium level of accuracy, where the feature can be assigned to a documented archaeological context, but not with feature-level precision; this placement has been mostly derived from broader descriptions or the overall archaeological context. Zonally located indicates a low level of accuracy, where only a broader zone, sector, or property is known. Conflicting information marks cases in which published spatial information is inconsistent across sources.

13. Monte_Mario_EPSG3004_Easting records the projected easting coordinate in EPSG:3004, Monte Mario/Italy zone 2. This is the source Gauss-Boaga coordinate pair used for the dataset. NULL indicates that no reliable point coordinate is available.

14. Monte_Mario_EPSG3004_Northing records the projected northing coordinate in EPSG:3004, Monte Mario/Italy zone 2. Together with the corresponding easting value, it forms the original projected coordinate pair.

15. WGS84_EPSG4326_Longitude records the longitude in EPSG:4326, WGS 84, expressed in decimal degrees. This coordinate is derived from the EPSG:3004 source coordinates and is used by the KML derivative.

16. WGS84_EPSG4326_Latitude records the latitude in EPSG:4326, WGS 84, expressed in decimal degrees. Together with the longitude field, it allows the data to be visualized in web-mapping environments and virtual globe applications.

17. WGS84_UTM33N_EPSG32633_Easting records the projected easting coordinate in EPSG:32633, WGS 84/UTM zone 33N. This value is derived from the EPSG:3004 source coordinates and supports reuse in widely supported GIS workflows.

18. WGS84_UTM33N_EPSG32633_Northing records the projected northing coordinate in EPSG:32633, WGS 84/UTM zone 33N. Together with the corresponding easting value, it provides a projected coordinate pair based on the global WGS 84 datum.

19. ETRS89_UTM33N_EPSG25833_Easting records the projected easting coordinate in EPSG:25833, ETRS89/UTM zone 33N. This value is derived from the EPSG:3004 source coordinates and is included for compatibility with contemporary European geodata workflows.

20. ETRS89_UTM33N_EPSG25833_Northing records the projected northing coordinate in EPSG:25833, ETRS89/UTM zone 33N. Together with the corresponding easting value, it provides a European-standard projected coordinate pair.

21. Date_start_BCE records the older boundary of the chronological range in BCE. Where composite source values were present, they were normalized and split into numeric start and end fields; the numeric value uses the first or older alternative where applicable.

22. Date_end_BCE records the younger boundary of the chronological range in BCE. It defines the later end of the normalized date range.

23. Date_phase records the broad chronological phase code assigned to the record. Multiple phase codes separated by semicolons indicate that the dating spans more than one chronological phase. The value 0 thereby indicates that no phase was assigned because the record is undated, too broadly dated or not documented. The value 1 refers to the earlier or pre-350 BCE phase used in the classification. The value 2 refers to the ca. 350–300 BCE phase. The value 3 refers to the later fourth- to third-century BCE phase. The value 4 refers to the later Hellenistic phase.

24. Dating_method records the basis on which the date was assigned; the value literature-based periodization means that dating derives from chronological interpretation reported in the cited literature. The value not documented means that no explicit dating information is recorded in the dataset. This is a categorical value, not a missing-value marker.

25. Date_note preserves the original composite dating information and any relevant normalization note. It functions as a transparent link between the source wording and the normalized numeric date fields.

26. Tomb_burials records the minimum number of buried individuals represented by the funerary feature or cluster. Age-related wording and uncertainty information are stored in Tomb_burials_note.

27. Tomb_burials_qualifier qualifies the value in Tomb_burials. The value at least marks a minimum number, while uncertain indicates that the burial count is not secure. NULL is used where no qualifier is required or where the number of burials is unknown or not applicable.

28. Tomb_burials_note preserves the original wording relating to burial count, age attribution or uncertainty. This field especially retains source-specific information that cannot be represented adequately as a simple numeric value.

29. Notes contains additional source notes, observations or contextual information that do not fit into the other structured fields.

30. Mapping describes how the spatial point was generated or why no point could be generated; the value located based on map means that the point coordinates were derived from a published map. Located based on orthophoto means that coordinates were generated through orthophoto interpretation. Roughly located based on map indicates an approximate point derived from a published map. Roughly located based on Carta archeologica indicates an approximate point derived from the officially published regional archaeological gazetteer. Exactly located based on Carta archeologica indicates that the feature could be placed precisely on the basis of the registry. Contextually located means that the point represents a more broadly documented archaeological context rather than the exact position of an individual feature. Not located means that no usable point coordinate is available. To be located marks records that were flagged for later georeferencing in the original data.

31. References contains short human-readable references for the record. Expanded bibliographic data are provided separately in IMEE_references.bib, IMEE_references_readable.csv and IMEE_references_readable.txt.

In addition to the main CSV table, the dataset includes IMEE_dataset.kml, a KML file for rapid spatial visualization in GIS software and virtual globe applications such as Google Earth. This derivative file contains the 340 spatially located records and uses the EPSG:4326 longitude and latitude columns. Each KML placemark uses the dataset ID as its identifier, includes a short descriptive name, and provides selected information from the main table in the placemark description. The KML file is intended for exploratory visualization and spatial orientation; however, IMEE_dataset.csv remains the authoritative analytical table.

Three further documentation files support interpretation and reuse of the tabular data: IMEE_data_dictionary.csv is a CSV data dictionary describing every field in the main table, including its meaning, expected format or controlled values, and relevant notes. IMEE_value_dictionary.csv, also provided as CSV, explains controlled values such as Date_phase, Location_quality, Mapping and Dating_method, and documents the NULL convention.

Bibliographic information is provided in three complementary forms: IMEE_references.bib is a BibTeX file containing the structured reference data used by the dataset and is intended for citation management and reproducible referencing. For easier reading outside reference-management software, the same bibliography is also supplied as IMEE_references_readable.csv in CSV format and as IMEE_references_readable.txt in plain text format. The CSV version allows the references to be filtered, searched or reused in tabular workflows, whereas the plain-text version provides a simple human-readable reference list.

Furthermore, README.md provides a detailed overview of the dataset package within the file set itself. Hence, it documents the spatial data, file-naming conventions, missing-value encoding and recommended use of the dataset.

Last but not least, there is a public group library available on Zotero. This serves as a centralized repository for storing and organizing references and sources related to the project. It enables multiple researchers to collaborate in managing and accessing the collection of references, thereby facilitating collaboration and knowledge sharing while ensuring that all interested researchers have access to the relevant literature and resources. The group library on Zotero therefore provides a convenient and efficient way to maintain a comprehensive and up-to-date collection of references for the IMEE dataset: https://www.zotero.org/groups/5069471/intra_muros_et_extra.

Format names and versions

BIB; CSV; KML; MD

Creation dates

From 21/12/2021 to 31/05/2026.

Language

English, Italian.

License

https://creativecommons.org/licenses/by/4.0/

Repository location

https://doi.org/10.5281/zenodo.20451742

Publication date

31/05/2026