Introduction

The Intergovernmental Science-Policy Platform on Biodiversity and Ecosystem Services (IPBES) is an independent intergovernmental body, established by member States in 2012. It provides policymakers with objective scientific assessments about the state of knowledge regarding the planet’s biodiversity, ecosystems and the benefits they provide to people, as well as the tools and methods to protect and sustainably use these vital natural assets.

Our mission is to strengthen knowledge foundations for better policy through science, for the conservation and sustainable use of biodiversity, long-term human well-being and sustainable development. To some extent IPBES does for biodiversity what the IPCC does for climate change.

Contributing

If you spot a problem, send us a pull request to fix it! If you're not sure how, you can also file an issue and we'll try to get to it ourselves.

In order to maintain a consistent style and voice throughout our documentation please try to follow these standards and conventions when filing Pull Requests against our documentation.

Markdown

• All files should end in .md. They should be all-lower-case and match the title of the page, or in some cases an abridged version of it.

• All pages should start with a title, denoted with # (first level header).

• Subsections within a page are encouraged, and should use ## for a 2nd level and ### for a 3rd level. Do not have more than 3 levels of header.

• Inline code statements, file names, and keys that would appear in a file should use backticks like this `.

• Always use inline links.

• Do not hard-wrap prose text. Set your text editor to soft wrapping.

• Internal links should be absolute (starting with /) and link to a file ending in .md, not .html. That makes them easier to find when needed to update.

Language usage

• All documentation should be written in English.

Getting help

If you're facing any issues with IPBES IT services and tools, please send an email to mea-ipbes-registration@un.org.

You can also reach us through the relevant technical support units of assessments or task forces

Address

IPBES Secretariat

10th floor

Platz der Vereinten, Nationen 1

53113 Bonn (Germany)

Zenodo

Summary

The task force on knowledge and data developed a series of short videos called, "The IPBES Data Management Tutorials" to help experts implement the IPBES data management policy. They cover topics ranging from data management policy, reports, active research data, tools, and examples.

The series includes the following chapters:

1. • Provides an overview on data management within the IPBES platform, and the series of the tutorials prepared by the task force on knowledge and data that will assist experts with the implementation of the IPBES data management policy.

2. • Provides an introduction of the IPBES data management policy. It discusses why IPBES has a data management policy and who is responsible for what in the implementation and further development of this policy.

3. • Provides an overview and discussion of specific elements of IPBES data management reports.

4. • Provides an introduction for IPBES experts on how to manage data while actively being used, analyzed, and produced to fulfill the criteria of the IPBES data management policy.

5. • Provides IPBES authors with an overview of open source tools used frequently by the scientific community to help it implement data management for the entire data life cycle.

Access the content

Prepared by Renske Gudde - IPBES Technical Support Unit (TSU) for Knowledge and Data and Rainer M. Krug - IPBES Task Force on Knowledge and Data. Reviewed by Aidin Niamir and Yanina V. Sica - IPBES Technical Support Unit for Knowledge and Data and the IPBES Task Force on Knowledge and Data (Hanno Seebens and Xubin Pan)

Version: 1.1 Last Updated: 27 February 2024

The IPBES assessment process is a lengthy and complex process, spanning over multiple years and involving many contributors and products. It is therefore important to easily track and find files related to the assessment. Here, an IPBES specific file name scheme for the assessments is being proposed.

Files used in IPBES should be named in a consistent and standardised way, while simultaneously informing about the content of the file, to avoid file loss and increase findability of the files, transparency of the final assessments, and reusability. For example, using the filename Fig3.8 or ILK dialogue meeting Asia seems to be informative, but when a user is interested in ILK dialogue meeting reports, it is unclear from which assessment the report comes and when the dialogue meeting took place, and when a user finds ‘Fig3.8’ in the download folder on their computer, the file name does not provide any indication of the contents and topic of that file. Having a standardised way to create file names improves the transparency and findability of information, and also avoids file names like DMR_systematic_review_final_final_JS_final_approved.

Apart from human understanding, the possibility to parse the file names automatically and deduce information about the file is an important second aspect of the naming conventions.

The recommended naming of files is built up in a similar way as the IBAN codes used by banks, and the proposed file name convention for IPBES products is:

IPBES_[assessment abbreviation]_[chapter]_[document type]_[short description]_[version]

In detail: All sections are required to be filled in.

IPBES: The acronym IPBES should be always present (in capital letters)

[assessment_abbreviation]: the abbreviation of the assessment as was approved during the scoping of the assessment, e.g., IAS for invasive alien species, NXS for the Nexus, TCA for transformative change and BBA for business and biodiversity (in capital letters).

[chapter]: chapter and subchapter number or “SPM”, e.g. “Ch5.2”. This is an optional field; if there is no chapter, use “__” (i.e. two underscores) to keep the file name machine readable.

[document_type] The kind of document it is (e.g., a meeting report, chapter or dataset). Suggested are the following types (a complete list is maintained by the data tsu):

[short_description] should describe the document in preferably 1-5 words (e.g., “dialogue Asia”, “systematic review topic chapter”). Clear descriptions are much easier to use than ambiguous ones, so when it is not possible to add a description in 1-5 words, it is recommended to use more words.

[version] Version in the format as described in the versioning scheme for IPBES products. The version number indicates at which state in the assessment a file was uploaded. It is therefore important to upload a new version (with updated version in the file name) at every milestone. Access to previous versions can be restricted in order to avoid confusion.

The sections are separated with “_”, and multiple words within a section can be separated with “ ” (space).

Examples

Figure

The final, interoperable, version of figure 3.6 that will be submitted to the Plenary, the phylogeny of marine mammals, of the Sea life assessment:

→ IPBES_SLA_Ch3_figure_fig 3.6_Phylogeny of marine mammals_v10.0.0.ai

Figure 7.8 showing the biodiversity hotspots on a global map, that will be submitted for the second external review as part of chapter 7 of the Hotspots assessment:

→ IPBES_HA_Ch7_figure_fig 7.8 Global biodiversity hotspots_v2.0.0.png

Table

The final version of table 5.4 that will be submitted for the first order draft for the Sea life assessment, containing a list of endangered marine animals:

→ IPBES_SLA_Ch5_table_Table 5.4 Endangered marine animals_v1.0.0.docx

Table 7.11 showing the number of endangered species in biodiversity hotspots, that will be submitted for the third external review as part of chapter 7 of the Hotspots assessment:

→ IPBES_HA_Ch7_table_Table 7.11 Endangered species in hotspots_v3.0.0.docx

Data Management Report

The first data management report for figure 4.1 of the invasive alien species assessment, uploaded to Zenodo before the submission for the first external review, would be:

→ IPBES_IAS_Ch4_DMR_Fig4.1 biodiversity versus water quality_v0.0.0.docx

The version of the data management report for figure 7.8 on the biodiversity hotspots map for the Hotspots assessment that will be submitted for the second external review as part of chapter 7 of the Hotspots assessment:

→ IPBES_HA_Ch7_DMR_Fig7.8 biodiversity hotspots map_v2.0.0.docx

Meeting report

Report about the third meeting to advance the summary for policymakers of the Sea life assessment:

→ IPBES_SLA__meeting report_Third SPM meeting_v1

Dialogue Workshop Report

The third version of a report on the dialogue meeting for Asia taking place after the second external review would be of the MR assessment:

→ IPBES_MR_dialogue__dialogue report_Asia_v2.0.3.zip

Dataset

The references found during a systematic literature search on ILK and nature conservation for the Hotspots assessment:

→ IPBES_HA__Dataset_References systematic literature search ILK and nature conservation_v1

Objectives

The data and knowledge management policy serves to ensure that data and knowledge is managed correctly and consistently throughout IPBES, and is maintained to the highest possible standard. Specific objectives include the following:

• To ensure that data and knowledge produced during IPBES research activities, within assessments as well as assessment overarching, follow the FAIR and CARE principles;

• To ensure inclusivity and benefit sharing at all stages of the creation and distribution of IPBES products as well as access of all involved stakeholders and producers to the final IPBES products;

• To provide a framework for all IPBES entities, including technical support units and experts, to fulfil their responsibilities with respect to management, handling, preservation, and distribution of data and knowledge and generated data within the platform;

• To guide the experts to fulfil their responsibilities to develop one or more data and knowledge management reports which fulfil the requirements of this policy;

• To provide a suggested workflow for long term storage and preservation of IPBES products to the experts;

• To promote the usage of open-source software to enable users to recreate and use IPBES products without limitations

Principles

• Open science: promotes the generation of knowledge through collaboration based on free and open access to knowledge, information, and data

  • Accessibility: the free and open access to its deliverables and to the material on which they are based

  • Inclusivity and benefit sharing: the co-operation in research and acceptance of the resulting products

Highlights

• Includes the full incorporation of indigenous and local knowledge throughout the policy

• Includes the requirement that IPBES products follow the FAIR and CARE principles

• Details specific provisions on reporting as well as accessibility, inclusivity, and benefit sharing

• Contains inputs and feedback from all Task Forces in IPBES

• Covers wide range of disciplines and different types of data

• Defines responsibilities and roles

• Includes commitment to support experts to follow the policy and to adopt their own data management reports

• Promotes transparency and reproducibility

Contact

Prepared by Renske Gudde - IPBES Technical Support Unit (TSU) for Knowledge and Data and Rainer M. Krug - IPBES Task Force on Knowledge and Data. Reviewed by Aidin Niamir and Yanina V. Sica - IPBES Technical Support Unit for Knowledge and Data and the IPBES Task Force on Knowledge and Data (Hanno Seebens and Xubin Pan)

Version: 1.0 Last Updated: 16 October 2023

Benefit sharing, by giving credit to those who contribute by properly acknowledging them, is important within IPBES. It is therefore important that the technical support units for assessments compile accurate information on the experts and maintain such information in a transparent and comprehensive manner.

The General Data Protection Regulation (GDPR)

In compliance with the GDPR, IPBES ensures to collect the minimum personal data that is required to guarantee that each expert and contributor is properly and sufficiently acknowledged. The information required is therefore: full name; preferred name which will be used in the citation or acknowledgement; title; gender; country of nationality and country of residence (if different); email address, and, optional, an ORCID iD.

• Name: Last name; first name; full name and preferred spelling of name (if different from the full name, for example, when Peter John Smith prefers to be called John Smith, or when authors prefer their names without the original accent marks).

• Affiliation: The complete affiliation(s) of the expert that are relevant to their IPBES contribution. For example, when an experts works for a specific lab or department at the School of Biological Sciences of the University of Edinburgh, the affiliation would be: University of Edinburgh, Edinburgh, United Kingdom. If an expert has more than one affiliation, these should all be added.

• Email: Any email address, work related or private (preferably both), which is the preferred way of IPBES and/or assessment related communication

The assessment technical support unit has to submit the list of experts to the secretariat to add them to the internal expert database and avoid duplication and different personal details. To ensure data protection and privacy protection, each assessment should have their own expert dataset, containing only the experts involved in that assessment.

Roles and responsibilities

Secretariat:

• assigns the expert id to the experts upon their first role within IPBES

• keeps the experts database up to date and available to the technical support units for the assessments

• answer any questions that may arise about data protection

Assessment TSU:

• Before each submission of a draft, confirm with the authors that all details are still correct.

Lead Authors:

• make sure that all authors and new contributing authors and other contributors are communicated to the Assessment TSU

TSU for data:

• include a section on the GDPR and the way that personal data is collected, handled and stored in the IPBES data and knowledge management policy, and making sure that this information is regularly updated with any updates on the GDPR

Authors / Experts:

• ensure that all your information is correct and complete, and that any updates and changes are communicated as soon as possible. It is in their interest that the information is up to date and correct.

Required experts' information

Prepared by Renske Gudde - IPBES Technical Support Unit (TSU) for Knowledge and Data and Rainer M. Krug - IPBES Task Force on Knowledge and Data. Reviewed by Aidin Niamir and Yanina V. Sica - IPBES Technical Support Unit for Knowledge and Data and the IPBES Task Force on Knowledge and Data (Hanno Seebens and Xubin Pan)

Version: 1.0 Last Updated: 16 October 2023

The IPBES assessment process is a lengthy and complex process, spanning over multiple years and involving many contributors. It is therefore important to track the versions of all files related to the assessment. Here, an IPBES specific versioning scheme for its assessments is being proposed.

There are usually five milestones during an IPBES assessment process; the first, second, and third order drafts, followed by the version submitted to the Plenary and the final approved version. Fast-track assessments have four milestones; they do not have a third order draft.

The IPBES versioning scheme consists of 3 parts separated by a dot (.):

vDRAFT.MAJOR.MINOR.

The DRAFT follows the following scheme:

Drafts 5 - 9 are reserved for any potential versions between the version submitted to the Plenary and the final approved version for production.

The MAJOR version starts with 0, going up one number for each new major revision, for example after the addition or removal of paragraphs, figures and/or data.

The MINOR version starts usually with 0 and is not often used (but needs to be specified). Minor versions are used for small changes in the text and/or data that do not lead to changes in the results, such as the addition of a reference or correcting of a spelling mistake. Similar to the major versions, for each new minor revision the number goes up by one.

Draft 0

Before the final draft of the first order draft:

Draft 1

Final version of the first order draft and every version before the final version of the second order draft:

Draft 2

Final version of the first order draft and every version before the final version of the second order draft:

Draft 3

Final version of the third order draft and every version before the final version submitted for the Plenary:

Draft 4

Final version to be submitted to the Plenary:

Final version

Final version that has been approved by the Plenary and is ready for publication:

Version: 1.2 Last Updated: 9 November 2023

This technical guidelines focuses on recommendations for the use of colour in maps and can be applied to other visualisations. We present some base considerations for colour paired with links to useful resources for further exploration to be used by all IPBES experts creating figures and maps.

Begin by loading the following packages:

library(RColorBrewer)
library(ggplot2)
library(sf)
library(rnaturalearth)

I. Overview of Pallets:

A Types of Pallets:

Colour is a critical key to communicating information to audiences. Often incorrect colour schemes are used that either make it difficult for people to understand the map or bias the interpretation. There are generally three types of palettes, qualitative, sequential, and diverging each corresponding to distinctive qualities of the data they represent.

Qualitative or categorical palettes have distinctive colours that are used to represent nominal or qualitative data with no presumed ordering, such as gender or cereal brands. Sequential palettes often represent continuous data such as temperature or height. These palettes are generally marked by even steps in value or intensity of a hue. Diverging palettes have two sets of sequential palettes meeting on a mutual colour which can represent continuous data with an obvious midpoint, such as data representing change from a baseline, or are often used to represent Likert scale survey responses.

B. Colour Blind Friendly Palettes

There are various apps to simulate colour blindness:

C. No rainbow colour palettes

Figure 2: Map illustrating the differences of interpretation of data displayed with a sunset palette scheme and the traditional rainbow palette.

II. RColorBrewer in R and Examples

A. RColorBrewer

In R, one can use the RColorBrewer package which provides convenient qualitative, sequential, and diverging palettes.

To display all of the prepared palettes within the RColorBrewer package run this line of code:

RColorBrewer::display.brewer.all()

To display all of the colourblind friendly palettes run this:

RColorBrewer::display.brewer.all(colorblindFriendly = TRUE)

If you would like to visualise a specific palette, specify the number of colours and the palette name.

RColorBrewer::display.brewer.pal(n = 5, name = 'YlOrRd')

B. Hexadecimal

These values can be used to specify specific colours for a plot. To return the hexadecimal colour code of a palette, use this code: brewer.pal(n, name)

For example:

RColorBrewer::brewer.pal(n = 5, name = "YlOrRd")

## [1] "#FFFFB2" "#FECC5C" "#FD8D3C" "#F03B20" "#BD0026"

We could then call those specific colours in a plot, as opposed to using general names like “blue” or pre-set palettes.

C. Examples

First run this code to download country data and the large cities dataset we will be working with. The code also projects both datasets to the Robinson Projection.

land <- ne_countries(scale = 110, returnclass = "sf") # Downloads land polygons 
cities <- read_sf("ne_110m_populated_places.shp") # Downloads the large cities points dataset

robin <- "+proj=robin +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs"# Defines Projection 

# Converts to Robinson
land <- st_transform(land, crs = robin)
cities <- st_transform(cities, crs = robin)

Example 1: Continuous Data We will use population information contained in the large cities dataset, which is a continuous variable. The function scale_color_gradient() is used for the continuous data. The hex values were obtained from the brewer.pal function shown in the last section.

ggplot(cities) +
  geom_sf(data = land, # adds land for reference
          col = NA,
          fill = "gray60") +
  geom_sf(aes(color = POP_MIN/1000000)) + # Assigns the colour of the large cities to their minimum population size
  scale_color_gradient( # used with continuous data
    low = "#FFFFB2", 
    high = "#BD0026") +
  labs(color = "Population (millions)") +
  theme(legend.position = "bottom", # Places legend on the bottom 
        panel.background = element_blank(), # controls the background panel colour 
        panel.grid.major = element_line(color = "grey80")) # controls the grid line colour 

Example 2: Categorical Data We now will use the land dataset and function scale_fill_brewer() to set the colour of the continents according to one of the qualitative palettes included in the RColorBrewer package.

ggplot(land) +
  geom_sf(aes(fill = continent, color = continent)) + # Fill and colour are the same to effective remove borders
  scale_color_brewer(palette = "Dark2") + # Uses a RColorBrewer palette
  scale_fill_brewer(palette = "Dark2") +
   theme(legend.position = "bottom", 
        legend.title = element_blank(),
         panel.background = element_blank(), 
        panel.grid.major = element_line(color = "grey80")) 

III. Suggestions

• Use colour schemes and projections consistently throughout the chapter, if possible throughout the assessment.

• No data is symbolized with the colour grey (BBBBBB; RGB:187, 187, 187)

• White or light sky blue (87CEFA; RGB: 135, 206, 250) is used for the ocean in maps

• Don’t overload colour - avoid colour when not necessary - use it to highlight important information

• Grey normally represents NA data in a map, but can be very useful in other plots to focus your audience’s attention on key parts of your visualisation that have colour

IV. Additional Resources

These technical guidelines on data management, handling, and delivery have been prepared by the technical support unit on knowledge and data and reviewed by the task force on knowledge and data.

Please note: The designations employed and the presentation of material on the maps shown here do not imply the expression of any opinion whatsoever on the part of the IPBES concerning the legal status of any country, territory, city or area or of its authorities, or concerning the delimitation of its frontiers or boundaries.

Version: 2.3 Last Updated: 15 August 2022

The guide will show how to aggregate and map FAO data according to the IPBES Regions and Sub-Regions polygons using R. For this exercise, we chose the FAO population data but any FAOSTAT dataset can be used. This guideline is intended for anyone aggregating data to IPBES regions and subregions.

Let’s begin by loading the following packages.

library(sf) 
library(dplyr)
library(magrittr)
library(FAOSTAT)
library(httr) # to download data off of Zenodo
library(rnaturalearth) # download ocean data from natural earth 
library(graticule) # for mapping 

I. Downloading Necessary Data

A. Downloading FAO data

FAOSTAT::download_faostat_bulk("http://fenixservices.fao.org/faostat/static/bulkdownloads/Population_E_All_Data_(Normalized).zip", getwd())

B. Downloading IPBES regions and subregions

Now we will download the shapefile of the IPBES Regions and Sub-regions off of Zenodo. This can be accomplished manually or through a few lines of code.

To do this through a script, first identify the record ID of the Zenodo entry, which is the numbers following “zenodo.” at the end of the URL. We then create a URL with the record ID and query the API for information about the record.

recordID <- "3923633"
url_record <- paste0("https://zenodo.org/api/records/", recordID)
record <- httr::GET(url_record)
record # Status 200 indicates a successful download
## Response [https://zenodo.org/api/records/3928281]
##   Date: 2021-02-04 13:31
##   Status: 200
##   Content-Type: application/json
##   Size: 6.41 kB

Now, we can inspect the contents downloaded with the function content()

View(content(record)) # view displays the output in a human readable form within R Studio

This information we received contains metadata for the record, and within this we can find the specific URL to download the IPBES regions and sub-regions shapefile. We then use this URL and the function GET() to download the shapefile.

# Contains the url to download the shapefile
url_shape <- content(record)$files[[5]]$links$download 

httr::GET(url_shape, write_disk("ipbes_regions_subregions.zip", overwrite = T)) # Downloads shapefile
## Response [https://zenodo.org/api/files/581f2706-24e9-43d0-a776-0ce97f377938/ipbes_regions_subregions_shape_1.1.zip]
##   Date: 2021-02-04 13:31
##   Status: 200
##   Content-Type: application/octet-stream
##   Size: 175 MB
## <ON DISK>  C:\Users\jkumagai\Documents\IPBES\R\Geoinformatics\Technical Guidelines Series\Mapping Guidelines v2\ipbes_regions_subregions.zip
unzip("ipbes_regions_subregions.zip") # unzips shapefile

II. Uploading data into R Studio

Now that our data is on our computer, we need to upload the data into R studio and project the spatial data.

pop_raw <- FAOSTAT::read_faostat_bulk("Population_E_All_Data_(Normalized).zip") # load the population data using FAOSTAT's built in function 
shape <- sf::st_read("IPBES_Regions_Subregions2.shp") # shapefile

## Reading layer `IPBES_Regions_Subregions2' from data source `C:\Users\jkumagai\Documents\IPBES\R\Geoinformatics\Technical Guidelines Series\Mapping Guidelines v2\IPBES_Regions_Subregions2.shp' using driver `ESRI Shapefile'
## Simple feature collection with 257 features and 5 fields
## geometry type:  MULTIPOLYGON
## dimension:      XY
## bbox:           xmin: -180 ymin: -90 xmax: 180 ymax: 83.65833
## geographic CRS: WGS 84

crs_robin <-  "+proj=robin +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs"
shape <- sf::st_transform(shape, crs_robin)

To plot the ocean in our maps, we will also download ocean data from the rnaturalearth package and project it

ocean <- rnaturalearth::ne_download(scale = 10, type = 'ocean', category = 'physical', returnclass = "sf")

## OGR data source with driver: ESRI Shapefile 
## Source: "C:\Users\jkumagai\AppData\Local\Temp\RtmpqmEyBR", layer: "ne_10m_ocean"
## with 1 features
## It has 3 fields

ocean <- sf::st_transform(ocean, crs = crs_robin) # changes the projection
ocean <- ocean[,1]

III. Cleaning the data

The next important step is to clean the data to ensure it can be joined and mapped easily. For this example, we will filter to only include the total population for each country in 2018.

pop_2018 <- pop_raw %>% 
  dplyr::filter(element == "Total Population - Both sexes" &
           year == 2018) %>% 
  dplyr::select(area_code, # these columns are selected from the original data
         area,
         element,
         year,
         unit,
         value)

By examining the Area names within the dataset, one will notice that every name after Zimbabwe refers to aggregated data, therefore we will remove these from our analysis.

tail(pop_2018$area, 34)

##  [1] "World"                                  
##  [2] "Africa"                                 
##  [3] "Eastern Africa"                         
##  [4] "Middle Africa"                          
##  [5] "Northern Africa"                        
##  [6] "Southern Africa"                        
##  [7] "Western Africa"                         
##  [8] "Americas"                               
##  [9] "Northern America"                       
## [10] "Central America"                        
## [11] "Caribbean"                              
## [12] "South America"                          
## [13] "Asia"                                   
## [14] "Central Asia"                           
## [15] "Eastern Asia"                           
## [16] "Southern Asia"                          
## [17] "South-Eastern Asia"                     
## [18] "Western Asia"                           
## [19] "Europe"                                 
## [20] "Eastern Europe"                         
## [21] "Northern Europe"                        
## [22] "Southern Europe"                        
## [23] "Western Europe"                         
## [24] "Oceania"                                
## [25] "Australia and New Zealand"              
## [26] "Melanesia"                              
## [27] "Micronesia"                             
## [28] "Polynesia"                              
## [29] "European Union"                         
## [30] "Least Developed Countries"              
## [31] "Land Locked Developing Countries"       
## [32] "Small Island Developing States"         
## [33] "Low Income Food Deficit Countries"      
## [34] "Net Food Importing Developing Countries"

pop_2018 <- pop_2018[1:237, ] # Selects the first 237 records, thus removing the last 34 which are aggregated data

Finally, we need to add the ISO3 codes onto the dataframe, so we can easily join it to the IPEBS Regions and Sub-Regions data. The translateCountryCode() function provided by the FAOSTAT package allows us to easily do this.

pop_2018 <- FAOSTAT::translateCountryCode(data = pop_2018, from = "FAOST_CODE", to = "ISO3_CODE", "area_code") # Add's the ISO Code to the data
## 
## NOTE: Please make sure that the country are matched according to their definition
## Warning in FAOSTAT::translateCountryCode(data = pop_2018, from = "FAOST_CODE", : The following entries does not have 'ISO3_CODE' available
##     FAOST_CODE ISO3_CODE
## 53         351      <NA>
## 234        277      <NA>
##                                            OFFICIAL_FAO_NAME
## 53  China (China mainland, Hong Kong SAR, Macao SAR, Taiwan)
## 234                              the Republic of South Sudan

There are two records where no ISO3 Code was assigned: China (including mainland, Hong Kong SAR, Macao SAR, and Taiwan) and South Sudan. “China mainland” refers to the same area as “China” in our dataset, so we are safe to exclude the China (including mainland, Hong Kong SAR, Macao SAR, and Taiwan) from our analysis.

For South Sudan, we will add the same ISO-3 Code we have in the IPBES Regions and Sub-regions dataset.

pop_2018[230,2] <- "SSD" # South Sudan
pop_2018 <- na.omit(pop_2018) # removes China (including other areas)

IV: Joining and Aggregating

We have all of our data downloaded locally, uploaded into R, and formatted properly. The last step is to join and aggregate the data to the IPBES regions and sub-regions shapefile.

First, we join the IPBES regions and sub-regions attributes to our data table. I drop the spatial attributes of the IPBES regions and sub-regions dataset to speed up the process.

colnames(shape)[2] <- "ISO3_CODE" 
regions <- shape %>%   
  as.data.frame() %>% # drops the spatial attributes
  dplyr::select(ISO3_CODE, Region, Sub_Region)  # filters the columns

pop_2018 <- dplyr::left_join(x = pop_2018, y = regions, by = "ISO3_CODE") %>% # Joins data
 tidyr::drop_na() # conveenient function from tidyr package 

Secondly, we aggregate the data per IPBES regions and sub-regions. In our example, I calculate the total population per region and per sub-region using the group_by() function.

pop_2018 <- pop_2018 %>% 
  dplyr::group_by(Region) %>% # Grouping by regions
  dplyr::mutate(region_pop = sum(value)/1000) %>% # calculates total population (millions) per region
  dplyr::ungroup() %>% 
  dplyr::group_by(Sub_Region) %>% # Grouping by sub-region 
  dplyr::mutate(sub_region_pop = sum(value)/1000) %>% # calculates total population (millions) per sub-region
  dplyr::ungroup() 
pop_2018

## # A tibble: 234 x 11
##    FAOST_CODE ISO3_CODE area  element  year unit   value Region Sub_Region
##         <int> <chr>     <chr> <chr>   <int> <chr>  <dbl> <chr>  <chr>     
##  1          1 ARM       Arme~ Total ~  2018 1000~ 2.95e3 Europ~ Eastern E~
##  2          2 AFG       Afgh~ Total ~  2018 1000~ 3.72e4 Asia ~ South Asia
##  3          3 ALB       Alba~ Total ~  2018 1000~ 2.88e3 Europ~ Central a~
##  4          4 DZA       Alge~ Total ~  2018 1000~ 4.22e4 Africa North Afr~
##  5          5 ASM       Amer~ Total ~  2018 1000~ 5.55e1 Asia ~ Oceania   
##  6          6 AND       Ando~ Total ~  2018 1000~ 7.70e1 Europ~ Central a~
##  7          7 AGO       Ango~ Total ~  2018 1000~ 3.08e4 Africa Southern ~
##  8          8 ATG       Anti~ Total ~  2018 1000~ 9.63e1 Ameri~ Caribbean 
##  9          9 ARG       Arge~ Total ~  2018 1000~ 4.44e4 Ameri~ South Ame~
## 10         10 AUS       Aust~ Total ~  2018 1000~ 2.49e4 Asia ~ Oceania   
## # ... with 224 more rows, and 2 more variables: region_pop <dbl>,
## #   sub_region_pop <dbl>

Finally, we join the formatted FAO data to the spatial data we originally had so we can create maps.

data <- dplyr::full_join(x = shape, y = pop_2018, by = "ISO3_CODE")

V. Mapping

All that is left to do is to map the data per region and sub-region. We begin by dissolving the spatial data per region and subregion so country borders are not included.

data_region <- data %>% # this dissolves the data by region
  dplyr::group_by(Region.x) %>% 
  dplyr::summarise(region_pop2 = sum(value, na.rm = T)/1000) %>% 
  sf::st_cast() 

data_subregion <- data %>% # this dissolves the data by subregion
  dplyr::group_by(Sub_Region.x) %>% 
  dplyr::summarise(sub_region_pop2 = sum(value, na.rm=T)/1000) %>% 
  sf::st_cast()

Now, we choose the palette and plot by region.

data_region$region_pop2 <- as.character(round(data_region$region_pop2 )) # Treats the values as groups so the legend displays correctly 
data_region$region_pop2[5] <- "0927" # Ensures the legend displays correctly

# Plotting by regions
palette <- c("grey","aliceblue", "lightskyblue", "dodgerblue", "dodgerblue4") # colors


plot(data_region[,2], pal = palette, main = "Total population (millions) in 2018 per region")

If you would like to add graticules and an ocean background, follow this example. First, we will set up the graticules we will plot

# Creates latitude and longitude labels and graticules
lat <- c(-90, -60, -30, 0, 30, 60, 90)
long <- c(-180, -120, -60, 0, 60, 120, 180)
labs <- graticule::graticule_labels(lons = long, lats = lat, xline = -180, yline = 90, proj = crs_robin) # labels for the graticules 
lines <- graticule::graticule(lons = long, lats = lat, proj = crs_robin) # graticules 

Then, we will plot the graticules, ocean data, then region data, and finally the text for latitude and longitude lines, legend, and surrounding box.

par(mar = c(2,3,1,2)) # Adjusts the edges of the frame 
plot(lines, lty = 5, col = "lightgrey",  main = "Total population (millions) in 2018 per region") # plots graticules 
plot(ocean, col = ggplot2::alpha("slategray1", 0.3), add = TRUE) 
plot(data_region[,2], pal = palette, add = TRUE)
text(subset(labs, labs$islon), lab = parse(text = labs$lab[labs$islon]), pos = 3, xpd = NA) # plots longitude labels
text(subset(labs, !labs$islon), lab = parse(text = labs$lab[!labs$islon]), pos = 2, xpd = NA) # plots latitude labels
legend("bottom", # adding the legend last 
       legend = (data_region %>% pull(region_pop2) %>% sort()),
       fill = palette, 
       horiz = TRUE, bty = "n")
box(which = "plot", lty = "solid") # Map frame 

We can also plot by subregion.

plot(data_subregion[,2], main = "Total population (millions) in 2018 per sub-region", breaks = "quantile")

Version: 2.1 Last Updated: 15 July 2022

The guide will show how to convert raster and vector data from a projection to the Robinson projection using R and is intended for IPBES experts creating maps. IPBES has adopted the Robinson projection for visualizing global scale maps as it balances distortions in area, direction, distance, and distortions near the poles. Please note that the projection used for analysis and whether one would like to display a Pacific centered or Greenwich centered map depends on the application. For example, If calculating area, an equal-area projection is needed.

Begin by loading the following packages.

library(terra)
library(raster)
library(graticule)
library(rgdal)
library(rworldmap)

crs <- "+proj=robin +lon_0=0 +x_0=0 +y_0=0 +datum=WGS84 +units=m"

I. Raster Data

To produce a Greenwich centered map in the Robinson projection with raster data, we will load precipitation data from world clim and plot the result, but please load and use the raster data that you will be working with. The crs() function will output the projection that your data is in.

prec <- raster::getData(name = "worldclim", var = "prec", res = 10)[[1]] # load data
plot(prec)

raster::crs(prec)

## CRS arguments: +proj=longlat +datum=WGS84 +no_defs

Next, we will create a mask, and then project the data with this mask so repeated areas of the world map are removed.

jp <- terra::rast(prec$prec1)
jp <- jp * 1 # to deal with NAs in this datasaet
rob <- terra::project(jp, crs, mask=TRUE)

Now we can plot our results to ensure it is correct.

plot(rob) #Plot the raster

The next step is to create graitcules and labels to add to all of the next plots.

# Creates latitude and longitude labels and graticules
lat <- c(-90, -60, -30, 0, 30, 60, 90)
long <- c(-180, -120, -60, 0, 60, 120, 180)
labs <- graticule::graticule_labels(lons = long, lats = lat, xline = -180, yline = 90, proj = crs) # labels for the graticules 
lines <- graticule::graticule(lons = long, lats = lat, proj = crs) # graticules 

The warnings of discarding the datum can be safely ignored in this case*.

Finally, we will plot the raster with the graticules we just created.

plot(rob,axes = F) #Plot the raster
plot(lines, lty = 5, col = "grey", add = TRUE) # plots graticules 
text(subset(labs, labs$islon), lab = parse(text = labs$lab[labs$islon]), pos = 3, xpd = NA) # plots longitude labels
text(subset(labs, !labs$islon), lab = parse(text = labs$lab[!labs$islon]), pos = 2, xpd = NA) # plots latitude labels

II. Vector Data

In this section, we will produce a world map of countries with vector data (points, lines, polygons). First, we will load, check the projection, and plot a world map of countries.

worldmap <- rworldmap::getMap(resolution = "coarse") # Load countries 
raster::crs(worldmap)

## CRS arguments:
##  +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

plot(worldmap) # Plot world map (vector)

## Warning in wkt(obj): CRS object has no comment

Now, we project the vector data into the Robinson projection and plot the map with graticules.

worldmap <- sp::spTransform(worldmap,crs) # Project to Robinson 

## Warning in spTransform(xSP, CRSobj, ...): NULL source CRS comment, falling back
## to PROJ string

## Warning in wkt(obj): CRS object has no comment

plot(worldmap)
plot(lines, lty = 5, col = "grey", add = TRUE) # plots graticules 
text(subset(labs, labs$islon), lab = parse(text = labs$lab[labs$islon]), pos = 3, xpd = NA) # plots longitude labels
text(subset(labs, !labs$islon), lab = parse(text = labs$lab[!labs$islon]), pos = 2, xpd = NA) # plots latitude labels

If there are polygons that cross the date line, it is possible that some erroneous polygons may appear. If this occurs, the solution is to run the function st_wrap_dateline() before projecting.

III. Combine Vector and Raster

Finally, we will visualize both the raster and vector data together in one map.

## Vector & Raster
plot(rob,axes = F) # Plot the raster
plot(worldmap,add=T) # Plot the vector data 
plot(lines, lty = 5, col = "grey", add = TRUE) # plots graticules 
text(subset(labs, labs$islon), lab = parse(text = labs$lab[labs$islon]), pos = 3, xpd = NA) # plots longitude labels
text(subset(labs, !labs$islon), lab = parse(text = labs$lab[!labs$islon]), pos = 2, xpd = NA) # plots latitude labels

Prepared by The Technical Support Unit and Task Force on Knowledge and Data and the Technical Support Unit and Task Force on Indigenous and Local Knowledge

Version: 1.1 Last Updated: 14 July 2022

I. Introduction

II. FPIC and moving towards the CARE and FAIR principles

A. Overarching challenges

There are some challenges for moving towards full FPIC, CARE, and FAIR alignment in IPBES products and their underlying processes, particularly:

• Indigenous peoples and local communities (IPLCs**), like all other knowledge and data owners, do not have final consent over the findings of the assessments, as assessment findings are intended to be based on a process of reviewing available evidence.

• Most IPBES products are only available online and additionally only in English, with the exception of assessments’ SPMs and some additional products. Therefore, full accessibility and findability of IPBES products for many IPLCs is not achieved within the standard IPBES distribution channels.

• Where authors rely on existing materials (including peer-review publications, grey literature and other sources) to work with ILK, it may not always be possible to know if FPIC principles were followed during the development of that literature, or to verify the veracity and reliability of the materials.

B. Overarching approaches for FPIC and moving towards CARE and FAIR

Keeping these challenges in mind, IPBES strives to ensure that FPIC and the CARE and FAIR principles are fulfilled to the fullest extent possible within the mandate of the Platform, by the following overarching approaches:

1. Ensuring that IPLCs are informed of the IPBES process prior to providing contributions

• Information about IPBES processes, products, and goals, and how these relate to the activity in question, needs to be provided prior to IPLCs participating, so that they can decide how they wish to share knowledge and what they wish to share. This can be achieved either through an explanatory email or text provided prior to an activity, for example, in the case of the call for contributions or when approaching contributing authors, with follow-up discussions as needed. In the case of dialogue workshops, an initial session of the workshop is also set aside to further explain and discuss aims, uses and storage of information shared during the workshop.

2. Ensuring that IPLCs are engaged in developing assessments, informed of assessment content, and that they can review and comment on drafts

• The main mechanism for ensuring that IPLCs are engaged in developing assessments, informed of assessment content, and that they can review and comment on drafts is the dialogue workshops and other online webinars and events that aim to inform IPLCs of current IPBES processes. The scoping dialogue workshop provides a first opportunity for IPLCs to learn about and help to frame an assessment. The first dialogue workshop further provides an opportunity for co-developing key themes and questions for the assessment, refining methods and approaches, and highlighting any risks or challenges relating to ILK and IPLC issues. The second and third dialogue workshops in an assessment cycle take place during the assessment review periods. These dialogues are designed to give IPLCs the opportunity to understand and comment on draft assessment materials, to provide any additional resources that could be used to improve an assessment text, and to raise any issues of concern in terms of representation of IPLCs and their knowledge, use of confidential knowledge, and information or gaps. Authors can use these dialogue workshops to raise any concerns they have with their chapters, especially where they are unsure whether FPIC was followed in materials reviewed, as described below.

3. Enhancing accessibility of IPBES products to IPLCs

The following activities and processes aim to enhance accessibility of IPBES products to IPLCs:

• Final assessments and associated IPBES products are publicly available online;

• IPLCs who contributed to the Assessments will be notified of their approval and online publication;

• Webinars and other events are held around these materials to enhance their outreach and uptake;

• IPBES will also aim to work with other organisations, including the BES-Net programme, to further develop outreach and communication materials in multiple languages.

4. Ensuring that access to confidential ILK is restricted

• Where appropriate, IPBES authors, together with the ILK task force and TSU, will work with IPLCs to ensure that their knowledge is only represented in ways that do not reveal confidential information with their permission (for example, a synthesis of medicinal plant use rather than specific details of this use).

III. CARE and FPIC when working with different ILK sources

Alongside the overarching processes described above, authors and TSUs can also work to ensure that FPIC, CARE, and FAIR are fulfilled to the maximum extent possible when working with different sources of ILK. ILK can come from a variety of sources, such as outcomes of IPBES dialogues, published materials, unpublished materials submitted during a review period, or from contributing authors. The recommended processes for different types of sources of ILK are discussed below. IPBES experts, including Contributing Authors, will need to document these processes within data management reports as explained in section IV.

A. Outcomes of IPBES dialogues (reports)

The IPBES ILK dialogue workshop process is designed to closely align with the CARE principles, and is an FPIC process, as follows:

• Participants are informed at the outset of the objectives of the workshop, and of the uses, storage and access to information provided;

• Participants are given the opportunity after the dialogue to comment on and edit the draft report and any other materials produced, and can remove the information they provided at any time;

• All information provided during the dialogue is included within the workshop report, which is publicly available, so there is no additional information stored by IPBES to which further access is needed, unless participants specifically request that their information remains confidential;

As such, when citing the reports, authors can be confident that it follows FPIC as well as the CARE and FAIR principles. However, there are additional considerations:

• If parts of the report will be quoted in their entirety, or case studies from the reports will be explicitly highlighted in the assessment, these portions of text should be sent to participants for their review and approval. Authors can contact the technical support unit on ILK to coordinate this. Appropriate credit should also be given to the dialogue workshop participants alongside these portions of text, rather than only referencing the IPBES report.

B. FPIC and CARE in review of other literature and published materials

IPBES authors review literature and materials describing ILK, which could include peer-reviewed articles, as well as published or unpublished grey literature such as NGO reports, community reports, and online videos, etc. Authors should be attentive to the possibility that FPIC may not have been properly sought by the authors of published materials, even where it appears to be published by a community. It is, however, generally not possible to trace each of these materials back to its source and check on FPIC and CARE compliance. However, there are key issues or themes within materials that can indicate that further attention may be needed:

• Materials that are critical of IPLCs;

• Materials that detail rituals or spiritual practices;

• Materials that detail uses of medicines, including plants and animals.

If such themes are detailed in a material, the following steps can be taken:

• Send any material in question to the ILK TSU for verification by the ILK task force or by participants of a dialogue workshop, including material that will become part of other IPBES products, such as a data management report.

Moreover, if a single paper or limited number of papers are used to build a detailed case study, authors could check that FPIC and proper protocols were followed, or engage with the community in question to verify.

C. Unpublished materials

In some circumstances, assessment authors may review unpublished materials, such as community reports, songs, artworks, or personal communication. In such cases, authors need to be particularly attentive to the issues and actions highlighted above, and bring any concerns to the ILK TSU. If requested, IPBES can support owners of unpublished materials to ensure that these materials are findable and accessible, including recommendations for storage. For example, supporting communities to publish the materials on a public website, or for confidential materials, making metadata available online but storing the materials inside a closed repository. A full process of free, prior and informed consent needs to be followed to make sure that the communities involved understand and formally consent to the use, storage and access rights for the materials.

D. Contributions from Contributing Authors

Contributing authors, who may or may not be IPLCs, are invited to contribute text, figures, or other inputs to an assessment. Again, any mention of the key issues highlighted above can indicate that there is a potential sensitivity and the ILK TSU should be informed.

A FPIC process should also be followed with IPLC contributing authors, to ensure that they understand and consent to the full proposed use, storage of, and access to the information they provide, including that:

• The final assessment may not include their submitted contribution at all;

• The final assessment may not include their submitted contribution in full;

• The final assessment may include a highly edited or synthesised version of the their contribution;

• Their full submitted contribution may be made publicly available in a data management report or in supplementary materials.

Where possible, IPBES authors should send contributing authors the parts of the assessment which include their contributions so they can review and approve the use of their text. Further, our recommendation is to include these points in a first email when approaching all relevant contributing authors, so that they agree to these terms. These contributing authors should also acknowledge that they are authorised to share any ILK contributions and confirm that these are non-confidential. Additionally, coordinating lead authors should have the responsibility to ensure that contact with contributing authors throughout the assessment is maintained. The technical guideline available at: https://ict.ipbes.net/data-management/technical-guidelines/Contributing-authors-template contains an adaptable template for a first email to contributing authors which states these points.

IV. Documentation for each type of source

Finalised dialogue reports are openly available and published as open access on Zenodo.

Data management reports*** should be used to document the process of working with other sources of ILK to enhance transparency. For data management reports that include descriptions of all ILK sources, a section describing the following for each source should be included:

• Published materials - If there were concerns identified including those described in section III - B, describe what steps were taken to address the concerns and the outcome. Rejected materials should be listed;

• Unpublished materials - Describe what steps were taken to store these materials and to follow the process of FPIC. Additionally, include the agreed terms of use and access, appropriate accreditation, and how these materials can be found and accessed in the future;

• Contributions - If there were concerns raised, describe what steps were taken to address the concerns and the outcome.

*The IPBES core glossary gives the following definition; “indigenous and local knowledge systems are social and ecological knowledge practices and beliefs pertaining to the relationship of living beings, including people, with one another and with their environments.” See https://www.ipbes.net/glossary/indigenous-local-knowledge-systems

**The IPBES glossary gives the following definition: Indigenous peoples and local communities (IPLCs) are, typically, ethnic groups who are descended from and identify with the original inhabitants of a given region, in contrast to groups that have settled, occupied or colonized the area more recently. IPBES does not intend to create or develop new definitions of what constitutes “indigenous peoples and local communities". See https://ipbes.net/glossary/indigenous-peoples-local-communities. Chapter 1 of the IPBES Global Assessment, and IPBES ILK methods guide also provide further detail and discussion.

***For more information on data management tutorials, Chapter 3 of the IPBES data management tutorials reviews the topic in detail, which is available here: https://doi.org/10.5281/zenodo.4014792

Prepared by Joy Kumagai and Aidin Niamir - IPBES Technical Support Unit (TSU) of Knowledge and Data Reviewed by the Task Force on Knowledge and Data (Hanno Seebens, Rainer Krug, Gregoire Dubois, Matea Vukelić, and Xubin Pan)

Version: 1.0 Last Updated: 19 August 2022

This technical guideline discusses how an indicator should be documented within IPBES and is intended for any experts that are involved in creating an indicator following the FAIR and CARE principles. The guideline focuses on the technical aspects of documentation.

I. Introduction

II. Documentation

The recommendations throughout this section focus on practical steps to ensure the FAIR and CARE principles can be followed when documenting the indicator and its calculation.

A. Input data for the calculation of the indicator:

It is essential to document where to find all the necessary inputs that go into the indicator workflow so others can calculate and update the indicator. Therefore, we suggest the following:

• All input data are clearly referenced and noted with version and access date;

• All input data need to be at least findable, although solely using open access datasets in compliance with the FAIR data management principles would be preferable but not feasible in all cases;

• Additionally, all input data used are stored so it is possible to re-calculate the indicator exactly in case the original versions of the data are no longer available;

• If any input datasets are products of Indigenous and local knowledge, it is crucial that a process of Free, Prior, and Informed Consent was completed before the data was generated and the information is used and made available only within the limits and following the intent set by the knowledge-holders;

• The licences of the respective data are acknowledged and followed.

B. Development and presentation of the indicator workflow:

Ensuring that others can understand the methodology and repeat the workflow of the indicator allows people to improve upon and use the indicators in their own context, greatly expanding the reach and impact of an indicator. Therefore we suggest the following:

• A visual figure is created that details the steps for transforming input data to calculate the indicator, in order to help others understand the workflow;

• Any assumptions in the workflow are clearly stated and explained. For example, often when overlaying protected areas with species data, it is assumed that species within those protected areas are "protected," while in reality this is often not the case on the ground. Or another example, often in carbon stock calculations an expert may assume a 1-metre depth of soil.

C. Outputs

Now that the inputs and process behind the indicator are clearly documented and explained, the final dataset (i.e. the indicator) should be findable and accessible. Additionally, in the documentation there should be information about the interpretation and limits, e.g. the scale and time frame in which the indicator can be interpreted. Therefore, we recommend the following:

• The final indicator dataset is easily findable and accessible in an online repository and has been assigned a DOI;

• Within this repository, the indicator dataset is stored in an interoperable format with clear metadata (version number, temporal scale, geographic scale, etc.);

• A licence is assigned to the indicator dataset and associated workflow, preferably CC-BY or CC0;

• A contact person is clearly identified in the repository with a monitored email;

• The indicator is communicated and interpreted clearly, including its limits and what questions it was developed to address, in a report/publication/media release to share it with the wider community;

In general, the associated publication should provide all required information to reproduce the results, including a link to the workflow repository and final dataset.

III. IPBES Process

Within IPBES, it is important that if any expert team develops an indicator, the associated technical support unit informs the technical support unit on knowledge and data. The technical support unit on knowledge and data can ensure that these steps are followed and all input data are accessible and stored in case the original source of the information is removed, enabling reuse by future assessments. Increasing transparency in the process of creating an indicator ensures consistency, allowing the scientific community to repeat workflows, improve upon them, and test different scenarios. Over time this process will build trust for the indicator and encourage their use to help inform policy and action.

References

These technical guidelines have been prepared by the technical support unit on knowledge and data and reviewed by the task force on knowledge and data within IPBES.

The Organisation of Work, consists of three separate parts:

These guidelines are intended to support the technical support units for the assessments, the other technical support units within IPBES and the assessment experts. Adopting these practices will increase the consistency and coherence within IPBES, and will facilitate the use of IPBES products for internal and external users.

Prepared by Joy Kumagai and Peter Bates Reviewed by Aidin Niamir, the Task Force on Knowledge and Data and the Task Force on Indigenous and Local Knowledge

Version: 1.0 Last Updated: 18 July 2022

This technical guideline is a template invitation email for contributing authors to IPBES assessments, which covers aspects relating to ILK and the data and knowledge management policy. The guideline is intended for assessment technical support units.

Contributing Authors Template Email considering ILK and the data and knowledge management policy

This formal email could be sent after initial more informal contact is made, as appropriate.

Dear [contributing author name],

The assessment of [assessment name] was approved by the IPBES plenary in [year] and will run until [year]. It is being developed based on the attached scoping document.

As a contributing author, you would be linked directly to authors of the assessment and would be requested to provide specific contributions around themes, topics or geographic areas, as discussed with [author name]. Contributing Authors do not however have access to drafts of the full chapter due to IPBES rules on confidentiality of assessment drafts.

Contributions by contributing authors are always highly valuable and gratefully received, and support the development of key themes in an assessment chapter. However, we cannot guarantee that contributions will be reproduced in their entirety in the assessment. They may be edited during rounds of drafting and external review processes so that they form a part of a coherent chapter. Also, depending on space and chapter structures, the chapter may eventually use a synthesised version of your contribution. However, your full contribution may be made publicly available in a data management report or in supplementary materials that are available online as companion resources to the assessment.

Contributing authors are acknowledged on the first page of the Chapter to which they have contributed, but they are not listed as authors or within the citation of the chapter and assessment.

Finally, further communications guiding your contributions will be made directly by [author name]. However, if you have any further questions feel free to contact me at [email].

We thank you for considering this invitation to contribute to this assessment, and we look forward to your valuable input.

[Signature]

Prepared by the technical support unit of knowledge and data

Version: 5.0 Last Updated: November 8th 2024

This technical guideline is a resource for everyone to cite previous IPBES assessments starting with the IPBES Global Assessment. BibTeX and RIS files are available to download beneath each citation. Assessments approved at each future Plenary session will be added to the list. Suggested citations are created by the assessments.

I. Transformative Change Assessment

Full report

Summary for policymakers

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

II. Nexus Assessment

Full report

Summary for Policy Makers

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 5.0

Chapter 5.1

Chapter 5.2

Chapter 5.3

Chapter 5.4

Chapter 5.5

Chapter 5.6

Chapter 6

Chapter 7

III. Invasive Alien Species Assessment

Full report

Summary for Policymakers

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 6

IV. Sustainable Use Assessment

Full report

Summary for Policymakers

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 6

V. Values Assessment

Full report

Summary for Policymakers

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 6

VI. Global Assessment

Full report

Summary for Policymakers

Chapter 1

Chapter 2.1

Chapter 2.2

Chapter 2.3

Chapter 3

Chapter 4

Chapter 5

Chapter 6

Prepared by the technical support unit of knowledge and data

Version: 5.0 Last Updated: November 8th 2024

This is a resource for everyone to cite previous IPBES assessments starting with the IPBES Global Assessment. BibTeX and RIS files are available to download beneath each citation. Assessments approved at each future Plenary session will be added to the list. Suggested citations are created by the assessments.

Prepared by Joy Kumagai - Technical Support Unit (TSU) of Knowledge and Data

Reviewed by the Task Force on Knowledge and Data and Benedict Omare - Information Management Officer

Version: 1.1 Last Updated: 14 July 2022

I. Zenodo overview

Zenodo provides the following services:

• A persistent Digital Object identifier (DOI) is assigned for each upload to make it citable, traceable and findable

• Metadata of each record is sent to DataCite servers during DOI registration and indexed there

• Data and metadata will be retained for the lifetime of the repository. This is defined as the lifetime of the host laboratory CERN, which currently has an experimental programme defined for the next 20 years

• Storage of large file sizes of up to 50 GB

• Versioning of data

• Integration with GitHub

• All data and metadata uploaded is traceable to a registered Zenodo user

1. Access to IPBES products

2. A digital object identifier (DOI) to enable citation of the product or deposit including direct access to its digital representation

3. Search functionality in numerous platforms (e.g. CrossRef, DataCite, PubMed, RefBank, GNUB and Mendeley)

Uploads to the IPBES community on Zenodo must be material that has been prepared for IPBES.

II. How to upload to Zenodo manually

The purpose of this section is to provide helpful guidance on specific aspects as opposed to going into detail on each part of the form for manual upload.

A. Some important things to mention

1. Descriptive metadata can be modified after publishing without changing the DOI. Files can also be re-uploaded but all data uploads are permanently stored and issued with unique version numbers and DOIs. Therefore, extra care should be used when uploading files.

3. A DOI can be reserved by creating a new Zenodo upload draft, selecting "Reserve DOI" under the basic information section, and saving the draft. The identifier can now be added to any documentation, including a data management report for the same upload

4. ORCIDs should be provided whenever possible

5. Please add your entry to the IPBES community, by searching IPBES secretariat within the upload form in the second section. The submission has to be approved by secretariat before it appears in the community

B. How to reserve a DOI

Under the section Basic information, the first field asks for a digital object identifier and directly below the descriptive text there is a box named "Reserve DOI" (see figure 1). Once this button is pressed, the text box then automatically fills in with the assigned DOI. Once you save the draft entry, which requires filling in sections with a red asterisk next to them (which can be changed at a later date), this is the corresponding DOI to the draft upload.

If creating a data management report, please include this reserved DOI at the top of the report and use the same drafted Zenodo entry for the data deposit package.

C. Authors versus contributors

The upload form for Zenodo has two explicit places where people can be attributed for their work. One can specify author names in the Basic information section, and other contributor names under the Contributors section further down the form.

Within the form, the role of each contributor can be specified. There are many options which provide valuable information, such as contact person or research group. Some of the options are pictured in Figure 2.

D. Related identifiers

Related identifiers are an incredibly useful tool that can help users understand the connections between products and easily navigate between them. For example, if one is interested in a data management report and finds the Zenodo upload, they can easily click on the related chapter and see how the analysis appears within the actual assessment chapter.

For data management reports associated with IPBES assessments, adding the DOI to the associated assessment chapter on Zenodo is important to maintain the relationship between the products.

There are a variety of options to specify relationships between products, such as the following:

• "is supplemented by this upload" / "is a supplement to this upload"

• "describes this upload" / "is described by this upload"

• "continues this upload" / "is continued by this upload"

Additionally, ISBNs, URLs, and other identifiers can be used in addition to DOIs.

An example of how these related identifiers work can be found on the IPBES Data Management Tutorials Zenodo page pictured below.

E. Access and licenses

Uploads related to IPBES assessments should be set to open access at the latest one calendar month following the adoption of the assessment by Plenary, unless a longer embargo period is approved by the task force on knowledge and data. Please see the IPBES data and knowledge management policy for more information.

Restricted access: If you select restricted access, you will need to specify the conditions under which you grant users access to the files in your upload. A user requesting access will be asked to justify how they fulfill the conditions. Based on the justification, you decide who to grant/deny access. You are not allowed to charge users for granting access to data hosted on Zenodo.

The following licenses can be specified on Zenodo:

• Creative Commons Attribution 4.0 International - Recommended

• Creative Commons Attribution 1.0 Generic

• Creative Commons Attribution 2.0 Generic

• Creative Commons Attribution 3.0 Unported

• Creative Commons Attribution 3.0 Austria

• Creative Commons Attribution 3.0 Germany

• Creative Commons Attribution 3.0 Netherlands

• Creative Commons Attribution 3.0 United States

F. Versioning and Keywords:

Please add version numbers to all entries. If the entry is updated, the version number and date can be used to keep track of which version was available and used.

To aid in discoverability, it can be helpful to add keywords to your upload that describe the deliverable, document type, and/or descriptive term.

For example:

• Deliverable: global assessment; values assessment; invasive alien species assessment

• Document Type: Full assessment report; Summary for Policymakers; Supplementation material; data management report

• Descriptive term: Data policy

III. How to upload to Zenodo using GitHub

Zenodo and GitHub have the possibility of being linked so that a new release on GitHub can create a new or an update to an existing Zenodo repository. Here we will discuss the context-specific considerations for IPBES and give a overview of the process.

One case where it would be helpful to have this link established would be if one has a project which utilizes a set of codes for and analysis with associated figures. The code, resulting figures, and data management report (perhaps in markdown format) could be included in the GitHub repository, and each release for a milestone draft could automatically have the associated Zenodo page updated.

Unfortunately, your repository on GitHub needs to be public for it to be published on Zenodo. Also, the access is automatically set to public on the Zenodo entry. Thus, the access would need to be adjusted after the release to restricted instead. IPBES products stemming from assessments need to be set to restricted access until the assessment is approved by Plenary.

To link your GitHub repository to a Zenodo page, follow the these steps:

1. Log in and choose your repository on GitHub and ensure it is publicly available

2. Log into your Zenodo account

3. Now, next to your email at the top right of the Zenodo page, there is a little drop down menu, select GitHub and select authorize application to give Zenodo the permissions it needs. Once this occurs, you should see a list of repositories, toggle the button next to your chosen repository into the ON position (see figure 4)

4. Back on GitHub, under settings click "Webhooks" in the left-hand menu. There should be a webhook configured to Zenodo

6. Back on Zenodo under the Upload tab, there should now be a new draft upload where you can reserve a DOI for your repository, edit the information and publish

Each new release should create a new version of the Zenodo Upload, published automatically.

IV. How to share Zenodo entries

One of the key benefits of Zenodo is that when you create an upload it provides a DOI for the entry. One can then find the Zenodo webpage by typing the following into a browser.

• https://doi.org/ [add DOI of the upload]

Diving deeper, Zenodo actually issues two DOI’s. One DOI refers to the specific version, while there is an additional DOI created which cites all versions and resolves to the latest one. For instance, if a data management report is updated between one of the milestone drafts and the final version for an assessment, include the DOI that cites all versions in the assessment, thus ensuring anyone who clicks on the URL will be automatically sent to the most recent version.

Generally, when sharing your Zenodo uploads please use the DOI that cites a specific version unless you only want to refer the newest version.

V. How to download from Zenodo

A. Manually

To download files from Zenodo, all one needs to do is to navigate to the entry they would like to download, scroll down to the Files section on the webpage, and press the button download next to each of the files they would like to download (highlighted in Figure 6). This functionality can be very useful to quickly check files or to save locally and quickly. Resources uploaded to the IPBES community can be found on https://zenodo.org/communities/ipbes.

B. Programmatically using R

For other applications, such as downloading a dataset to be used in a script, one may want to have the script download the files, so that the most recent version is always used and the source is explicit.

The shapefile for the ipbes regions and subregions is within the zipped folder called "ipbes_regions_subregions_shape_1.1.zip". Once these files are downloaded, one can unzip the shapefile, call it into memory, and begin to use it as shown here:

Version: 1.1 Last Updated: 15 July 2022

I. Executive Summary

This technical guideline is for all IPBES experts and focuses on recommended file formats for IPBES with open or mostly open standards. To summarize briefly:

Table 1: Recommendations for file formats

* While we are aiming to use open or mostly open formats, currently DOCX is widely used by the IPBES community and thus is still acceptable, although for preservation a PDF version of the DOCX file should also be added to the repository.

More details on these formats follow below. If you have any suggestions on further content or file format types you would like to see covered please contact us.

II. Geospatial Files

For each type of spatial data, this guideline will show examples of how to export and read the information. Please download the following data using this code to follow the examples.

A. Vector Data

i. GeoPackage

A GeoPackage is ideal for encoding geospatial data when size and power are limited such as within a mobile device and is implemented in an SQLite database. It is slightly lighter in size than a shapefile, usually around 1.1-1.3x smaller and there is not limit on file size.

Some drawbacks are that the format is relatively young and the raster support in R is limited. It is very difficult to write multiband raster files using the common packages in R.

To export a geopackage the following code and the sf package can be used:

Next, you can read a geopackage using the simple st_read() function

ii. Shapefile

A shapefile consists of multiple files that together are read by a computer program which specifies geometry of features, projection, and metadata of the dataset.

• .shp - Mandatory. Contains the geometry for each feature - each record describes a shape with a list of its vertices

• .shx - Mandatory. Stores the index of the feature geometry

• .dbf - Mandatory. Dataset that stores the attribute information of features with a one-to-one relationship between geometry and attribute rows

• .prj - Necessary. Stores the metadata associated with the shapefiles coordinate and projection system. This file needs to be included or the data can not be used correctly

• .xml - Optional. Contains the metadata associated with the shapefile

• .sbn and .sbx - Optional. Two spatial index files that optimize spatial queries. These two files make up a shape index to speed up spatial queries

• .cpg - Optional. Describes the encoding applied to create the shapefile

Some drawbacks to using shapefiles are the following:

• Not a completely open format

• Lacks support for UNICODE character strings, therefore limiting the use of non-English languages

• Consists of multiple files which can easily be separated

• Field names can only be 10 characters or shorter in length

• Size limit of 2GB

• Can only have one type of geometry per file (only point data or only polygon data)

• Does not store geometry of features. e.g. polygons which are next to each other are independent and joining borders are coded as separate line segments, which can result in holes and islands.

To export and read a shapefile, the sf package can also be used.

iii. GeoJSON

Another vector format if the recommended formats are not possible is GeoJSON. GeoJSON is a simple open standard geospatial format that also represents features and associated attributes. This format is commonly used in web-based mapping. It is based on JavaScript Object Notation (JSON) and the standard format uses a geographic coordinate reference system, WGS 1984. Unlike shapefiles, it was not developed by a commercial company, but an internet working group of developers and thus is openly documented.

We recommend only using this format when data is simple points and lines as it is text based. Since it is text based, it is easy for humans to read directly and for machines to parse through and almost all GIS programs used for applications on the web can write and read GeoJSON data.

An important drawback worth mentioning is that it lacks support for projections. Additionally, there is no built-in support for embedding rich metadata about the dataset as a whole. Therefore, when using GeoJSON, provide the additional structured metadata with the json file so that the data is interoperable including an additional metadata file which specifies the projection and map datum.

To export and read a GeoJSON file the following code can be used. The option RFC7946 = YES needs to be used when exporting as it is a more recent and strict standard for GeoJSON.

iv. KML/KMZ

KML (Keyhole Markup Language) is a geospatial publishing format that enables easy visualization. The format is used primarily in the Google Earth Interface. The KML format focuses on visualization and allows one to encode what information to show and how to show it including annotation of images and maps and supports 3D textured models. KML supports display of rich data through icons and captions and can control the users view point directing where to look.

KML files can be created and edited on the google earth interface or can be drafted in an XML or simple text editor. When KML files are shared usually they are compressed and zipped into KMZ files. There are various ways to package a KML file, and thus we recommend other formats for storing or transferring geospatial data.

KML only uses one coordinate reference system and is not well suited for delivering large quantities of data.

To export a KML file from R, the following code can be used. First, the projection needs to be checked as KML only supports WGS84.

Next, the same functions st_write() and st_read() can be used

B. Raster Data

i. GeoTIFF and Cloud Optimized GeoTIFF

Raster data can come in a variety of formats such as png, tiff, or jpeg, commonly used for images, but here we focus on geospatial data formats. We recommend GeoTIFF for geospatial raster data. GeoTIFF is a formatted TIFF 6.0 raster file that embeds cartographic information into the raster image as tags. The format was originally developed as a format to distribute satellite or aerial photography imagery and is widely used.

There are many benefits to using the GeoTIFF format. There is strong software support in the form of open source libraries and many commercial and open GIS and spatial data analysis software products support reading and writing GeoTIFF data. It is highly interoperable, used worldwide, can store multiband raster data, and supported for many years.

The tags of GeoTIFF files, called tif tags should include the following metadata: extent, resolution, datum, projection (CRS), and values that represent missing data. These tags are incredibly important and are how programs recognize the spatial coverage and projection of the raster data.

GeoTIFF is not suitable for storing complex multi-dimensional data structures and has a size limit of 4GB.

To export a GeoTIFF file, the following code can be used with the raster package.

To read a GeoTIFF raster, just one line of code is needed

ii. Geopackage (raster)

We recommend using the GeoPackage format for storing raster data as well. Raster data is stored in a tile-based pyramid structure within the GeoPackage, therefore the imagery or raster information is stored at multiple resolutions. The parameters of the tiles can be set when writing the layer to the Geopackage. This tile-based pyramid structure is useful when handling a GeoPackage on a small device, as the appropriate resolution can be displayed based on the zoom level and screen size.

Please note that in R, currently support for writing multiband rasters in a GeoPackage is limited.

To write and read a GeoPackage with a raster layer within it, the following code can be used with the package stars

iii. NetCDF

Another option for storing geospatial raster data is NetCDF (Network Common Data Form) if a GeoTIFF will not suit your purpose or you were given data in NetCDF format. NetCDFs are often used for climate and large scientific raster data files, especially for storing multidimensional scientific data. NetCDF is used by a large community and is self-describing, portable, scalable, appenable, archivable, and is considered a standard. It is in the public domain, and thus open, well documented, and actively developed and maintained. NetCDF files support multidimensional arrays with multiple unlimited appendable dimensions but is not as commonly used as GeoTIFFs.

Some limitations to NetCDFs are that they are not as user-friendly to work with especially in R, they do not support nested structures, and no real compression is supported.

Next, we will store the elevations and grid dimensions in variables.

We will now define the spatial dimensions of the data (lat / long) and then use ncvar_def to define a variable in the netCDF file that will hold the elevation data.

We will now create the netCDF file and add the variables into the file. At this step, one can add additional metadata such as title, affiliated institution, source, references, etc.

Finally, close the file, which writes the data to disk.

Now, let’s move onto opening the netCDF file we just created.

Next, we will extract the coordinate variables and elevation variable.

Now, one can create a plot from the netcdf file.

C. Resources and useful R packages for handling spatial data

While information on the various formats for spatial data are incredibly important to understand when using and sharing geospatial data, we would also like to recommend a few packages for handling spatial data in R.

Finally, here is a table summarizing the recommended r packages for each data type with links to more guides on how to read, convert, and write in R between these formats:

Table 2: Recommendations for handling these file formats in R

* Important note: The commonly used package raster will be replaced by the new package terra as rgdal, one of the key packages it uses, will be retired in 2024. There are many more resources available online to guide people on how to use these packages than those mentioned.

III. Tabular Files

The rest of this technical guideline will go through recommended file formats for tabular, textual files, and image files with less detailed information.

i. Structure

Often when one pictures data, they don’t think of complex geometries, but rather tabular data such as a list of field sites and associated variables recorded in an table or a survey responses in an excel sheet. Tabular data is data structured into rows and columns and can be wide or long.

Wide data is where each different variable is listed in a separate column, while long data is structured so a row is one observation, therefore one column contains all values, and another column contains the variable. Often with small amounts of data, a wide table can be more easily interpreted by humans, while long data is often required for running statistical analysis in computer programs. The use of the long format is highly recommended!

Table 3: Example of wide data

Table 4: Example of long data

We recommend the following open file formats for tabular data which does not include Excel sheets.

ii. CSV / TXT

A CSV file (Comma Separated Variable) file is a text based data file that describes tabular data. Each row is one line, and the columns are separated by commas.

It is widely used as a data exchange format and highly recommended. If your tabular data do not contain commas, than a CSV file is the recommended choice. If your data do contain commas, such as survey responses, one can delineate columns in a TXT file based on tab’s or other characters such as semicolons.

To export a table as a CSV file or tab delineated file in R, follow and adapt this code:

IV. Textual Files

For files mostly comprising of text, such as transcripts and survey questions, we recommend .txt, .pdf, or .docx files which are explained in more detail below. While .docx are not open and therefore not ideal, currently the IPBES communitiy relies on them heavily and thus this format is still recommended. When using .docx, also export the document to a pdf when submitting the data to a repository.

i. TXT

A .txt file, is a plain text file that just contains text, therefore it is human-readable and interoperable. This file can be opened in any text editor and almost all operating systems come with text editors that allow you to easily create, open and edit text files. There is no limitation on the size of contents. The default character set of text files is ASCII, but they can also be saved in Unicode format, such as UTF-8 which is acceptable.

ii. PDF

A PDF (Portable Document Format) was originally created by Adobe back in the 1990s, but was released as a open format in 2008. PDFs allow one to view documents easily independent of application software and operating system that is why presentations are often shared in PDF format as opposed to a powerpoint file. The PDF file format has the ability to contain not only text, but images, hyperlinks, form-fields, digital signatures, attachments, and other information. PDFs are very suitable for long-term storage of documents, as they are independent of application software.

iii. DOCX

DOCX files are Microsoft Word documents. This format is not open and is not interoperable. While TXT and PDF files are preferred to DOCX files, the IPBES community relies heavily on DOCX files and thus it is still acceptable to use this format. In 2007, the original standard DOC file format was updated to a new standard DOCX file, where the addition of the X stands for XML. When using .docx, also export the document to a pdf when submitting the data to a repository.

V. Image Files

Vector formats are superior to raster formats for most images such as line drawings, including plots, graphs, or logos. Vector formats will never look pixelated, as they are not based on pixels, but rather mathematical forumlas that define geometric objects such as polygons, lines, and curves. Vector images are more malleable than raster images, smaller in size, faster to display, and perfectly scalable.

Raster images are based on pixels with a defined resolution and are the preferred format for photographs or non-line art images. One of the largest considerations for raster image files is resolution. Resolution is often reported in the units DPI, dots per inch. As resolution increases, clarity and the size of the file increases. The standard for displaying images on websites is 72dpi, for printing it is 300dpi or higher, and for submitting figures for publications it is 600dpi.

Vector Image Files

i. SVG

SVG (Scalable Vector Graphics) is a vector image format, which uses XML text to specify lines and color. SVG is a great option and highly recommended for graphs, logos, and illustrations, especially for publishing materials on the internet. It is supported by all major browsers, but most default image editors do not support SVG. It should not be used to save photographs.

To export a SVG file from R, one can use this base code and add additional arguments such as height, width, point size, to the svg() function.

ii. EPS

EPS (Encapsulated PostScript) was created by Adobe in 1992 and is based on Postscript rather than XML. EPS was originally intended for a print workflow not an online workflows and is no longer in development. EPS file format is recommended and better than SVG for high-quality document printing, printed logos, and marketing materials.

To export a EPS file from R, one can use this base code and add additional arguments to the postscript() function.

iii. PDF

PDFs (Portable Document Files) mentioned previously under the textual files section can also be saved as a vector file. Vector formated PDFs allow one to easily select objects and are preferred to raster formatted PDFs. PDFs can have a mix of vector and raster content, but when exported from R, the graphics will be in vector format. If scanned, the PDF will be in raster format.

To export a figure as a PDF file from R, one can use this base code and change and add additional arguments to the pdf() function.

Raster Image Files

i. PNG

PNG (Portable Network Graphics) files are a type of raster file format that supports lossless data compression and has no copyright limitations. We generally recommend PNG files for storage and sharing images online. The lossless compression means that there is no loss in quality each time it is opened and saved again. PNG only supports the RGB color space and not CMYK, and does not support animations.

To export a PNG file from R, one can use this based code and change and add additional arguments to the png() funciton.

ii. JPEG / JPG

In comparison, JPEG (or JPG) files are raster files that are often used online for displaying images as they are fast to load. It has lossy compression which means each time it is saved it reduces in file size but also in quality. We do not recommend JPEG files for long term storage, except in the case of images which come from e.g. cameras as nothing is gained in converting an original JPEG into a PNG.

To export a jpeg file from R, one can use this base code and change and add additional arguments to the jpeg() argument, although we discourage exporting graphs in jpeg.

iii. TIFF

Another option is TIFF. A TIFF (Tagged Image File) is a raster file that also supports lossless compression. We do not recommend using this tile type on websites as it is slow to load due to its large size and has limited browser support, but it is recommended for long term storage or publications. If there are no concerns about losing embedded metadata and tags, in general, it makes sense to convert a TIFF image to PNG as it reduces the size and is lossless.

To export a TIFF image file from R, one can use this base code and change and add additional arguments to the tiff() function, although we discourage exporting graphs in tiff.

Full report

Summary for Policy Makers

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 5.0

Chapter 5.1

Chapter 5.2

Chapter 5.3

Chapter 5.4

Chapter 5.5

Chapter 5.6

Chapter 6

Chapter 7

Prepared by Joy Kumagai - IPBES Technical Support Unit (TSU) of Knowledge and Data Reviewed by the Task Force on Knowledge and Data (Hanno Seebens, Rainer Krug, András Báldi, Xubin Pan, and Aidin Niamir)

Version: 1.1 Last Updated: 14 July 2022

This technical guideline provides guidance on figures within IPBES assessments, with particular emphasis on long-term storage in repositories. The guideline is intended for IPBES assessment technical support units or anyone storing figures within IPBES assessments.

I. Overarching guidance

• All figures, except for those borrowed (i.e. not modified) from external sources, are stored on Zenodo. Figures can then be accessed in the long-term, enabling reuse by others and future IPBES experts.

• When uploading a figure to a repository, please specify which chapter it belongs to and the figure number. Additionally, please include the related identifiers, specifically the DOI of the assessment chapter and/or the associated data management report it appears in. At a quick glance, viewers should be able to track where a figure appears within the assessment.

• It is incredibly important that permission for any borrowed or adapted figures is granted and documented as early as possible. If permission can not be secured, then the figure can not be used in the assessment.

II. Double check these items

Please double check the following items to ensure the figures are in line with IPBES guidance.

• Colors used in figures are color blind friendly.

III. What to include in each repository

Depending on the type of figure, there are different items that need to be part of the repository and checked. Please go through the following lists for each figure in the assessment.

A. Created by IPBES experts

• Schematic figures

  • Upload the native/original file of the figure (e.g. powerpoint file).

  • Upload the figure in an open format and high resolution (600 dpi).
• Data driven figures

  • Upload the workflows/scripts that were used to create the figure.

  • Upload the data sources themselves or specify the references to the data sources underlying the figure in the associated data management report, which can be included in the same repository.

B. Created by an external source

• Borrowed figures (unmodified)

  • These figures do not need to be uploaded to Zenodo, but please check the following:

    • Permission to reuse the figure has been granted and recorded.

    • The source of the figure is cited properly in the Zotero library.

    • The figure is in high resolution (600 dpi or vector format).
• Adapted figures (modified)

  • Specify the usage rights.

  • Please also check:

    • Permission to reuse and adapt the figure has been granted and recorded.

    • The source of the figure is cited properly in the Zotero library.

IV. Examples

In this section, examples for each type of figure are provided with links to the associated data deposit pacakge, except for borrowed figures which do not need a data deposit package.

Original schematic figure

Original data driven figure

Adapted figure

These assessment directories have been propared by the technical support unit for data, and reviewed by the task force on knowledge and data and the technical support unit for invasive alien species.