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. Introduction to IPBES data management tutorials (10.5281/zenodo.4014762)

   • 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. IPBES data management policy (10.5281/zenodo.4014790)

   • 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. IPBES data management reports (10.5281/zenodo.4014792)

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

4. Data management of active research data (10.5281/zenodo.4014796)

   • 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. Tools for data management (10.5281/zenodo.4014798 )

   • 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.

6. Examples of implementing the IPBES data management Policy (10.5281/zenodo.4014802)

   • Contains examples of how certain data management tasks and workflows were implemented within IPBES so that they follow the data management policy. These are currently legacy videos and the most recent examples can be found within the technical guidelines here: https://ict.ipbes.net/ipbes-ict-guide/data-management/technical-guidelines

Access the content

To view these tutorials online, please visit the ipbes website here: https://ipbes.net/dmp/tutorials. The associated youtube videos can be opened by clicking on the session names.

To download these tutorials and their associated content from Zenodo, please click on the overview description here: https://doi.org/ 10.5281/zenodo.4020373 where you can navigate to each chapter and then individual section.

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.

Version: 1.0 DOI: https://zenodo.org/doi/10.5281/zenodo.10004399

The Organisation of Work, consists of three separate parts:

• A - File Naming Convention,

• B - Versioning Scheme and

• C - Experts Lists

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.

All source files are also available on our GitHub. For any questions, feedback, or suggestions for future guidelines, contact aidin.niamir@senckenberg.de.

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.

If interested, all source files are available on my . For any questions, feedback, or suggestions for future guidelines, contact

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.

Prepared by Joy Kumagai - Technical Support Unit (TSU) of Knowledge and Data Reviewed by Aidin Niamir - Head of the Technical Support Unit of Knowledge and Data For any inquires please contact aidin.niamir@senckenberg.de

Version: 2.1 Last Updated: 15 July 2022

DOI: 10.5281/zenodo.6840235

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)

Next, we define the Robinson projection using PROJ.4 notation. This information can be found at the this link.

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

Your feedback on this content is welcome. Let us know what other useful material would you like to see here by emailing aidin.niamir@senckenberg.de.

*The warnings of discarding the datum but preserving the +towgs1984 = values stem from an update from PROJ4 to PRROJ6 but is not worriesome in this case. The +datum= part is depreciated from GDAL >3 and sf, rgdal, and raster packages use GDAL to read files. There is a stackoverflow thread with more information here

Introduction

This repository holds the public user documentation for IPBES data management and IT services and tools. It is hosted on

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

Our documentation is public because we want your help in improving and maintaining it. See our for guidelines on filing pull requests. All documentation is released under the Creative Commons Attribution license.

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

Our documentation site is built using . GitBook uses Markdown as its file format.

• 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

Prepared by Joy Kumagai - Technical Support Unit (TSU) of Knowledge and Data Reviewed by Aidin Niamir - Head of the Technical Support Unit of Knowledge and Data For any inquires please contact

Version: 3.0 Last Updated: 15 August 2022

DOI:

This technical guideline will review the necessary and suggested cartographic elements for maps produced as part of IPBES assessments. The guide is split into four sections, cartographic elements, disclaimers, country borders, and general suggestions and have examples of maps and the code behind them throughout. This guideline is intended for anyone involved in the process of creating maps within IPBES assessments.

Begin by loading the following packages.

I. Cartographic Elements and considerations for IPBES assessments:

A. Cartographic Elements

Generally the following cartographic elements should be included within each map:

• Map with frame and legend

• Graticules (North arrow and scale are not needed when graticules are included)

• References for each of the layers used to make the map are required within each data deposit package associated with the map

Generally these elements do not need to be included with each map for assessments:

• North arrow and scale bar - do not need to be included when graticules are present

• Titles - should not be included within the map’s frame, but rather included in the caption.

Here is an example of creating a world map with these elements. The following code downloads land and ocean polygons from rnaturalearth package, creates latitude and longitude labels and graticules, and then plots a global map in robinson projection.

The messages describe the data and where it is downloaded locally.

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

Now we set up the plotting frame, and plot the graticules, ocean, land, and latitude and longitude lines.

We can also use the ggplot package, with some additional functionality added with ggspatial, to map sf objects in R Studio such as in the following example:

B. Projections

IPBES has adopted the Robinson projection for all global scale maps.

The Robinson projection balances distortions in area, direction, distance, and distortions near the poles. We encourage the use of Pacific centered maps when focused on marine or Pacific themes. The pacificCentric function within the envirem package can reneter a raster on the Pacific.

For maps of countries or regions, national or appropriate regional projections are recommended. If there is no specific country projection available, the relevant Universal Transverse Mercator zone projection is suggested.

C. Color Considerations

II. Disclaimers:

The standard disclaimers that should appear on all maps within IPBES assessments are the following:

Short form

The boundaries and names shown, and the designations used on the maps shown here do not imply official endorsement or acceptance by IPBES.

Long form

