========================================================================================== Title of Dataset: A Global Database of Nature-Based Carbon Offset Project Boundaries Date: 2024/06/05 ========================================================================================== Authors: - Akshata Karnik - Jack B. Kilbride - Tristan R.H. Goodbody - Rachael Ross - Elias Ayrey (Corresponding Author) ========================================================================================== Overview: Nature-based climate solutions (NBS) have become an important component of strategies aiming to reduce atmospheric CO2 and mitigate climate change impacts. Carbon offsets have emerged as one of the most widely implemented NBS strategies. However, these projects have also been criticized for exaggerating offsets. Verifying the efficacy of NBS-derived carbon offset is complicated by a lack of readily available geospatial boundary data. We detail methods and present a database of nature-based offset project boundaries. This database provides the locations of 575 NBS projects distributed across 55 countries. Geospatial boundaries were aggregated using a combination of scraping data from carbon project registries (n=433, 75.3%) as well as manual georeferencing and digitization (n=127, 22.1%). Database entries include three varieties of carbon projects: avoided deforestation, afforestation, reforestation and re-vegetation, and improved forest management. An accuracy assessment of the georeferencing and digitizing process indicated a high degree of accuracy (intersection over union score of 0.98 ± 0.015). ========================================================================================== Database notes: - Users must carefully distinguish between overall project areas and project accounting areas based on their specific analysis requirements. ---- The project area is defined as the geographical area where the project participants implement activities to reduce deforestation. ---- The project accounting area is defined as the geographical area of the project that was used to calculate carbon credit issuance. - This database does not represent a census of nature-based carbon projects and does not contain all varieties of nature-based carbon projects. - Users should verify that any georeferencing inaccuracies will not significantly impact their analyses. - The boundaries included in the database reflect the data available in the registries at the time of access, with some projects regularly updating their information. - We note that we were unable to assess the accuracy of the boundaries constructed from linear features or from a developer provided protocol. ========================================================================================== Database Schema Description: Each of the records in the GeoPackages that constitute the carbon project database contain the following attributes. ----- Project Name: The name of the carbon project as given in the documentation. ----- ProjectID: A combination of the registry abbreviation and project number. ----- Registry Name: The name of the registry where project information is hosted. Possible values are: American Carbon Registry, BioCarbon Registry, Climate Action Reserve, EcoRegistry, Gold Standard, Verra. ----- Methodology: The name of the methodology used for the project’s implementation. ----- Project Type: The type of forestry carbon offset program. One of the following: ARR, AD, IFM. ----- Country: The country where the project is located. ----- Project Developer Name: Name of the entity or individual organizing, proposing or advocating a particular carbon offset project. In case of multiple entities/individuals, only the first name is recorded here. ----- Project Start Date: Date of the start of the crediting period (mm/dd/yyyy). ----- Project End Date: Date of the end of the crediting period (mm/dd/yyyy). ----- Date of Entry: Date when the project information was added to the database (mm/dd/yyyy). ----- Processing Approach: One of four possible values: Official, Georeferenced, Linear, or Method. Official if the canonical boundary was obtained from a registry or the project developer. Georeferenced if the boundary data was obtained via georeferencing and digitizing maps obtained from the project documents. Linear if the boundary data were distributed as linear features that were processed into geometries. Method if a developer specified protocol was followed to obtain the boundary data. ----- PD Declined to Provide: One of: Yes, No, N/A. Yes if the project developer was contacted for the project geometry but declined to provide the necessary information. No if the project developer provided the geometries or sufficient information to create the project geometry. N/A if the geometry was available from a registry and the developer was not contacted. ----- Geometry Type: One of: Point or Polygon. Indicates if the geometry in the database is a point or a polygon. ----- Project Area: The well-known text (WKT) representation of the geographical area where the project participants implement activities to reduce deforestation. ----- Project Accounting Area: The WKT representation of the geographical area of the project which was used to calculate carbon credits. If the project area is the same as the project accounting area, then the project accounting area is not defined. ----- Project Reference Region: The well-known text (WKT) representation of the geographical area of the project from where historical and current deforestation and forest degradation quantities and trends are obtained. This is not always defined. ----- Comment: Notes about how manual referencing was carried out or other relevant information. ----- ========================================================================================== Manual Georeferencing & Digitization: Project boundaries were manually georeferenced using QGIS (v3.32.2). First, the map with the clearest boundary within the PDD was identified and overlaid on OpenStreetMap and Bing Satellite Imagery basemaps. Each map was then georeferenced with the basemap layers using at least 4 ground control points. The geometries depicted on the georeferenced map were then manually digitized. Digitized geometries were then consolidated into a single geospatial layer representing the project area or project accounting area. For nine projects, the project boundaries were distributed by registries as a set of linear features rather than polygons. If this was the case, linear geometries were processed to obtain the boundary data. To do so, the project’s linear features first were buffered by 30 m. Holes in the resulting geometry were then eliminated using the “Delete Holes” tool in QGIS. An inverse (i.e., negative) buffer of 29m was then applied to obtain the final polygon geometry. All geospatial boundaries were standardized to use geographic coordinates and the World Geodetic System 1984 datum (EPSG:4326). For six projects, the project boundaries were not available in the registry but a detailed description about how the project boundary was created was outlined in the PDD. We followed the steps mentioned in the PDD to recreate either the project area, the project accounting area, or both. Details include use of the ASTER Global Digital Elevation Model (GDEM) and the Copernicus Global Land Cover (CGLC) dataset. Lastly, for 42 projects, we were unable to derive a geospatial boundary due to insufficient information being available. For these projects, we were able to identify the general location of the project and related information such as the project type. In these cases, the project was entered into the database a point geometry. ==========================================================================================