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.

1. Conversion to the Robinson Projection

2. Preparing and Mapping Data to IPBES Regions and Subregions

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 and Peter Bates Reviewed by Aidin Niamir, the Task Force on Knowledge and Data and the Task Force on Indigenous and Local Knowledge

For any inquires please contact [email protected] and [email protected]

Version: 1.0 Last Updated: 18 July 2022

DOI: 10.5281/zenodo.6655926

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

It is my pleasure to invite you to be a Contributing Author for the assessment of [assessment name], that is being developed by the . Specifically, you are invited to contribute to Chapter [#] on [Chapter title]. Your contribution would focus on the section on [topic], and you would be working with [IPBES authors names], who are [Lead Author(s)/Coordinating Lead Author(s)] of the assessment and copied on this email.

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

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.

If you choose to share any previously unpublished Indigenous and local knowledge or materials, you will be asked to confirm that you are authorised to share this information and confirm that it is non-confidential as specified in our guidance on documenting Indigenous and local knowledge ().

To enable open science and accessibility within IPBES, the Platform has a data and knowledge management policy available at .

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 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 [email protected]

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.

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

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.

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

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

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

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.

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.

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

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.

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

*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

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:

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)

For any inquires please contact [email protected]

Version: 1.0 Last Updated: 19 August 2022

DOI: 10.5281/zenodo.6882518

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

Referenced and used within many biodiversity-related policy documents and instruments, indicators can help us to understand the current state of biodiversity at the ecosystem and species levels, threats and pressures, and conservation responses. They are incredibly important in our current science-policy interface enabling decision making from the international sphere to local responses. As defined by the , an indicator is "a measure based on verifiable data that conveys information about more than itself." Indicators often take the form of final datasets resulting from a workflow. An indicator workflow is defined here as the steps performed between the input data and final indicator. Successful biodiversity indicators have a variety of attributes such as scientifically valid, updated over time, responsive to change, easily understood, and consistent as described in the document " (Brooks & Bubb 2014)."

Clear and accessible documentation is necessary for indicators to be effective, consistent, and trustworthy. Unfortunately, indicator workflows often do not follow the (findable, accessible, interoperable, and reusable) and (collective benefit, authority to control, responsibility, and ethics) principles and are not reproducible by other scientists. For example, small differences in how geospatial layers or assumptions are treated can lead to vastly different results. There needs to be transparency in the underlying calculations, to maintain consistency and ensure reuse by others. IPBES is committed to following the open science principles and increasing transparency in data management. Therefore, this guideline discusses how indicators developed within IPBES should be documented starting from the input data, through processing, to outputs to enable reuse by the community.

Throughout this guideline, we will use the indexes from the publication, , as an example for documentation. The data descriptor paper published in Scientific Data describes two indexes which report on how much of six important marine habitats are within protected and conserved areas at the country and global scale

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;

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:

• The workflow used to calculate the indicator is contained in reproducible scripts, preferably in an open-source software as explained in Session 4.2 within the IPBES data management tutorials, '';

• Version control software (such as behind github) is used to track, store, and share the development as well as the different versions of the workflow, which is especially useful when collaborating in a team. GitHub can not only be used to store the workflow, but the repository can be linked to a Zenodo account () to make the code citable. Other repositories can also be used. Any new releases of the code should be published with Digital Object Identifiers (DOIs) ensuring traceability;

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;

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.

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

References

1. Brooks, S. and Bubb, P. (2014) Key Knowledge for Successful Biodiversity Indicators UNEP-WCMC, Cambridge, UK 12pp.

2. Kumagai, J.A., Favoretto, F., Pruckner, S. et al. (2022) Habitat Protection Indexes - new monitoring measures for the conservation of coastal and marine habitats. Sci Data 9, 203.

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 [email protected] and [email protected]

Version: 1.1 Last Updated: 14 July 2022

DOI: 10.5281/zenodo.6834183

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;

• Specific materials are developed to make assessment findings more accessible to IPLCs. For example, the document ;

4. Ensuring that access to confidential ILK is restricted

• Through direct discussion with IPLCs, including in the dialogue workshops, and through work with the task force on ILK, IPBES authors and TSUs should seek to determine the appropriate accessibility of materials submitted by IPLCs. With the formally documented consent of those providing the materials, these confidential materials may be documented and stored in long-term repositories (e.g. Zenodo) with restricted access. Authors should contact the data and knowledge TSU () and ILK TSU () to coordinate this process.

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

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

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.

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 [email protected]

Version: 2.3 Last Updated: 15 August 2022

DOI: 10.5281/zenodo.6992546

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 download the shapefile manually, please go to the .

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.

We chose to project the data into the Robinson projection as it minimizes distortions in both area and distance. To find the proj4 notation please visit .

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.

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

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 [email protected]

Version: 1.1 Last Updated: 14 July 2022

DOI: 10.5281/zenodo.6834336

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

For IPEBS, is the repository for long term storage of all IPBES products, including milestones, data deposit packages and associated data management reports.

The IPBES secretariat has created and is maintaining one single community on Zenodo for IPBES () where the goal is to provide:

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.

2. can be used to become familiar with the interface and practice without permanently 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

B. How to reserve a DOI

To obtain a digital object identifier for an entry on Zenodo, please first log into your account and start . Note that the account should be affiliated with your IPBES email address if available.

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.