The designations employed and the presentation of material on the maps used in the assessment do not imply the expression of any opinion whatsoever on the part of 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. These maps have been prepared or used for the sole purpose of facilitating the assessment of the broad biogeographical areas represented therein and for purposes of representing scientific data spatially.

III. Country Borders

If a map displays data at the country-level, special consideration needs to be taken when drawing country borders. IPBES follows current UN guidance on country borders for original global-scale maps. To assist with following the UN guidance, the technical support unit on knowledge and data and the secretariat have created a package of resources, including shapefiles, to use when displaying country borders.

Before you begin, please double check that the data is displayed at the country level and not the territory level. If your data is at the territory level ensure this is reflected in the caption and text and it is not required to follow these guidelines.

In summary, there are five layers that need to be added to the map in this order: grey areas, solid borders, dashed borders, dotted borders, and major lakes. The major lakes are used to represent cross-border waterbodies serving as a border between countries.

First, load all shapefiles into the R session and project each into the Robinson projection. The function, st_wrap_dateline(), is used to correct borders that cross the dateline.

Now, the next section of code can be split into three categories, plotting the base global map used earlier (section IA), plotting the borders in the correct order, and finally adding the graticule lables to the map.

A line width of 0.1 (lwd = 0.2) is used throughout. Lty controls the type of line, while border controls the color of the border for polygon data and can be set to transparent by using border = NA. Besides the grey areas, which should be slightly darker, the same grey shade is used for all borders (col = "grey40").

Finally, in your maps check that the colors within the map match UN guidance paying particular attention to Taiwan, Falkland Islands (Malvinas), and Arunachal Pradesh.

IV. Suggestions:

Streamlining the design of maps allows for better comparison and integration. Therefore, to facilitate the standardization of maps within IPBES, we recommend the following:

• Include all continents in global maps, including Antarctica

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

• Color schemes should be consistent with the ones used for figures.

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

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

• Do not add excessive labels which interfere with interpretation of the map as a whole

Here we also include some popular resources for global and country scale spatial data:

• Standardizing country names:

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)

For any inquires please contact aidin.niamir@senckenberg.de

Version: 1.0 Last Updated: 16 October 2023

DOI: 10.5281/zenodo.10004409

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)

The GDPR is a regulation on data protection and privacy in the EU, which protects the privacy and personal data of all EU citizens. It is rooted in seven principles for privacy: lawfulness, fairness and transparency (gathering data with a valid legal basis in the best interest of the people data is collected from, and transparent in a way that it is clear what, how and why data is collected); purpose limitation (using the data only for the initially stated purpose); data minimisation (not gathering more data than is necessary); accuracy (data must be correct and up to date); storage limitations (deleting personal data when it is not needed anymore); integrity and confidentiality (ensuring that the data cannot be manipulated by others and making sure that the only people with access to personal data are the ones processing it); and accountability (taking responsibility for proper processing of personal data and compliance with the rules of the GDPR).

There are comparable rights and laws for other countries and regions, such as the Data Protection Act 2018 in the UK, the Privacy Amendment to Australia’s Privacy Act, the Personal Information Protection Law in China, the Nigeria Data Protection Regulation, the South Africa’s Protection of Personal Information Act, and the Digital Charter Implementation Act in Canada. Personal data can be sensitive, and it is therefore important that these data are collected and stored with the consent of the experts.

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).

• Country: Both the country of nationality and the country of residence, if different. The country names have to follow the UN recommendations.

• 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

• ORCID iD: Optional. An ORCID iD is a personal digital identifier, which is often used by researchers to increase findability of their work and the distinguishing from other researchers with the same or a similar name. It is highly recommended for all contributors to obtain an ORCID iD to make them uniquely attributable, even if they are not publishing in the academic sector. The tsu for data can help with any problems encountered during the registration process.

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

The excel template (CSV with UTF-8 formatting) for the experts list, including example information of a fictional expert called John Smith.

Prepared by Joy Kumagai - Technical Support Unit of Knowledge and Data Reviewed by Aidin Niamir - Head of the Technical Support Unit of Knowledge and Data For any inquires please contact

Version: 2.3 Last Updated: 15 August 2022

DOI:

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.

I. Downloading Necessary Data

A. Downloading FAO data

The first step is to download the FAO data using the FAOSTAT package. The url can be found in FAO STAT’s data description file

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

Now, we choose the palette and plot by 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

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

We can also plot by subregion.

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)

For any inquires please contact

Version: 1.1 Last Updated: 27 February 2024

DOI:

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

Prepared by the technical support unit of knowledge and data

For any inquires please contact

Version: 5.0 Last Updated: November 8th 2024

DOI:

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

Thematic Assessment Report on the Underlying Causes of Biodiversity Loss and the Determinants of Transformative Change and Options for Achieving the 2050 Vision for Biodiversity of the Intergovernmental Science-Policy Platform on Biodiversity and Ecosystem Services DOI:

