Skip to content

Commit

Permalink
Merge pull request #89 from NINAnor/anders-kolstad/issue62
Browse files Browse the repository at this point in the history 
Anders kolstad/issue62
  • Loading branch information
@anders-kolstad
anders-kolstad authored Jan 9, 2025
2 parents e137227 + 604d078 commit 98826b5
Show file tree
Hide file tree
Showing 3 changed files with 98 additions and 41 deletions.
2 changes: 2 additions & 0 deletions .gitignore
View file
Original file line number Diff line number Diff line change
Expand Up @@ -36,3 +36,5 @@ po/*~
rsconnect/
README.html
ecRxiv.Rproj
indicators/template/R/document_indicator_here_and rename_file.html
man/workflow.vsdx
137 changes: 96 additions & 41 deletions indicators/template/R/document_indicator_here_and rename_file.qmd
View file
Original file line number Diff line number Diff line change
@@ -1,9 +1,16 @@
---
title: "Enter indicator name here"
subtitle: "[INDICATORID]"
format:
html:
embed-resources: true
code-fold: true
toc: true
toc-title: Contents
toc-depth: 3
smooth-scroll: true
execute:
cache: true
author:
- name: John Doe # Enter name
email: [email protected] # Enter email
Expand All @@ -13,12 +20,17 @@ author:
- name: Jane Doe # Enter subsequent authors like this, or remove if not relevant
affiliations:
- ref: myID # To reuse affiliations referecen the id like this
date: April 10, 2024 # Enter date
date: January 1, 1901 # Enter date
callout-icon: false
lightbox: true
css: ../../../style.css
code-links:
- text: Add a review
icon: github
href: https://github.com/NINAnor/ecRxiv
---

<!--# This is a template for how to document the indicator analyses. Make sure also to not change the order, or modify, the headers, unless you really need to. This is because it easier to read if all the indicators are presented using the same layout. If there is one header where you don't have anything to write, just leave the header as is, and don't write anything below it. If you are providing code, Be careful to annotate and comment on every step in the analysis. Before starting it is recommended to fill in as much as you can in the metadata file. This file will populate the initial table in your output.-->
<!--# This is a template for how to document the indicator analyses. Make sure also to not change the order, or modify, the headers, unless you really need to. This is because it easier to read if all the indicators are presented using the same layout. If there is one header where you don't have anything to write, just leave the header as is, and don't write anything below it. If you are providing code, be careful to annotate and comment on every step in the analysis. Before starting it is recommended to fill in as much as you can in the metadata file. This file will populate the initial table in your output.-->

<!--# Load all you dependencies here -->

Expand Down Expand Up @@ -87,17 +99,12 @@ status(st)

::: {layout-ncol="2"}

::: {.callout-note style="background: cornsilk;"}
## Recomended citation

`r paste(auth, " ", year, ". ", name, " (ID: ", id, ") ", "v. ", version, ". ecRxiv: ", url, sep="")`
:::

::: {.callout-note style="background: khaki;"}
## Version
> **Recomended citation**: `r paste(auth, " ", year, ". ", name, " (ID: ", id, ") ", "v. ", version, ". ecRxiv: ", url, sep="")`
> **Version**: `r version`
`r version`
:::
:::

```{=html}
Expand All @@ -119,27 +126,36 @@ meta |>
```{=html}
</details>
```
# Indicator name

<!--# Replace 'indicator name' with your the actual indicator name -->

<br />

<!--# Don't remove these three html lines -->
::: {.callout-note collapse="true"}
<!--# Update this logg with short messages for each update -->
## Logg
- 01 Jan. 1901 - Original PR
:::

<br /> <br />

<hr />

<!--# Document you work below. -->

## 1. Introduction
## 1. Summary

<!--#
<!--# Describe the indicator in general terms. It is a good idea to include a bullet point list of the spesific steps in the workflow -->
With a maximum of 300 words, describe the indicator in general terms as you would to a non-expert. Think of this as a kind of commmon language summary. It is a good idea to include a bullet point list of the spesific steps in the workflow. Include a mention of the following aspects:
What does the metric represent?
Why is this relevant for describing ecosystem condition in this ecosystem?
What kind of data is used?
Shortly, how is the data customized (modified, estimated, integarted) to fit its purpuse as an indicator?
What is the current status of the metric (can it be used or is it still in development)?
How should the metric be used and interpretted, and how should it not be used/interpretted?
-->

## 2. About the underlying data

<!--# Describe the data you have used, it's origin, biases, avaiabilit ect.-->
<!--# Describe the data you have used in more detail, it's origin, biases, availabilit ect.-->

### 2.1 Spatial and temporal resolution

Expand All @@ -155,41 +171,58 @@ meta |>

## 3. Indicator properties

### 3.1. ECT
### 3.1 Ecosystem Condition Typology Class (ECT)

<!--#
Describe the rationale for assigning the indicator to the ECT class. See https://oneecosystem.pensoft.net/article/58218/
This doesnt need to be very long. Maybe just a single sentence.
<!--# Describe the rationale for assigning the indicator to the ECT class -->
-->

### 3.2. Ecosystem condition characteristic
### 3.2 Ecosystem condition characteristic

<!--# Describe the ecosystem condition characteristic represneted in the indicator. See 10.3897/oneeco.6.e58218 for information on what these characteristics might be. -->
<!--#
### 3.3. Other standards
Describe the ecosystem condition characteristic represented in the indicator. See 10.3897/oneeco.6.e58218 for information on what these characteristics might be.
For example, and indicator called 'Trenching in mires' could be made to represent an ecosystem characteristic 'Intact hydrology'. The term 'characteristic' is used similar to the term 'criteria' in Multiple Criteria Decition Making.
<!--# Add text about other spesific standards, e.g. natinoal standards, and how the indicator relates to these -->
-->

### 3.4. Collinearities with other indicators
### 3.3 Other standards

<!--# Optional: Add text about other spesific standards, e.g. national standards, and how the indicator relates to these -->

### 3.4 Collinearities with other indicators

<!--# Describe known collinearities with other metrices (indicators or variables) that could become problematic if they were also included in the same Ecosystem Condition Assessment as the indicator described here. -->

## 4. Reference condition and values
## 4. Reference condition and levels

### 4.1 Reference condition

### 4. 1. Reference condition
<!--# Define the reference condition (or refer to where it is defined). Note the destinction between reference condition and reference levels 10.3897/oneeco.5.e58216 -->

<!--# Define the reference condition (or refer to where it is defined). Note the destinction between reference condition and reference values 10.3897/oneeco.5.e58216 -->
### 4.2 Reference levels

### 4. 2. Reference values
<!--#
#### 4.2.1 Minimum and maximum values
If relevant (i.e. if you have normalised a variable), describe the reference levels used to normalise the variable.
<!--# Describe the reference values used to set the lower and upper limits on the normative indicator scale. Why was the current option chosen and how were the reference values quantified? If the reference values are calculated as part of the analyses further down, please repeat the main information here. -->
Use the terminology where X~0~ referes to the referece level (the variable value) denoting the worst possible condition; X~100~denotes the optimum or best possible condition; and X~*n*~, where in is between 0 and 100, denotes any other anchoring points linking the variable scale to the indicator scale (e.g. the threshold value between good and bad condition X~60^).
#### 4.2.2. Threshold value for defining *good ecological condition (if relevant)*
Why was the current option chosen and how were the reference levels quantified? If the reference values are calculated as part of the analyses further down, please repeat the main information here.
<!--# Describe the different reference values here and the justification for using these -->
-->

#### 4.2.3. Spatial resolution and validity

<!--# Describe the spatial resolution of the reference values. E.g. is it defined as a fixed value for all areas, or does it vary. Also, at what spatial scale is the reference values valid? For example, if the reference value has a regional resolution (varies between regions), it might mean that it is only valid and correct to use for scaling local variable values that are first aggregated to regional scale. However, sometimes the reference value is insensitive to this and can be used to scale variables at the local (e.g. plot) scale. -->
#### 4.2.1 Spatial resolution and validity

<!--#
Describe the spatial resolution of the reference levels. E.g. is it defined as a fixed value for all areas, or does it vary. Also, at what spatial scale are the reference levels valid? For example, if the reference levels have a regional resolution (varies between regions), it might mean that it is only valid and correct to use for normalising local variable values that are first aggregated to regional scale. However, sometimes the reference levels are insensitive to this and can be used to scale variables at the local (e.g. plot) scale.
-->

## 5. Uncertainties

Expand All @@ -213,19 +246,41 @@ meta |>

## 8. Spatial units

<!--# Describe the spatial units that you rely on in your analyses. Highlight the spatial units (the resolution) that the indicator values should be interpretted at. Potential spatial delineation data should eb introduced under 7.1. Datasets. We recomend using the SEEA EA terminology opf Basic Spatial Units (BSU), Ecosystem Asses (EA) and Ecosystem Accounting Area (EAA). -->
<!--#
Describe the spatial units that you rely on in your analyses. Highlight the spatial units (the resolution) that the indicator values should be interpretted at. Potential spatial delineation data should eb introduced under 7.1. Datasets. We recomend using the SEEA EA terminology opf Basic Spatial Units (BSU), Ecosystem Asses (EA) and Ecosystem Accounting Area (EAA).
-->

## 9. Analyses

<!--# Use this header for documenting the analyses. Put code in seperate code chunks, and annotate the code in between using normal text (i.e. between the chunks, and try to avoid too many hashed out comments inside the code chunks). Add subheaders as needed. -->
<!--#
Use this header for documenting the analyses. Put code in seperate code chunks, and annotate the code in between using normal text (i.e. between the chunks, and try to avoid too many hashed out comments inside the code chunks). Add subheaders as needed.
Code folding is activated, meaning the code will be hidden by default in the html (one can click to expand it).
Caching is also activated (from the top YAML), meaning that rendering to html will be quicker the second time you do it. This will create a folder inside you project folder (called INDICATORID_cache). Sometimes caching created problems because some operations are not rerun when they should be rerun. Try deleting the cash folder and try again.
-->

## 10. Results

<!--# Repeat the final results here. Typically this is a map or table of indicator values.-->
<!--#
Repeat the final results here. Typically this is a map or table of indicator values.
This is typically where people will harvest data from, so make sure to include all relevant output here, but don't clutter this section with too much output either.
-->

## 11. Export file

<!--# Display the code (don't execute it) or the workflow for exporting the indicator values to file. Ideally the indicator values are exported as a georeferenced shape or raster file with indicators values, reference values and errors. You can also chose to export the raw (un-normalised or unscaled variable) as a seperate product. You should not save large sptaial output data on GitHub. You can use eval=FALSE to avoid code from being executed (example below - delete if not relevant) -->
<!--#
Optional: Display the code (don't execute it) or the workflow for exporting the indicator values to file. Ideally the indicator values are exported as a georeferenced shape or raster file with indicators values, reference values and errors. You can also chose to export the raw (un-normalised or unscaled variable) as a seperate product. You should not save large sptaial output data on GitHub. You can use eval=FALSE to avoid code from being executed (example below - delete if not relevant)
-->

```{r export}
#| eval: false
Expand Down
Binary file modified indicators/template/metadata.xlsx
View file
Binary file not shown.

0 comments on commit 98826b5

Please sign in to comment.