Each Zenodo entry requires that at least one author name is listed per repository item. The author names then appear on the repository web page directly underneath the title and are added to the citation. The contributor names appear one line below the authors on the website and are categorized according to their specific role, but these names are not listed within the citation. An example of this can be found within the upload where the author is listed as the IPBES task force on knowledge and data, but editors, project leaders, and project members are specified to acknowledge the specific contributions of the members.

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

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)

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

For a descriptive step by step guide on this process, please visit the available is also helpful to understand how to create a new release that is synced between GitHub and Zenodo.

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]

For example, see the Zenodo upload of this technical guideline here:

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.

One can find this additional DOI in the versions section of the published webpage of the upload. For example, when referring to the IPBES data management policy (figure 5) we use this doi:

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.

Within Python, there's a package available on GitHub which allows one to download from Zenodo using the function zenodo_get.

Within R, there's a handy function called from the package that allows one to download from Zenodo easily.

To illustrate this in R, all of the files associated with the Zenodo repository can be downloaded programmatically at once with the following code:

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:

For any questions please feel free to contact us at . If you have any Zenodo specific questions they may be answered on their .

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 [email protected]

Version: 1.1 Last Updated: 15 July 2022

DOI: 10.5281/zenodo.6839037

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

Spatial data generally fall into either vector or raster data. Vector data consists of points, lines, and polygons that are based on point locations. Raster data is grid-based data, such as pixels on a screen or an image. Raster data is either continuous or discrete, for example a temperature dataset is continuous or a land cover dataset with classes is discrete. For more information on these geospatial data types and a general introduction to geospatial concepts please visit . Additionally, for a complete list of geospatial formats please reference .

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

We recommend using the GeoPackage format for storing geospatial information. This file format is new and less widely used, but a completely open format for storing geospatial data. As stated on “GeoPackage is an open, standards-based, platform-independent, portable, self-describing, compact format for transferring geospatial information.” A GeoPackage can store both vector and raster data (as tiles) and can have multiple layers per single file. The format allows for multiple geometry types per file, so one can store both point and polygon data within the same file.

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.

We generally encourage everybody to use the GeoPackage format because of these reasons. Existing shapefiles can be converted by using the package stars in R and

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.

If you are interested in understanding all of the file types and contents in a GeoPackage detailed information on the structure of a GeoPackage can be found .

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 is the most widely used vector type spatial data format and is recommended although it is not ideal and needs be used correctly. The geometry of a feature is stored as a shape comprising of a set of coordinates. Each feature is associated with a list of attributes within a table. Shapefiles can be used with almost all geospatial software and are well supported by open source software libraries. It was developed and currently regulated by ESRI, a commercial company. More information on shapefiles can be found on .

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.

All files within one shapefile share the same file name with different extensions. These files can not be separated from each other and should be zipped into a single archive when being transferred. The mandatory and some optional extensions are included below but more are described on the ESRI website .

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

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

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.

More technical information can be found on the Sustainability of Digital Formats website which supports the US Library of Congress Collections.

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.

More information on KML is available from Google.

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.

More information can be found on from the NASA standards and references webpage.

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

Recently, a format called, , has become increasingly popular which is a regular GeoTIFF file aimed at being hosted on a HTTP file server. This standard was developed in 2016 within the Open Source Geospatial Foundation project. The format enables efficient workflows on the cloud by utilizing tiling and overviews. It allows for efficient imagery data display and access through HTTP GET range requests, so end-users can just use the parts of the GeoTIFF they need. A cloud optimized GeoTIFF is larger in size than a normal GeoTIFF, but it enables faster access on a server.

If you are interested in exporting Cloud Optimized GeoTIFFs, one option is to use the write_tif function from the gdalcubes package described

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.

More information on how the tiles are stored within the GeoPackage can be found

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.

NetCDF was developed and maintained at Unidata. On their website they provide tutorials and documentation. A quick factsheet with more information is available .

R is able to read and write netCDF files using the package ncdf4. For a full tutorial on how to read and write netCDF files, please refer to

We will now go through a very simple example starting with formatting and exporting NetCDF data adapted from and finally importing the netCDF we create. We will use the base R volcano dataset.

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

For more information on these geospatial data types and other types can be found here as well:

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.

The sf package is used to handle vector data, while the terra and raster packages are often used to handle raster data. The packages sf and raster have been used throughout these technical guidelines. For an overview on these packages, I recommend the vignettes on for each of the packages linked below.

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.

A CSV file can be created from an excel sheet easily described , written in a txt file, or created in R or other computer programming languages. Text files are highly interoperable and can be imported and exported by almost any software designed for storing or manipulating data.

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.

More information on the PDF file format can be found .

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.

If you interested, more technical information can be found .

V. Image Files

There are many different image file formats that one can choose from when exporting images. We recommend commonly used formats that are open and interoperable, such as SVG or PNG, but other formats may also be appropriate depending on the use case. Similar to geospatial information, there are two image file types vector and raster. For a more comprehensive list of image file formats please see

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.

Thank you for your time. If you have any suggestions on further content or file format types you would like to see covered please contact us at the technical support unit at .

Prepared by the technical support unit of knowledge and data

For any inquires please contact

Version: 6.0 Last Updated: October 6th 2025

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.