IPBES (2024). Thematic Assessment Report on the Underlying Causes of Biodiversity Loss and the Determinants of Transformative Change and Options for Achieving the 2050 Vision for Biodiversity of the Intergovernmental Science-Policy Platform on Biodiversity and Ecosystem Services. O’Brien, K., Garibaldi, L., and Agrawal, A. (eds.). IPBES secretariat, Bonn, Germany. DOI:

Download the . Download the .

Summary for policymakers

Summary for Policymakers of the Thematic Assessment Report on the Underlying Causes of Biodiversity Loss and the Determinants of Transformative Change and Options for Achieving the 2050 Vision for Biodiversity of the Intergovernmental Science-Policy Platform on Biodiversity and Ecosystem Services DOI:

IPBES (2024). Summary for Policymakers of the Thematic Assessment Report on the Underlying Causes of Biodiversity Loss and the Determinants of Transformative Change and Options for Achieving the 2050 Vision for Biodiversity of the Intergovernmental Science-Policy Platform on Biodiversity and Ecosystem Services. O’Brien, K., Garibaldi, L., Agrawal, A., Bennett, E., Biggs, O., Calderón Contreras, R., Carr, E., Frantzeskaki, N., Gosnell, H., Gurung, J., Lambertucci, S., Leventon, J., Liao, C., Reyes García, V., Shannon, L., Villasante, S., Wickson, F., Zinngrebe, Y., and Perianin, L. (eds.). IPBES secretariat, Bonn, Germany. DOI:

Download the . Download the .

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 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

For any inquires please contact

Version: 1.1 Last Updated: 14 July 2022

DOI:

Within this guideline, we cover how to upload, share, and download to Zenodo both manually and programmatically. This technical guideline is intended for IPBES technical support units and provides useful tips and options, but does not seek to be comprehensive. The material presented here incorporates and builds upon the guide available here: .

I. Zenodo overview

is a general-purpose free and open-access repository operated by the European Organization for Nuclear Research (CERN). It allows researchers in any subject area to deposit data sets, research software, reports, and any other research related digital artifacts.

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:

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)

For any inquires please contact

Version: 1.1 Last Updated: 14 July 2022

DOI:

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.

• Please provide editable, high resolution figures in vector format which enables graphic designers to edit the figure. Vector formats could be pdf, eps, or others as specified in the . If the graphic designer needs to edit a figure, the new version should be uploaded to the same repository as an additional file.

• 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.

• If there are country borders displayed, there are certain rules for borders and a few regions that need to be adhered to ().

• World maps are in the .

• Country names are in within figures. If full names are needed in captions for clarity, they are fully spelt out according to current UN guidance. Names can be double checked with the interactive map on .

• Colors used in figures are color blind friendly.

• Licenses behind IPBES original figures are or .

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

Prepared by Joy Kumagai - Technical Support Unit (TSU) of Knowledge and Data Reviewed by Aidin Niamir - Head of the Technical Support Unit on Knowledge and Data For any inquires please contact

Version: 1.1 Last Updated: 15 July 2022

DOI:

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.

Revised by Renske Gudde - Technical Support Unit (TSU) of Knowledge and Data Reviewed by Aidin Niamir - Head of the Technical Support Unit of Knowledge and Data and Rainer M. Krug - IPBES Task Force on Knowledge and Data For any inquires please contact

Version: 1.2 Last Updated: 9 November 2023

DOI:

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:

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

When creating a map or figure, please choose colour schemes that are colour blind friendly (more information about or about ). Printing a map or figure in black and white or grey tones are a good method to see how well the map or figure is interpretable without colour. Especially for maps, when areas without sufficient data are indicated, it is advisable to use a pattern instead of grey scales, because without the use of colour it can seem that there is a value for the data deficient areas.

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:

To display all of the colourblind friendly palettes run this:

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

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:

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.

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.

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.

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

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

For any inquires please contact and

Version: 1.1 Last Updated: 14 July 2022

DOI:

I. Introduction

The purpose of this technical guideline is to provide practical guidance for all IPBES authors and technical support units on how to work with and document Indigenous and Local Knowledge (ILK*) within IPBES. All IPBES experts working with ILK are expected to follow the requirements in the and free, prior, and informed consent (FPIC) as laid out in the .

The policy specifically requires all experts to follow the (Collective benefit, Authority control, Responsibility and Ethics) and the (Findable, Accessible, Interoperable and Reusable). The policy is also built upon the concept of open science, reflected within the . IPBES experts are also required to follow the IPBES process for adhering to the FPIC principles when working with ILK. Please refer to the methodological guidance which provides a detailed process for ensuring that FPIC principles are followed for assessments.

This guideline provides both practical advice and key considerations on how to apply these principles. Applying the principles will require careful consideration on a case-by-case basis, as opposed to following a rigid protocol. Additionally, this guidance is not intended to be comprehensive and depending on the nature of the project, other ethical guidelines could be consulted. Please contact the technical support unit on data () and/or the technical support unit on indigenous and local knowledge () with any specific questions, concerns, or recommendations. Note that this guideline is a working document and may be periodically updated. The newest version will always be available via

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