+*/
+
+.hide-child .child {
+ opacity: 0;
+ transition: opacity .15s ease-in;
+}
+
+.hide-child:hover .child,
+.hide-child:focus .child,
+.hide-child:active .child {
+ opacity: 1;
+ transition: opacity .15s ease-in;
+}
+
+.underline-hover:hover,
+.underline-hover:focus {
+ text-decoration: underline;
+}
+
+/* Can combine this with overflow-hidden to make background images grow on hover
+ * even if you are using background-size: cover */
+
+.grow {
+ -moz-osx-font-smoothing: grayscale;
+ -webkit-backface-visibility: hidden;
+ backface-visibility: hidden;
+ -webkit-transform: translateZ(0);
+ transform: translateZ(0);
+ transition: -webkit-transform 0.25s ease-out;
+ transition: transform 0.25s ease-out;
+ transition: transform 0.25s ease-out, -webkit-transform 0.25s ease-out;
+}
+
+.grow:hover,
+.grow:focus {
+ -webkit-transform: scale(1.05);
+ transform: scale(1.05);
+}
+
+.grow:active {
+ -webkit-transform: scale(.90);
+ transform: scale(.90);
+}
+
+.grow-large {
+ -moz-osx-font-smoothing: grayscale;
+ -webkit-backface-visibility: hidden;
+ backface-visibility: hidden;
+ -webkit-transform: translateZ(0);
+ transform: translateZ(0);
+ transition: -webkit-transform .25s ease-in-out;
+ transition: transform .25s ease-in-out;
+ transition: transform .25s ease-in-out, -webkit-transform .25s ease-in-out;
+}
+
+.grow-large:hover,
+.grow-large:focus {
+ -webkit-transform: scale(1.2);
+ transform: scale(1.2);
+}
+
+.grow-large:active {
+ -webkit-transform: scale(.95);
+ transform: scale(.95);
+}
+
+/* Add pointer on hover */
+
+.pointer:hover {
+ cursor: pointer;
+}
+
+/*
+ Add shadow on hover.
+
+ Performant box-shadow animation pattern from
+ http://tobiasahlin.com/blog/how-to-animate-box-shadow/
+*/
+
+.shadow-hover {
+ cursor: pointer;
+ position: relative;
+ transition: all 0.5s cubic-bezier(0.165, 0.84, 0.44, 1);
+}
+
+.shadow-hover::after {
+ content: '';
+ box-shadow: 0px 0px 16px 2px rgba(0, 0, 0, .2);
+ border-radius: inherit;
+ opacity: 0;
+ position: absolute;
+ top: 0;
+ left: 0;
+ width: 100%;
+ height: 100%;
+ z-index: -1;
+ transition: opacity 0.5s cubic-bezier(0.165, 0.84, 0.44, 1);
+}
+
+.shadow-hover:hover::after,
+.shadow-hover:focus::after {
+ opacity: 1;
+}
+
+/* Combine with classes in skins and skins-pseudo for
+ * many different transition possibilities. */
+
+.bg-animate,
+.bg-animate:hover,
+.bg-animate:focus {
+ transition: background-color .15s ease-in-out;
+}
+
+/*
+
+ Z-INDEX
+
+ Base
+ z = z-index
+
+ Modifiers
+ -0 = literal value 0
+ -1 = literal value 1
+ -2 = literal value 2
+ -3 = literal value 3
+ -4 = literal value 4
+ -5 = literal value 5
+ -999 = literal value 999
+ -9999 = literal value 9999
+
+ -max = largest accepted z-index value as integer
+
+ -inherit = string value inherit
+ -initial = string value initial
+ -unset = string value unset
+
+ MDN: https://developer.mozilla.org/en/docs/Web/CSS/z-index
+ Spec: http://www.w3.org/TR/CSS2/zindex.html
+ Articles:
+ https://philipwalton.com/articles/what-no-one-told-you-about-z-index/
+
+ Tips on extending:
+ There might be a time worth using negative z-index values.
+ Or if you are using tachyons with another project, you might need to
+ adjust these values to suit your needs.
+
+*/
+
+.z-0 { z-index: 0; }
+
+.z-1 { z-index: 1; }
+
+.z-2 { z-index: 2; }
+
+.z-3 { z-index: 3; }
+
+.z-4 { z-index: 4; }
+
+.z-5 { z-index: 5; }
+
+.z-999 { z-index: 999; }
+
+.z-9999 { z-index: 9999; }
+
+.z-max {
+ z-index: 2147483647;
+}
+
+.z-inherit { z-index: inherit; }
+
+.z-initial { z-index: auto; z-index: initial; }
+
+.z-unset { z-index: unset; }
+
+/*
+
+ NESTED
+ Tachyons module for styling nested elements
+ that are generated by a cms.
+
+*/
+
+.nested-copy-line-height p,
+.nested-copy-line-height ul,
+.nested-copy-line-height ol {
+ line-height: 1.5;
+}
+
+.nested-headline-line-height h1,
+.nested-headline-line-height h2,
+.nested-headline-line-height h3,
+.nested-headline-line-height h4,
+.nested-headline-line-height h5,
+.nested-headline-line-height h6 {
+ line-height: 1.25;
+}
+
+.nested-list-reset ul,
+.nested-list-reset ol {
+ padding-left: 0;
+ margin-left: 0;
+ list-style-type: none;
+}
+
+.nested-copy-indent p+p {
+ text-indent: 1em;
+ margin-top: 0;
+ margin-bottom: 0;
+}
+
+.nested-copy-separator p+p {
+ margin-top: 1.5em;
+}
+
+.nested-img img {
+ width: 100%;
+ max-width: 100%;
+ display: block;
+}
+
+.nested-links a {
+ color: #357edd;
+ transition: color .15s ease-in;
+}
+
+.nested-links a:hover,
+.nested-links a:focus {
+ color: #96ccff;
+ transition: color .15s ease-in;
+}
+
+/*
+
+ STYLES
+
+ Add custom styles here.
+
+*/
+
+/* Variables */
+
+/* Importing here will allow you to override any variables in the modules */
+
+/*
+
+ Tachyons
+ COLOR VARIABLES
+
+ Grayscale
+ - Solids
+ - Transparencies
+ Colors
+
+*/
+
+/*
+
+ CUSTOM MEDIA QUERIES
+
+ Media query values can be changed to fit your own content.
+ There are no magic bullets when it comes to media query width values.
+ They should be declared in em units - and they should be set to meet
+ the needs of your content. You can also add additional media queries,
+ or remove some of the existing ones.
+
+ These media queries can be referenced like so:
+
+ @media (--breakpoint-not-small) {
+ .medium-and-larger-specific-style {
+ background-color: red;
+ }
+ }
+
+ @media (--breakpoint-medium) {
+ .medium-screen-specific-style {
+ background-color: red;
+ }
+ }
+
+ @media (--breakpoint-large) {
+ .large-and-larger-screen-specific-style {
+ background-color: red;
+ }
+ }
+
+*/
+
+/* Media Queries */
+
+/* Debugging */
+
+/* @import 'tachyons/src/_debug-children';
+@import 'tachyons/src/_debug-grid'; */
+
+/* Uncomment out the line below to help debug layout issues */
+
+/* @import 'tachyons/src/_debug'; */
+
+pre, .pre {
+ overflow-x: auto;
+ overflow-y: hidden;
+ overflow: scroll;
+}
+
+pre code {
+ display: block;
+ padding: 1.5em 1.5em;
+ white-space: pre;
+ font-size: .875rem;
+ line-height: 2;
+
+}
+
+pre {
+ background-color: #222;
+ color: #ddd;
+ white-space: pre;
+
+ -webkit-hyphens: none;
+
+ -ms-hyphens: none;
+
+ hyphens: none;
+ position: relative;
+}
+
+/* pagination.html: https://github.com/spf13/hugo/blob/master/tpl/tplimpl/template_embedded.go#L117 */
+
+.pagination {
+ margin: 3rem 0;
+}
+
+.pagination li {
+ display: inline-block;
+ margin-right: .375rem;
+ font-size: .875rem;
+ margin-bottom: 2.5em;
+}
+
+.pagination li a {
+ padding: .5rem .625rem;
+ background-color: white;
+ color: #333;
+ border: 1px solid #ddd;
+ border-radius: 3px;
+ text-decoration: none;
+}
+
+.pagination li.disabled {
+ display: none;
+}
+
+.pagination li.active a:link,
+.pagination li.active a:active,
+.pagination li.active a:visited {
+ background-color: #ddd;
+}
+
+#TableOfContents ul li {
+ margin-bottom: 1em;
+}
+
+.facebook, .twitter, .instagram, .youtube, .github, .gitlab, .keybase, .linkedin, .medium, .mastodon, .slack, .stackoverflow, .rss {
+ fill: #BABABA;
+}
+
+.new-window {
+ opacity: 0;
+ display: inline-block;
+ vertical-align: top;
+}
+
+.link-transition:hover .new-window{
+ opacity: 1;
+}
+
+.facebook:hover {
+ fill: #3b5998;
+}
+
+.twitter:hover {
+ fill: #1da1f2;
+}
+
+.instagram:hover {
+ fill: #e1306c;
+}
+
+.youtube:hover {
+ fill: #cd201f;
+}
+
+.github:hover {
+ fill: #6cc644;
+}
+
+.gitlab:hover {
+ fill: #FC6D26;
+}
+
+.keybase:hover {
+ fill: #3d76ff;
+}
+
+.linkedin:hover {
+ fill: #0077b5
+}
+
+.medium:hover {
+ fill: #0077b5
+}
+
+.mastodon:hover {
+ fill: #3088d4;
+}
+
+.slack:hover {
+ fill: #E01E5A;
+}
+
+.stackoverflow:hover {
+ fill: #f48024;
+}
+
+.rss:hover{
+ fill: #ff6f1a;
+}
+
+/* Put your custom styles here and run `npm start` from the "src" directory on */
+
+#TableOfContents ul li {
+ margin-bottom: 1em;
+}
+
+.lh-copy blockquote {
+ display: block;
+ font-size: .875em;
+ margin-left: 2rem;
+ margin-top: 2rem;
+ margin-bottom: 2rem;
+ border-left: 4px solid #ccc;
+ padding-left: 1rem;
+
+}
diff --git a/public/dist/js/app.3fc0f988d21662902933.js b/public/dist/js/app.3fc0f988d21662902933.js
new file mode 100644
index 00000000..ad6c35c3
--- /dev/null
+++ b/public/dist/js/app.3fc0f988d21662902933.js
@@ -0,0 +1 @@
+!function(n){function t(e){if(r[e])return r[e].exports;var o=r[e]={i:e,l:!1,exports:{}};return n[e].call(o.exports,o,o.exports,t),o.l=!0,o.exports}var r={};t.m=n,t.c=r,t.i=function(n){return n},t.d=function(n,r,e){t.o(n,r)||Object.defineProperty(n,r,{configurable:!1,enumerable:!0,get:e})},t.n=function(n){var r=n&&n.__esModule?function(){return n.default}:function(){return n};return t.d(r,"a",r),r},t.o=function(n,t){return Object.prototype.hasOwnProperty.call(n,t)},t.p="",t(t.s=1)}([function(n,t){},function(n,t,r){"use strict";var e=r(0);!function(n){n&&n.__esModule}(e)}]);
\ No newline at end of file
diff --git a/public/events/2017_07_arctic/index.html b/public/events/2017_07_arctic/index.html
new file mode 100644
index 00000000..7dea1971
--- /dev/null
+++ b/public/events/2017_07_arctic/index.html
@@ -0,0 +1,335 @@
+
+
+
+
+
+
+ Tools for Data Science in Arctic Research (July 2017) | NCEAS Training Materials Catalog
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Arctic Data Center
+
+
+
+
+
+
+
+
+ EVENTS
+
+
+ Tools for Data Science in Arctic Research (July 2017)
+
+
+
+
+
+
Dates: July 31 - Aug 1, 2017
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse. This 2-day workshop will provide researchers with an overview of best data management practices, data science tools and concrete steps and methods for more easily documenting and uploading their data to the Arctic Data Center.
+
+
Course overview
+
+
The Arctic Data Center conducts training in data science and management,
+both of which are critical skills for stewardship of data, software, and other
+products of research that are preserved at the Arctic Data Center.
+
+
Course topics will include:
+
+
+
Arctic Data Center and NSF Standards and Policies
+
Data Management Plans
+
Effective data management for data preservation
+
+
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
+ Open Science for Synthesis: Gulf Research Program Workshop
+
+
+
+
+
+
Dates: July 10 - July 28, 2017
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+
+
The primary goal of the Open Science for Synthesis: Gulf Research Program Workshop is to provide hands-on experience with contemporary open science tools from command line to data to communication. Team science is promoted. Practice and real data are used in groups to apply skills we explore.
+
+
Week 1. Fundamental collaboration skills
+Introduction to command line, communicating science, R, meta-analysis and data management.
+ Dataset Publishing with the Arctic Data Center (June 2018)
+
+
+
+
+
+
Dates: June 22, 2018 12:30 to 14:00
+Location: Davos, Switzerland
+Venue: POLAR 2018 Open Science Conference
+
+
This hands-on session will cover (1) Open data archives, especially the Arctic Data Center; (2) What science metadata is and how it can be used; (3) How data and code can be documented and published in open data archives; (4) Web-based submission, and (5) Submission using R (pending sufficient time).
+
+
Course overview
+
+
The Arctic Data Center conducts training in data science and management,
+both of which are critical skills for stewardship of data, software, and other
+products of research that are preserved at the Arctic Data Center.
+
+
In this hands-on session, we will cover:
+
+
+
About open data archives, especially the Arctic Data Center
+
What science metadata is and how it can be used
+
How data and code can be documented and published in open data archives
+
+
+
Web-based submission
+
Submission using R (extra credit, likely insufficient time)
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
Dates: August 13 - August 17, 2018
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse. This 5-day workshop will provide researchers with an overview of best data management practices, data science tools and concrete steps and methods for more easily documenting and uploading their data to the Arctic Data Center.
+
+
Overview:
+
+
Workshop topics will include:
+
+
+
Arctic Data Center and NSF Standards and Policies
+
Data Management Plans
+
Effective Data Management for Data Preservation
+
Publishing Data at the Arctic Data Center
+
Data and Metadata Quality
+
Provenance for Data and Software
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
+
+
Preparing for the Workshop
+
+
Required software
+
+
We will primarily be using a web browser, R, RStudio, and git. Please be sure these are all installed on your laptop, as follows:
+
+
+
R: We will use R version 3.4.2, which you can download and install from CRAN
+
+
RStudio: To download RStudio, visit RStudio’s download page.
+If you don’t know how up to date your version of RStudio is, please download an updated copy and install it
+
+
R packages: Please be sure you have installed or updated the following packages:
+
+
+
dataone
+
datapack
+
devtools
+
dplyr
+
EML
+
ggplot2
+
tidyr
+
+
+
You can install these packages quickly by running the following two code snippets:
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
Dates: January 14 - January 18, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse. This 5-day workshop will provide researchers with an overview of best data management practices, data science tools and concrete steps and methods for more easily documenting and uploading their data to the Arctic Data Center.
+
+
Overview:
+
+
Workshop topics will include:
+
+
+
Arctic Data Center and NSF Standards and Policies
+
Data Management Plans
+
Effective Data Management for Data Preservation
+
Publishing Data at the Arctic Data Center
+
Data and Metadata Quality
+
Provenance for Data and Software
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
+
+
Preparing for the Workshop
+
+
Required software
+
+
We will primarily be using a web browser, R, RStudio, and git. Please be sure these are all installed on your laptop, as follows:
+
+
+
R: We will use R version 3.5.2, which you can download and install from CRAN
+
+
RStudio: To download RStudio, visit RStudio’s download page.
+If you don’t know how up to date your version of RStudio is, please download an updated copy and install it
+
+
R packages: Please be sure you have installed or updated the following packages:
+
+
+
devtools
+
dplyr
+
DT
+
ggplot2
+
leaflet
+
tidyr
+
+
+
You can install these packages quickly by running the following two code snippets:
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
+ Openscapes Champions Cohort sponsored by Mozilla
+
+
+
+
+
+
Dates: January 10 - May 24, 2019
+Location: Remote
+
+
In the Long-term Remote Program, Cohorts of research groups participate over a four-month period, with two Cohort Calls each month. Calls are designed to be engaging, requiring discussion and active participation through live-notetaking in Google Docs and video Zoom (group and breakouts).
+
+
Openscapes is operated by the National Center for Ecological Analysis & Synthesis (NCEAS) and is being incubated by a Mozilla Fellowship awarded to Julia Stewart Lowndes.
Dates: February 11 - February 15, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse. This 5-day workshop will provide researchers with an overview of best data management practices, data science tools and concrete steps and methods for more easily documenting and uploading their data to the Arctic Data Center.
+
+
Overview:
+
+
Workshop topics will include:
+
+
+
Arctic Data Center and NSF Standards and Policies
+
Data Management Plans
+
Effective Data Management for Data Preservation
+
Publishing Data at the Arctic Data Center
+
Data and Metadata Quality
+
Provenance for Data and Software
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
+
+
Preparing for the Workshop
+
+
Required software
+
+
We will primarily be using a web browser, R, RStudio, and git. Please be sure these are all installed on your laptop, as follows:
+
+
+
R: We will use R version 3.5.2, which you can download and install from CRAN
+
+
RStudio: To download RStudio, visit RStudio’s download page.
+If you don’t know how up to date your version of RStudio is, please download an updated copy and install it
+
+
R packages: Please be sure you have installed or updated the following packages:
+
+
+
devtools
+
dplyr
+
DT
+
ggplot2
+
leaflet
+
tidyr
+
+
+
You can install these packages quickly by running the following two code snippets:
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
Dates: October 7 - October 11, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse. This 5-day workshop will provide researchers with an overview of best data management practices, data science tools and concrete steps and methods for more easily documenting and uploading their data to the Arctic Data Center.
+
+
Acceptance to the training includes domestic travel, accommodation, and meals.
+
+
Overview:
+
+
Workshop topics will include:
+
+
+
Arctic Data Center and NSF Standards and Policies
+
Data Management Plans
+
Effective Data Management for Data Preservation
+
Publishing Data at the Arctic Data Center
+
Data and Metadata Quality
+
Provenance for Data and Software
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
+
+
Preparing for the Workshop
+
+
Required software
+
+
We will primarily be using a web browser, R, RStudio, and git. Please be sure these are all installed on your laptop, as follows:
+
+
+
R: We will use R version 3.6.1, which you can download and install from CRAN
+
+
RStudio: To download RStudio, visit RStudio’s download page.
+If you don’t know how up to date your version of RStudio is, please download an updated copy and install it
+
+
R packages: Please be sure you have installed or updated the following packages:
+
+
+
devtools
+
dplyr
+
DT
+
ggplot2
+
leaflet
+
tidyr
+
EML
+
dataone
+
datapack
+
sf
+
+
+
You can install these packages quickly by running the following two code snippets:
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
+ Reproducible Research Techniques for Synthesis (November 2019)
+
+
+
+
+
+
Dates: November 4 - November 8, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
Curriculum at a glance:
+
+
Enable data reuse through better data management
+
+
+
Metadata - what is it and how to write a quality data description
+
Data modeling - tidy data for efficient access and storage
+
Data publishing, citation, and credit
+
+
+
Build reproducible scientific workflows
+
+
+
Data munging with R tidyverse
+
Working collaboratively - git and GitHub
+
Writing functions in R
+
Building packages for publishing reproducible research
+
+
+
Communicate results effectively
+
+
+
Literate analysis with RMarkdown
+
Publishing analytical web pages with GitHub pages
+
Data visualization with ggplot and leaflet
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
We will primarily be using a web browser, R, RStudio, and git. Please be sure these are all installed on your laptop, as follows:
+
+
+
R: We will use R version 3.6.1, which you can download and install from CRAN
+
+
RStudio: To download RStudio, visit RStudio’s download page.
+If you don’t know how up to date your version of RStudio is, please download an updated copy and install it
+
+
R packages: Please be sure you have installed or updated the following packages:
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
+ Reproducible Research Techniques for Synthesis (February 2020)
+
+
+
+
+
+
Dates: February 3 - February 7, 2020
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
Curriculum at a glance:
+
+
Enable data reuse through better data management
+
+
+
Metadata - what is it and how to write a quality data description
+
Data modeling - tidy data for efficient access and storage
+
Data publishing, citation, and credit
+
+
+
Build reproducible scientific workflows
+
+
+
Data munging with R tidyverse
+
Working collaboratively - git and GitHub
+
Writing functions in R
+
Building packages for publishing reproducible research
+
+
+
Communicate results effectively
+
+
+
Literate analysis with RMarkdown
+
Publishing analytical web pages with GitHub pages
+
Data visualization with ggplot and leaflet
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
We will primarily be using a web browser, R, RStudio, and git. Please be sure these are all installed on your laptop, as follows:
+
+
+
R: We will use R version 3.6.2, which you can download and install from CRAN
+
+
RStudio: To download RStudio, visit RStudio’s download page.
+If you don’t know how up to date your version of RStudio is, please download an updated copy and install it
+
+
R packages: Please be sure you have installed or updated the following packages:
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
Dates: February 26 - February 27, 2020
+Location: Woods Hole, Massachusetts. NOAA Northeast Fisheries Science Center.
+
+
Through in-person Workshops, cohorts of research groups participate over a 2 full days. Workshops are designed to be engaging, requiring active participation through discussion, live-notetaking in Google Docs, and breakout group activities.
+
+
Openscapes is operated by the National Center for Ecological Analysis & Synthesis (NCEAS) and is being incubated by a Mozilla Fellowship awarded to Julia Stewart Lowndes.
+ Data Science and Collaboration Skills for Integrative Conservation Science
+
+
+
+
+
+
Dates: February 18 - February 21, 2020
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+
+
This intensive 4-day workshop on Data Science and Collaboration Skills for Integrative Conservation Science will be held at NCEAS, Santa Barbara, CA from Feb 18 to Feb 21, 2020.
+
+
This training, sponsored by SNAPP, aims to bring together the SNAPP and NCEAS postdoctoral associates to foster communities and collaboration, as well as promote scientific computing and open science best practices.
Integrate collaborative science best practices within SNAPP Working Groups
+
Empower participants to adopt computing best practices in their scientific workflows and data management
+
Create a greater sense of SNAPP community
+
Foster potential collaboration and enhanced knowledge-sharing across SNAPP Working Groups
+
Familiarize and instruct SNAPP researchers in the use of NCEAS (and other) analytical servers and services
+
Discuss mechanisms that have helped SNAPP groups to advance SNAPP’s commitment to open science
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
+
+
Organizers
+
+
+
+
+
Name
+
Email
+
+
+
+
+
+
Julien Brun
+
brun@nceas.ucsb.edu
+
+
+
+
Carrie Kappel
+
kappel@nceas.ucsb.edu
+
+
+
+
Jeanette Clark
+
jclark@nceas.ucsb.edu
+
+
+
+
+
Preparing for the Workshop
+
+
Required software
+
+
We will primarily be using a web browser, R, RStudio, and git. Please be sure these are all installed on your laptop, as follows:
+
+
+
R: We will use R version 3.6.2, which you can download and install from CRAN
+
+
RStudio: To download RStudio, visit RStudio’s download page.
+If you don’t know how up to date your version of RStudio is, please download an updated copy and install it
+
+
R packages: Please be sure you have installed or updated the following packages:
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
+ Efficient virtual collaboration & facilitation for synthesis science
+
+
+
+
Dates: April 24, 2020
+Location: Remote
+
+
This 3-hour module provides mentorship and facilitation training for Working Groups to develop skill sets, habits, and mindsets to make remote work and collaborative synthesis science more efficient and resilient.
+ Tools and practices for collaborative, reproducible data science
+
+
+
+
+
+
Dates: May 8, 2020
+Location: Remote
+
+
This module is an introduction to the data science support NCEAS is providing to LTER and SNAPP working groups followed by a discussion on best practices about data management in a distributed team setup. Participants will have the opportunity to brainstorm on their data and computing needs. In the second part of the workshop, an introduction to the use of NCEAS analytical server and the concept of collaborative coding as a distributed team will be demonstrated to empower participants to develop their analytical workflows in a remote setup.
+
+
Data science support (1.5 hours)
+
+
Goal: Introduction to data science support and discuss data and analytical needs
+
+
Format: presentation and discussion;
+
+
Audience: Whole Working group
+
+
+
Data Science support available to working groups (15min + 15min)
+
+
+
Presentation of support and goals
+
Data preservation requirements
+
+
Data management tips (30 min)
+
+
+
How to track your data sources
+
How to best organize your data
+
+
Discussion about data and computational needs (30min; as breakout group per WG)
+
+
+
Reproducible analytical workflows for distributed teams (1.5 hours)
+
+
Goal: Empower working groups to collaboratively develop analytical workflows
+
+
Format: Demo + questions
+
+
Audience: Analysts + interested participants
+
+
+
Collaborative and reproducible workflows:
+
+
+
Workflows to collaborate on a remote server
+
How to code collaboratively using git and GitHub
+
+
+
GitHub Web interface
+
RStudio projects and GitHub
+
+
+
Instructions on how to get an account on NCEAS analytical server
Dates: October 19 - October 23, 2020
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse. This 5-day workshop will provide researchers with an overview of best data management practices, data science tools and concrete steps and methods for more easily documenting and uploading their data to the Arctic Data Center.
+
+
Overview:
+
+
Workshop topics will include:
+
+
+
Arctic Data Center and NSF Standards and Policies
+
Data Management Plans
+
Effective Data Management for Data Preservation using R
+
Publishing Data at the Arctic Data Center
+
Data and Metadata Quality
+
Provenance for Data and Software
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
+
+
Preparing for the Workshop
+
+
Required software
+
+
We will primarily be using a web browser along with an instance of RStudio server set
+up especially for this course. However, we also recommend setting up R, RStudio,
+and git on your local system to more easily prepare you to utilize the skills you learned
+once the course ends.
+
+
+
R: We will use R version 4.0.2, which you can download and install from CRAN
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
+ Reproducible Research Techniques for Synthesis (November 2020)
+
+
+
+
+
+
Dates: November 12 - November 18, 2020
+Location: Remote
+
+
This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
Curriculum at a glance:
+
+
Enable data reuse through better data management
+
+
+
Metadata - what is it and how to write a quality data description
+
Data modeling - tidy data for efficient access and storage
+
Data publishing, citation, and credit
+
+
+
Build reproducible scientific workflows
+
+
+
Data munging with R tidyverse
+
Working collaboratively - git and GitHub
+
Writing functions in R
+
Building packages for publishing reproducible research
+
+
+
Communicate results effectively
+
+
+
Literate analysis with RMarkdown
+
Publishing analytical web pages with GitHub pages
+
Data visualization with ggplot and leaflet
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
We will primarily be using a web browser along with an instance of RStudio server set
+up especially for this course. However, we also recommend setting up R, RStudio,
+and git on your local system to more easily prepare you to utilize the skills you learned
+once the course ends.
+
+
+
R: We will use R version 4.0.2, which you can download and install from CRAN
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
A self guided learning curricula to support new NEON postdocs as part of their onboarding experience. The curricula builds from the experience of ecological researchers, trainers, developers and information managers to provide resources and training in support of collaborative, reproducible research practices.
+ Reproducible Research Techniques for Synthesis (February 2021)
+
+
+
+
+
+
Dates: February 25-26, March 1-3, 2021
+Location: Remote
+
+
This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
Curriculum at a glance:
+
+
Enable data reuse through better data management
+
+
+
Metadata - what is it and how to write a quality data description
+
Data modeling - tidy data for efficient access and storage
+
Data publishing, citation, and credit
+
+
+
Build reproducible scientific workflows
+
+
+
Data munging with R tidyverse
+
Working collaboratively - git and GitHub
+
Writing functions in R
+
Building packages for publishing reproducible research
+
+
+
Communicate results effectively
+
+
+
Literate analysis with RMarkdown
+
Publishing analytical web pages with GitHub pages
+
Data visualization with ggplot and leaflet
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
We will primarily be using a web browser along with an instance of RStudio server set
+up especially for this course. However, we also recommend setting up R, RStudio,
+and git on your local system to more easily prepare you to utilize the skills you learned
+once the course ends.
+
+
+
R: We will use R version 4.0.2, which you can download and install from CRAN
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
+ Reproducible Research Techniques for Synthesis (July 2021)
+
+
+
+
+
+
Dates: July 8-9, 12-14, 2021
+Location: Remote
+
+
This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
Curriculum at a glance:
+
+
Enable data reuse through better data management
+
+
+
Metadata - what is it and how to write a quality data description
+
Data modeling - tidy data for efficient access and storage
+
Data publishing, citation, and credit
+
+
+
Build reproducible scientific workflows
+
+
+
Data munging with R tidyverse
+
Working collaboratively - git and GitHub
+
Writing functions in R
+
Building packages for publishing reproducible research
+
+
+
Communicate results effectively
+
+
+
Literate analysis with RMarkdown
+
Publishing analytical web pages with GitHub pages
+
Data visualization with ggplot and leaflet
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
We will primarily be using a web browser along with an instance of RStudio server set
+up especially for this course. However, we also recommend setting up R, RStudio,
+and git on your local system to more easily prepare you to utilize the skills you learned
+once the course ends.
+
+
+
R: We will use R version 4.0.2, which you can download and install from CRAN
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
+ Managing Ecological Data for Effective Use and Re-Use
+
+
+
+
+
+
Friday, August 6th, 2021
+10:30 AM - 1:30 PM
+
+
Session Description
+
+
While graduate students in ecology learn about methods for collecting and analyzing ecological data, there is less emphasis on managing and using the resulting data effectively. This is an increasingly important skill set as the research landscape changes. Researchers are increasingly engaging in collaboration across networks, many funding agencies require data management plans, journals are requiring that data and code be accessible, and society is increasingly expecting that research be reproducible. Ecologists can maximize the productivity of their research program with good data skills, in that they can effectively and efficiently share their data and other research products with the scientific community, and potentially benefit from the re-use of their data by others.
+
+
The purpose of this short course is to give attendees an introduction to a set of practical tools for organizing and sharing their data through all parts of the research cycle. The target audience is early-career scientists but is open to any researcher who would benefit from developing better data management skills. Topics will include data organization, data documentation, and the importance of good data management practices for data sharing, collaboration, and data re-use. The short course will be an interactive combination of presentation, discussion and activities. Participants must bring their own laptop to work on exercises.
+
+
Session Summary
+
+
Learn to organize and share your data through all parts of the research cycle. Topics include data organization, data documentation, and the importance of good data management practices for data sharing, collaboration, and data re-use.
+
+
Organizer:
+
+
Jeanette Clark – University of California, Santa Barbara, NCEAS, Arctic Data Center
+
+
Co-organizers:
+
+
Amber Budden – University of California, Santa Barbara, NCEAS
+Matthew B. Jones – University of California, Santa Barbara, NCEAS
+ Open Science Synthesis for the Delta Science Program
+
+
+
+
+
+
+
+
In collaboration with the Delta Science Program we are running a 12 month facilitated research synthesis activity, supported by 3 one-week intensive training events. Curriculum material will focus on introducing Delta Researchers to best practices in, and application of, scientific computing and
+scientific software for reproducible science. In addition to developing and delivering learning curriculum, this collaboration will include the provision of data consulting, synthesis facilitation, and a remote workshop to conclude the group synthesis activities.
+
+
The learning curricula will focus on techniques for data management, scientific programming, synthetic analysis, and collaboration techniques through the use of open-source, community-supported tools. Participants will learn skills for rapid and robust use of open source scientific software. These approaches will be explored and applied to scientific synthesis projects related to the Delta ecosystem.
+
+
The course will weave together several core themes which are reinforced – and injected into the real-time synthetic scientific research process – through work on group synthesis projects.
+
+
Schedule
+
+
Week 1: September 13-17, 2021. Remote.
+Week 2: October 25-29, 2021. UC Davis.
+Week 3: November 1-5, 2021. UC Davis.
Jeanette is a Projects Data Coordinator at NCEAS with extensive experience helping synthesis scientists find, synthesize, document, and publish datasets. She also helps maintain the Knowledge Network for Biocomplexity (KNB) data archive. She has expertise in R, GitHub, structured metadata, and data archival. Jeanette was introduced to data processing and data analysis through her academic background in physical oceanography, and enjoys applying this foundation to more interdisciplinary ecology research.
+
+
Amber Budden
+
+
Amber is the Director of Learning and Outreach at NCEAS and lead of community engagement and outreach at DataONE and the Arctic Data Center. She holds a PhD in Ecology in addition to research experience in bibliometrics. She has coordinated and taught numerous workshops focused on data management for Earth and environmental science. Her skills include data management, science communication and outreach, and training evaluation.
+
+
Matt Jones
+
+
Matt is the Director of Informatics Research and Development at NCEAS and has expertise in environmental informatics, particularly software for management, integration, analysis, and modeling of data. Jones has taught at over 20 training workshops over a decade on data science topics including analysis in R, GitHub, programming (e.g., Python), data management, quality assessment and reporting, metadata and data infrastructure, scientific workflow systems, and other topics.
+
+
Chris Lortie
+
+
Chris Lortie is Professor of Ecology at York University. He received his B.Sc. in Biology, Bachelor’s of Education, and Master’s degrees from Queen’s University and was awarded a PhD in Botany from the University of British Columbia. Chris’ areas of research include community ecology, seedbanks, invasive species, social ecology and theory development with a focus on synthesis and meta-analytical techniques.
+
+
David LeBauer
+
+
Dr. David LeBauer Director of Data Science for the Division of Agriculture, Life and Veterinary Sciences and Cooperative Extension, University of Arizona. David develops open data and software that enables synthesis of observations with systems-level understanding to improve understanding and prediction of agricultural yield potential as well as ecosystem carbon, nutrient, water, and energy budgets.
+
+
Jessica Guo
+
+
Jessica Guo is a scientific programmer and plant ecophysiologist in the Digital Agriculture Group at the University of Arizona. Her background is in hierarchical Bayesian modeling of plant and ecosystem processes. She completed her PhD in Biology at Northern Arizona University with Dr. Kiona Ogle.
+ Reproducible Research Techniques for Synthesis (November 2021)
+
+
+
+
+
+
Dates: November 15-19, 2021
+Location: Remote
+
+
This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
Curriculum at a glance:
+
+
Enable data reuse through better data management
+
+
+
Metadata - what is it and how to write a quality data description
+
Data modeling - tidy data for efficient access and storage
+
Data publishing, citation, and credit
+
+
+
Build reproducible scientific workflows
+
+
+
Data munging with R tidyverse
+
Working collaboratively - git and GitHub
+
Writing functions in R
+
Building packages for publishing reproducible research
+
+
+
Communicate results effectively
+
+
+
Literate analysis with RMarkdown
+
Publishing analytical web pages with GitHub pages
+
Data visualization with ggplot and leaflet
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
We will primarily be using a web browser along with an instance of RStudio server set
+up especially for this course. However, we also recommend setting up R, RStudio,
+and git on your local system to more easily prepare you to utilize the skills you learned
+once the course ends.
+
+
+
R: We will use R version 4.0.2, which you can download and install from CRAN
GitHub: We will be using GitHub so you will need create (or remember your existing) GitHub login
+
+
+
Refresh your skills
+
+
This workshop assumes a base level of experience using R for scientific and statistical analyses.
+However, we realize that not everyone will be at the same place in terms of familiarity with the tools we’ll be using.
+If you’d like to brush up on your R skills prior to the workshop, check out this list of resources we like:
If you’re a fan of cheat sheets, RStudio provides some fantastic ones on their Cheat Sheets page.
+Please make sure to print ahead of time if you prefer hard copies.
+In particular, check out:
+ Fundamentals in Data Management for Qualitative and Quantitative Arctic Research
+
+
+
+
+
+
Dates: April 18 - 22, 2022
+Location: NCEAS
+Venue: Santa Barbara, CA
+
+
This 5-day in-person workshop will provide researchers with an overview of reproducible and ethical research practices, steps and methods for more easily documenting and preserving their data at the Arctic Data Center, and an introduction to programming in R. Special attention will be paid to qualitative data management, including practices working with sensitive data. Example datasets will draw from natural and social sciences, and methods for conducting reproducible research will be discussed in the context of both qualitative and quantitative data. Responsible and reproducible data management practices will be discussed as they apply to all aspects of the data life cycle. This includes ethical data collection and data sharing, data sovereignty, and the CARE principles. The CARE principles are guidelines that help ensure open data practices (like the FAIR principles) appropriately engage with Indigenous Peoples’ rights and interests.
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
+ Scalable and Computationally Reproducible Approaches to Arctic Research
+
+
+
+
+
+
Dates: September 19 - 23, 2022
+Location: NCEAS
+Venue: Santa Barbara, CA
+
+
This 5-day in-person workshop will provide researchers with an introduction to advanced topics in computationally reproducible research in python, including software and techniques for working with very large datasets. This includes working in cloud computing environments, docker containers, and parallel processing using tools like parsl and dask. The workshop will also cover concrete methods for documenting and uploading data to the Arctic Data Center, advanced approaches to tracking data provenance, responsible research and data management practices including data sovereignty and the CARE principles, and ethical concerns with data-intensive modeling and analysis.
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
Dates: February 14 - February 19, 2022
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse. This 5-day workshop will provide researchers with an overview of best data management practices, data science tools and concrete steps and methods for more easily documenting and uploading their data to the Arctic Data Center.
+
+
Overview:
+
+
Workshop topics will include:
+
+
+
Arctic Data Center and NSF Standards and Policies
+
Data Management Plans
+
Ethical Research Practices
+
Effective Data Management for Data Preservation using R
+
Publishing Data at the Arctic Data Center
+
Data and Metadata Quality
+
Provenance for Data and Software
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
This workshop is a collaboration between the Arctic Data Center, ELOKA and the NNA Community Office, and will focus on the presentation of open science principles and best practices. Open science will be explored from the lens of reproducibility of research, Indigenous data sovereignty, and community data management. A combination of presentation and discussion will introduce participants to key topics, detail current recommended practices and highlight areas for future research. During the second part of the workshop, participants will have the opportunity to explore data organization and the principles of ‘tidy’ data structures through practical hands-on and small group activities.
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
+ Fundamentals in Data Management for Qualitative and Quantitative Arctic Research
+
+
+
+
+
+
Dates: January 30 - February 3, 2023
+Location: NCEAS
+Venue: Santa Barbara, CA
+
+
This 5-day in-person workshop will provide researchers with an overview of reproducible and ethical research practices, steps and methods for more easily documenting and preserving their data at the Arctic Data Center, and an introduction to programming in R. Special attention will be paid to qualitative data management, including practices working with sensitive data. Example datasets will draw from natural and social sciences, and methods for conducting reproducible research will be discussed in the context of both qualitative and quantitative data. Responsible and reproducible data management practices will be discussed as they apply to all aspects of the data life cycle. This includes ethical data collection and data sharing, data sovereignty, and the CARE principles. The CARE principles are guidelines that help ensure open data practices (like the FAIR principles) appropriately engage with Indigenous Peoples’ rights and interests.
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
+ Reproducible Practices for Arctic Research Using R
+
+
+
+
+
+
Dates: February 27 - March 3, 2023
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+
+
This 5-day remote workshop will provided researchers with an overview of best data management practices, data science tools for cleaning and analyzing data, and concrete steps and methods for more easily documenting and preserving their data at the Arctic Data Center. Example tools included R, Rmarkdown, and git/GitHub. This course provided background in both the theory and practice of reproducible research, spanning all portions of the research lifecycle, from ethical data collection following the CARE principles to engage with local stakeholders, to data publishing..
+
+
Overview:
+
+
Workshop topics will include:
+
+
+
Literate analysis (RMarkdown),
+
Data wrangling (tidyr/dplyr),
+
Data publishing,
+
Visualization (ggplot2/sf),
+
Code versioning (git),
+
Ethical data procedures (CARE principles)
+
+
+
For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
NSF award #1546024 to M. B. Jones, S. Baker-Yeboah, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
+ Scalable and Computationally Reproducible Approaches to Arctic Research
+
+
+
+
+
+
Dates: March 27-31, 2023
+Location: NCEAS
+Venue: Santa Barbara, CA
+
+
This 5-day in-person workshop will provide researchers with an introduction to advanced topics in computationally reproducible research in python, including software and techniques for working with very large datasets. This includes working in cloud computing environments, docker containers, and parallel processing using tools like parsl and dask. The workshop will also cover concrete methods for documenting and uploading data to the Arctic Data Center, advanced approaches to tracking data provenance, responsible research and data management practices including data sovereignty and the CARE principles, and ethical concerns with data-intensive modeling and analysis.
NSF award #2042102 to M. B. Jones, A. Budden, J. Dozier, and M. Schildhauer
+
+
+
Additional support was provided for working group collaboration by the National Center for Ecological Analysis and Synthesis, a Center funded by the University of California, Santa Barbara, and the State of California.
Previously called the Reproducible Research Techniques for Synthesis course
+
+
Dates: April 3-7, 2023
+Location: NCEAS
+Venue: Santa Barbara, CA
+
+
A five-day immersion in R programming for environmental data science. Researchers will gain experience with essential data science tools and best practices to increase their capacity as collaborators, reproducible coders, and open scientists. This course is taught both in-person and virtually.
+ Open Science Synthesis for the Delta Science Program
+
+
+
+
+
+
+
+
In collaboration with the Delta Science Program we are running a 12 month facilitated research synthesis activity, supported by 3 one-week intensive training events. Curriculum material will focus on introducing Delta Researchers to best practices in, and application of, scientific computing and
+scientific software for reproducible science. In addition to developing and delivering learning curriculum, this collaboration will include the provision of data consulting, synthesis facilitation, and a remote workshop to conclude the group synthesis activities.
+
+
The learning curricula will focus on techniques for data management, scientific programming, and collaboration techniques through the use of open-source, community-supported tools. Participants will learn skills for rapid and robust use of open source scientific software. These approaches will be explored and applied to scientific synthesis projects related to the Delta ecosystem.
+
+
The course will weave together several core themes which are reinforced – and injected into the real-time synthetic scientific research process – through work on group synthesis projects.
+
+
Schedule
+
+
Week 1: June 26-30, 2023. UC Davis.
+Week 2: August 28 - Spetember 1, 2023. UC Davis.
+Week 3: October 23-27, 2023. UC Davis.
+ In collaboration with the Delta Science Program we are running a 12 month facilitated research synthesis activity, supported by 3 one-week intensive training events. Curriculum material will focus on introducing Delta Researchers to best practices in, and application of, scientific computing and scientific software for reproducible science. In addition to developing and delivering learning curriculum, this collaboration will include the provision of data consulting, synthesis facilitation, and a remote workshop to conclude the group synthesis activities.
+
+ Previously called the Reproducible Research Techniques for Synthesis course
+Dates: April 3-7, 2023
+Location: NCEAS Venue: Santa Barbara, CA
+A five-day immersion in R programming for environmental data science. Researchers will gain experience with essential data science tools and best practices to increase their capacity as collaborators, reproducible coders, and open scientists. This course is taught both in-person and virtually.
+Materials Link to course book
+Instructors Name Email Halina Do-Linh dolinh@nceas.
+
+ Dates: March 27-31, 2023
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an introduction to advanced topics in computationally reproducible research in python, including software and techniques for working with very large datasets. This includes working in cloud computing environments, docker containers, and parallel processing using tools like parsl and dask. The workshop will also cover concrete methods for documenting and uploading data to the Arctic Data Center, advanced approaches to tracking data provenance, responsible research and data management practices including data sovereignty and the CARE principles, and ethical concerns with data-intensive modeling and analysis.
+
+ Dates: February 27 - March 3, 2023
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+This 5-day remote workshop will provided researchers with an overview of best data management practices, data science tools for cleaning and analyzing data, and concrete steps and methods for more easily documenting and preserving their data at the Arctic Data Center. Example tools included R, Rmarkdown, and git/GitHub. This course provided background in both the theory and practice of reproducible research, spanning all portions of the research lifecycle, from ethical data collection following the CARE principles to engage with local stakeholders, to data publishing.
+
+ Dates: January 30 - February 3, 2023
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an overview of reproducible and ethical research practices, steps and methods for more easily documenting and preserving their data at the Arctic Data Center, and an introduction to programming in R. Special attention will be paid to qualitative data management, including practices working with sensitive data. Example datasets will draw from natural and social sciences, and methods for conducting reproducible research will be discussed in the context of both qualitative and quantitative data.
+
+ Dates: September 19 - 23, 2022
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an introduction to advanced topics in computationally reproducible research in python, including software and techniques for working with very large datasets. This includes working in cloud computing environments, docker containers, and parallel processing using tools like parsl and dask. The workshop will also cover concrete methods for documenting and uploading data to the Arctic Data Center, advanced approaches to tracking data provenance, responsible research and data management practices including data sovereignty and the CARE principles, and ethical concerns with data-intensive modeling and analysis.
+
+ Dates: April 18 - 22, 2022
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an overview of reproducible and ethical research practices, steps and methods for more easily documenting and preserving their data at the Arctic Data Center, and an introduction to programming in R. Special attention will be paid to qualitative data management, including practices working with sensitive data. Example datasets will draw from natural and social sciences, and methods for conducting reproducible research will be discussed in the context of both qualitative and quantitative data.
+
+ Dates: February 14 - February 19, 2022
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+ Dates: March 29, 2022
+Location: Arctic Science Summit Week
+Venue: Tromso, Norway
+This workshop is a collaboration between the Arctic Data Center, ELOKA and the NNA Community Office, and will focus on the presentation of open science principles and best practices. Open science will be explored from the lens of reproducibility of research, Indigenous data sovereignty, and community data management. A combination of presentation and discussion will introduce participants to key topics, detail current recommended practices and highlight areas for future research.
+
+ Dates: November 15-19, 2021
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+Curriculum at a glance: Enable data reuse through better data management Metadata - what is it and how to write a quality data description Data modeling - tidy data for efficient access and storage Data publishing, citation, and credit Build reproducible scientific workflows Data munging with R tidyverse Working collaboratively - git and GitHub Writing functions in R Building packages for publishing reproducible research Communicate results effectively Literate analysis with RMarkdown Publishing analytical web pages with GitHub pages Data visualization with ggplot and leaflet For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/public/events/index.xml b/public/events/index.xml
new file mode 100644
index 00000000..09a40598
--- /dev/null
+++ b/public/events/index.xml
@@ -0,0 +1,360 @@
+
+
+
+ Events on NCEAS Training Materials Catalog
+ /events/
+ Recent content in Events on NCEAS Training Materials Catalog
+ Hugo -- gohugo.io
+ en-us
+ Mon, 26 Jun 2023 00:00:00 +0000
+
+
+
+
+
+ Open Science Synthesis for the Delta Science Program
+ /events/2023-06-delta/
+ Mon, 26 Jun 2023 00:00:00 +0000
+
+ /events/2023-06-delta/
+ In collaboration with the Delta Science Program we are running a 12 month facilitated research synthesis activity, supported by 3 one-week intensive training events. Curriculum material will focus on introducing Delta Researchers to best practices in, and application of, scientific computing and scientific software for reproducible science. In addition to developing and delivering learning curriculum, this collaboration will include the provision of data consulting, synthesis facilitation, and a remote workshop to conclude the group synthesis activities.
+
+
+
+ NCEAS Learning Hub coreR Course
+ /events/2023-04-corer/
+ Mon, 03 Apr 2023 00:00:00 +0000
+
+ /events/2023-04-corer/
+ Previously called the Reproducible Research Techniques for Synthesis course
+Dates: April 3-7, 2023
+Location: NCEAS Venue: Santa Barbara, CA
+A five-day immersion in R programming for environmental data science. Researchers will gain experience with essential data science tools and best practices to increase their capacity as collaborators, reproducible coders, and open scientists. This course is taught both in-person and virtually.
+Materials Link to course book
+Instructors Name Email Halina Do-Linh dolinh@nceas.
+
+
+
+ Scalable and Computationally Reproducible Approaches to Arctic Research
+ /events/2023-03-arctic/
+ Thu, 23 Mar 2023 00:00:00 +0000
+
+ /events/2023-03-arctic/
+ Dates: March 27-31, 2023
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an introduction to advanced topics in computationally reproducible research in python, including software and techniques for working with very large datasets. This includes working in cloud computing environments, docker containers, and parallel processing using tools like parsl and dask. The workshop will also cover concrete methods for documenting and uploading data to the Arctic Data Center, advanced approaches to tracking data provenance, responsible research and data management practices including data sovereignty and the CARE principles, and ethical concerns with data-intensive modeling and analysis.
+
+
+
+ Reproducible Practices for Arctic Research Using R
+ /events/2023-02-arctic/
+ Mon, 27 Feb 2023 00:00:00 +0000
+
+ /events/2023-02-arctic/
+ Dates: February 27 - March 3, 2023
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+This 5-day remote workshop will provided researchers with an overview of best data management practices, data science tools for cleaning and analyzing data, and concrete steps and methods for more easily documenting and preserving their data at the Arctic Data Center. Example tools included R, Rmarkdown, and git/GitHub. This course provided background in both the theory and practice of reproducible research, spanning all portions of the research lifecycle, from ethical data collection following the CARE principles to engage with local stakeholders, to data publishing.
+
+
+
+ Fundamentals in Data Management for Qualitative and Quantitative Arctic Research
+ /events/2023-01-arctic/
+ Mon, 30 Jan 2023 00:00:00 +0000
+
+ /events/2023-01-arctic/
+ Dates: January 30 - February 3, 2023
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an overview of reproducible and ethical research practices, steps and methods for more easily documenting and preserving their data at the Arctic Data Center, and an introduction to programming in R. Special attention will be paid to qualitative data management, including practices working with sensitive data. Example datasets will draw from natural and social sciences, and methods for conducting reproducible research will be discussed in the context of both qualitative and quantitative data.
+
+
+
+ Scalable and Computationally Reproducible Approaches to Arctic Research
+ /events/2022-09-arctic/
+ Sun, 18 Sep 2022 00:00:00 +0000
+
+ /events/2022-09-arctic/
+ Dates: September 19 - 23, 2022
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an introduction to advanced topics in computationally reproducible research in python, including software and techniques for working with very large datasets. This includes working in cloud computing environments, docker containers, and parallel processing using tools like parsl and dask. The workshop will also cover concrete methods for documenting and uploading data to the Arctic Data Center, advanced approaches to tracking data provenance, responsible research and data management practices including data sovereignty and the CARE principles, and ethical concerns with data-intensive modeling and analysis.
+
+
+
+ Fundamentals in Data Management for Qualitative and Quantitative Arctic Research
+ /events/2022-04-arctic/
+ Mon, 18 Apr 2022 00:00:00 +0000
+
+ /events/2022-04-arctic/
+ Dates: April 18 - 22, 2022
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an overview of reproducible and ethical research practices, steps and methods for more easily documenting and preserving their data at the Arctic Data Center, and an introduction to programming in R. Special attention will be paid to qualitative data management, including practices working with sensitive data. Example datasets will draw from natural and social sciences, and methods for conducting reproducible research will be discussed in the context of both qualitative and quantitative data.
+
+
+
+ Arctic Data Center Training (February 2022)
+ /events/2022_02_arctic/
+ Mon, 14 Feb 2022 00:00:00 +0000
+
+ /events/2022_02_arctic/
+ Dates: February 14 - February 19, 2022
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Open Science: Best Practices, Data Sovereignty and Co-production
+ /events/2022_03_arctic/
+ Mon, 14 Feb 2022 00:00:00 +0000
+
+ /events/2022_03_arctic/
+ Dates: March 29, 2022
+Location: Arctic Science Summit Week
+Venue: Tromso, Norway
+This workshop is a collaboration between the Arctic Data Center, ELOKA and the NNA Community Office, and will focus on the presentation of open science principles and best practices. Open science will be explored from the lens of reproducibility of research, Indigenous data sovereignty, and community data management. A combination of presentation and discussion will introduce participants to key topics, detail current recommended practices and highlight areas for future research.
+
+
+
+ Reproducible Research Techniques for Synthesis (November 2021)
+ /events/2021_11_nceas/
+ Fri, 05 Nov 2021 00:00:00 +0000
+
+ /events/2021_11_nceas/
+ Dates: November 15-19, 2021
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+Curriculum at a glance: Enable data reuse through better data management Metadata - what is it and how to write a quality data description Data modeling - tidy data for efficient access and storage Data publishing, citation, and credit Build reproducible scientific workflows Data munging with R tidyverse Working collaboratively - git and GitHub Writing functions in R Building packages for publishing reproducible research Communicate results effectively Literate analysis with RMarkdown Publishing analytical web pages with GitHub pages Data visualization with ggplot and leaflet For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
+
+
+
+ Managing Ecological Data for Effective Use and Re-Use
+ /events/2021_08_esa/
+ Wed, 28 Jul 2021 00:00:00 +0000
+
+ /events/2021_08_esa/
+ Friday, August 6th, 2021 10:30 AM - 1:30 PM
+Session Description While graduate students in ecology learn about methods for collecting and analyzing ecological data, there is less emphasis on managing and using the resulting data effectively. This is an increasingly important skill set as the research landscape changes. Researchers are increasingly engaging in collaboration across networks, many funding agencies require data management plans, journals are requiring that data and code be accessible, and society is increasingly expecting that research be reproducible.
+
+
+
+ Open Science Synthesis for the Delta Science Program
+ /events/2021_09_delta/
+ Thu, 27 May 2021 00:00:00 +0000
+
+ /events/2021_09_delta/
+ In collaboration with the Delta Science Program we are running a 12 month facilitated research synthesis activity, supported by 3 one-week intensive training events. Curriculum material will focus on introducing Delta Researchers to best practices in, and application of, scientific computing and scientific software for reproducible science. In addition to developing and delivering learning curriculum, this collaboration will include the provision of data consulting, synthesis facilitation, and a remote workshop to conclude the group synthesis activities.
+
+
+
+ Reproducible Research Techniques for Synthesis (July 2021)
+ /events/2021_07_nceas/
+ Tue, 25 May 2021 00:00:00 +0000
+
+ /events/2021_07_nceas/
+ Dates: July 8-9, 12-14, 2021
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
+
+ Reproducible Research Techniques for Synthesis (February 2021)
+ /events/2021_02_nceas/
+ Fri, 05 Feb 2021 00:00:00 +0000
+
+ /events/2021_02_nceas/
+ Dates: February 25-26, March 1-3, 2021
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
+
+ NEON Onboarding
+ /events/2020_12_neon/
+ Tue, 01 Dec 2020 00:00:00 +0000
+
+ /events/2020_12_neon/
+ Dates: December, 2020 Location: Virtual NEON Onboarding A self guided learning curricula to support new NEON postdocs as part of their onboarding experience. The curricula builds from the experience of ecological researchers, trainers, developers and information managers to provide resources and training in support of collaborative, reproducible research practices.
+Materials Link to onboarding materials
+
+
+
+ Reproducible Research Techniques for Synthesis (November 2020)
+ /events/2020_11_nceas/
+ Thu, 12 Nov 2020 00:00:00 +0000
+
+ /events/2020_11_nceas/
+ Dates: November 12 - November 18, 2020
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
+
+ Arctic Data Center Training (October 2020)
+ /events/2020_10_arctic/
+ Mon, 19 Oct 2020 00:00:00 +0000
+
+ /events/2020_10_arctic/
+ Dates: October 19 - October 23, 2020
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Tools and practices for collaborative, reproducible data science
+ /events/2020_05_nceaswg/
+ Fri, 08 May 2020 00:00:00 +0000
+
+ /events/2020_05_nceaswg/
+ Dates: May 8, 2020
+Location: Remote This module is an introduction to the data science support NCEAS is providing to LTER and SNAPP working groups followed by a discussion on best practices about data management in a distributed team setup. Participants will have the opportunity to brainstorm on their data and computing needs. In the second part of the workshop, an introduction to the use of NCEAS analytical server and the concept of collaborative coding as a distributed team will be demonstrated to empower participants to develop their analytical workflows in a remote setup.
+
+
+
+ Efficient virtual collaboration & facilitation for synthesis science
+ /events/2020_04_nceaswg/
+ Fri, 24 Apr 2020 00:00:00 +0000
+
+ /events/2020_04_nceaswg/
+ Dates: April 24, 2020
+Location: Remote This 3-hour module provides mentorship and facilitation training for Working Groups to develop skill sets, habits, and mindsets to make remote work and collaborative synthesis science more efficient and resilient.
+
+
+
+ Openscapes Champions Workshop with NOAA
+ /events/2020_02_openscapes/
+ Wed, 26 Feb 2020 00:00:00 +0000
+
+ /events/2020_02_openscapes/
+ Dates: February 26 - February 27, 2020
+Location: Woods Hole, Massachusetts. NOAA Northeast Fisheries Science Center. Through in-person Workshops, cohorts of research groups participate over a 2 full days. Workshops are designed to be engaging, requiring active participation through discussion, live-notetaking in Google Docs, and breakout group activities.
+Openscapes is operated by the National Center for Ecological Analysis & Synthesis (NCEAS) and is being incubated by a Mozilla Fellowship awarded to Julia Stewart Lowndes.
+
+
+
+ Data Science and Collaboration Skills for Integrative Conservation Science
+ /events/2020_02_snapp/
+ Tue, 18 Feb 2020 00:00:00 +0000
+
+ /events/2020_02_snapp/
+ Dates: February 18 - February 21, 2020
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+This intensive 4-day workshop on Data Science and Collaboration Skills for Integrative Conservation Science will be held at NCEAS, Santa Barbara, CA from Feb 18 to Feb 21, 2020.
+This training, sponsored by SNAPP, aims to bring together the SNAPP and NCEAS postdoctoral associates to foster communities and collaboration, as well as promote scientific computing and open science best practices.
+
+
+
+ Reproducible Research Techniques for Synthesis (February 2020)
+ /events/2020_02_nceas/
+ Mon, 03 Feb 2020 00:00:00 +0000
+
+ /events/2020_02_nceas/
+ Dates: February 3 - February 7, 2020
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
+
+ Reproducible Research Techniques for Synthesis (November 2019)
+ /events/2019_11_nceas/
+ Mon, 04 Nov 2019 00:00:00 +0000
+
+ /events/2019_11_nceas/
+ Dates: November 4 - November 8, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
+
+ Arctic Data Center Training (October 2019)
+ /events/2019_10_arctic/
+ Mon, 07 Oct 2019 00:00:00 +0000
+
+ /events/2019_10_arctic/
+ Dates: October 7 - October 11, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Arctic Data Center Training (February 2019)
+ /events/2019_02_arctic/
+ Mon, 11 Feb 2019 00:00:00 +0000
+
+ /events/2019_02_arctic/
+ Dates: February 11 - February 15, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Arctic Data Center Training (January 2019)
+ /events/2019_01_arctic/
+ Mon, 14 Jan 2019 00:00:00 +0000
+
+ /events/2019_01_arctic/
+ Dates: January 14 - January 18, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Openscapes Champions Cohort sponsored by Mozilla
+ /events/2019_01_openscapes/
+ Thu, 10 Jan 2019 00:00:00 +0000
+
+ /events/2019_01_openscapes/
+ Dates: January 10 - May 24, 2019
+Location: Remote In the Long-term Remote Program, Cohorts of research groups participate over a four-month period, with two Cohort Calls each month. Calls are designed to be engaging, requiring discussion and active participation through live-notetaking in Google Docs and video Zoom (group and breakouts).
+Openscapes is operated by the National Center for Ecological Analysis & Synthesis (NCEAS) and is being incubated by a Mozilla Fellowship awarded to Julia Stewart Lowndes.
+
+
+
+ Arctic Data Center Training (August 2018)
+ /events/2018_08_arctic/
+ Mon, 13 Aug 2018 00:00:00 +0000
+
+ /events/2018_08_arctic/
+ Dates: August 13 - August 17, 2018
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Dataset Publishing with the Arctic Data Center (June 2018)
+ /events/2018_06_arctic/
+ Fri, 22 Jun 2018 00:00:00 +0000
+
+ /events/2018_06_arctic/
+ Dates: June 22, 2018 12:30 to 14:00
+Location: Davos, Switzerland
+Venue: POLAR 2018 Open Science Conference
+This hands-on session will cover (1) Open data archives, especially the Arctic Data Center; (2) What science metadata is and how it can be used; (3) How data and code can be documented and published in open data archives; (4) Web-based submission, and (5) Submission using R (pending sufficient time).
+Course overview The Arctic Data Center conducts training in data science and management, both of which are critical skills for stewardship of data, software, and other products of research that are preserved at the Arctic Data Center.
+
+
+
+ Tools for Data Science in Arctic Research (July 2017)
+ /events/2017_07_arctic/
+ Mon, 31 Jul 2017 00:00:00 +0000
+
+ /events/2017_07_arctic/
+ Dates: July 31 - Aug 1, 2017
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Open Science for Synthesis: Gulf Research Program Workshop
+ /events/2017_07_oss/
+ Mon, 10 Jul 2017 00:00:00 +0000
+
+ /events/2017_07_oss/
+ Dates: July 10 - July 28, 2017
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+The primary goal of the Open Science for Synthesis: Gulf Research Program Workshop is to provide hands-on experience with contemporary open science tools from command line to data to communication. Team science is promoted. Practice and real data are used in groups to apply skills we explore.
+Week 1.
+
+
+
+
\ No newline at end of file
diff --git a/public/events/page/1/index.html b/public/events/page/1/index.html
new file mode 100644
index 00000000..666ee42c
--- /dev/null
+++ b/public/events/page/1/index.html
@@ -0,0 +1 @@
+/events/
\ No newline at end of file
diff --git a/public/events/page/2/index.html b/public/events/page/2/index.html
new file mode 100644
index 00000000..cbeb80ee
--- /dev/null
+++ b/public/events/page/2/index.html
@@ -0,0 +1,403 @@
+
+
+
+
+
+
+ NCEAS Training Materials Catalog
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Friday, August 6th, 2021 10:30 AM - 1:30 PM
+Session Description While graduate students in ecology learn about methods for collecting and analyzing ecological data, there is less emphasis on managing and using the resulting data effectively. This is an increasingly important skill set as the research landscape changes. Researchers are increasingly engaging in collaboration across networks, many funding agencies require data management plans, journals are requiring that data and code be accessible, and society is increasingly expecting that research be reproducible.
+
+ In collaboration with the Delta Science Program we are running a 12 month facilitated research synthesis activity, supported by 3 one-week intensive training events. Curriculum material will focus on introducing Delta Researchers to best practices in, and application of, scientific computing and scientific software for reproducible science. In addition to developing and delivering learning curriculum, this collaboration will include the provision of data consulting, synthesis facilitation, and a remote workshop to conclude the group synthesis activities.
+
+ Dates: July 8-9, 12-14, 2021
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+ Dates: February 25-26, March 1-3, 2021
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+ Dates: December, 2020 Location: Virtual NEON Onboarding A self guided learning curricula to support new NEON postdocs as part of their onboarding experience. The curricula builds from the experience of ecological researchers, trainers, developers and information managers to provide resources and training in support of collaborative, reproducible research practices.
+Materials Link to onboarding materials
+
+ Dates: November 12 - November 18, 2020
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+ Dates: October 19 - October 23, 2020
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+ Dates: May 8, 2020
+Location: Remote This module is an introduction to the data science support NCEAS is providing to LTER and SNAPP working groups followed by a discussion on best practices about data management in a distributed team setup. Participants will have the opportunity to brainstorm on their data and computing needs. In the second part of the workshop, an introduction to the use of NCEAS analytical server and the concept of collaborative coding as a distributed team will be demonstrated to empower participants to develop their analytical workflows in a remote setup.
+
+ Dates: April 24, 2020
+Location: Remote This 3-hour module provides mentorship and facilitation training for Working Groups to develop skill sets, habits, and mindsets to make remote work and collaborative synthesis science more efficient and resilient.
+
+ Dates: February 26 - February 27, 2020
+Location: Woods Hole, Massachusetts. NOAA Northeast Fisheries Science Center. Through in-person Workshops, cohorts of research groups participate over a 2 full days. Workshops are designed to be engaging, requiring active participation through discussion, live-notetaking in Google Docs, and breakout group activities.
+Openscapes is operated by the National Center for Ecological Analysis & Synthesis (NCEAS) and is being incubated by a Mozilla Fellowship awarded to Julia Stewart Lowndes.
+
+ Dates: February 18 - February 21, 2020
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+This intensive 4-day workshop on Data Science and Collaboration Skills for Integrative Conservation Science will be held at NCEAS, Santa Barbara, CA from Feb 18 to Feb 21, 2020.
+This training, sponsored by SNAPP, aims to bring together the SNAPP and NCEAS postdoctoral associates to foster communities and collaboration, as well as promote scientific computing and open science best practices.
+
+ Dates: February 3 - February 7, 2020
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+ Dates: November 4 - November 8, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+ Dates: October 7 - October 11, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+ Dates: February 11 - February 15, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+ Dates: January 14 - January 18, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+ Dates: January 10 - May 24, 2019
+Location: Remote In the Long-term Remote Program, Cohorts of research groups participate over a four-month period, with two Cohort Calls each month. Calls are designed to be engaging, requiring discussion and active participation through live-notetaking in Google Docs and video Zoom (group and breakouts).
+Openscapes is operated by the National Center for Ecological Analysis & Synthesis (NCEAS) and is being incubated by a Mozilla Fellowship awarded to Julia Stewart Lowndes.
+
+ Dates: August 13 - August 17, 2018
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+ Dates: June 22, 2018 12:30 to 14:00
+Location: Davos, Switzerland
+Venue: POLAR 2018 Open Science Conference
+This hands-on session will cover (1) Open data archives, especially the Arctic Data Center; (2) What science metadata is and how it can be used; (3) How data and code can be documented and published in open data archives; (4) Web-based submission, and (5) Submission using R (pending sufficient time).
+Course overview The Arctic Data Center conducts training in data science and management, both of which are critical skills for stewardship of data, software, and other products of research that are preserved at the Arctic Data Center.
+
+ Dates: July 31 - Aug 1, 2017
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+ Dates: July 10 - July 28, 2017
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+The primary goal of the Open Science for Synthesis: Gulf Research Program Workshop is to provide hands-on experience with contemporary open science tools from command line to data to communication. Team science is promoted. Practice and real data are used in groups to apply skills we explore.
+Week 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/public/files/tempeco_DMP-2.pdf b/public/files/tempeco_DMP-2.pdf
new file mode 100644
index 00000000..32032513
Binary files /dev/null and b/public/files/tempeco_DMP-2.pdf differ
diff --git a/public/images/FAIR_CARE.png b/public/images/FAIR_CARE.png
new file mode 100644
index 00000000..3f3a1132
Binary files /dev/null and b/public/images/FAIR_CARE.png differ
diff --git a/public/images/FAIRsFAIR.png b/public/images/FAIRsFAIR.png
new file mode 100644
index 00000000..562dde76
Binary files /dev/null and b/public/images/FAIRsFAIR.png differ
diff --git a/public/images/Mountains.jpg b/public/images/Mountains.jpg
new file mode 100644
index 00000000..1c261dc4
Binary files /dev/null and b/public/images/Mountains.jpg differ
diff --git a/public/images/NCEAS_logo.png b/public/images/NCEAS_logo.png
new file mode 100644
index 00000000..a60a88ce
Binary files /dev/null and b/public/images/NCEAS_logo.png differ
diff --git a/public/images/NSF_Logo.jpg b/public/images/NSF_Logo.jpg
new file mode 100644
index 00000000..00d118e6
Binary files /dev/null and b/public/images/NSF_Logo.jpg differ
diff --git a/public/images/alaska_population.png b/public/images/alaska_population.png
new file mode 100644
index 00000000..16465fea
Binary files /dev/null and b/public/images/alaska_population.png differ
diff --git a/public/images/allison-horst-jenny-bryan-quote.png b/public/images/allison-horst-jenny-bryan-quote.png
new file mode 100644
index 00000000..4c44b266
Binary files /dev/null and b/public/images/allison-horst-jenny-bryan-quote.png differ
diff --git a/public/images/delta/delta-logo.png b/public/images/delta/delta-logo.png
new file mode 100644
index 00000000..606dd02c
Binary files /dev/null and b/public/images/delta/delta-logo.png differ
diff --git a/public/images/ethical-dataset-retractions.png b/public/images/ethical-dataset-retractions.png
new file mode 100644
index 00000000..4f9ea271
Binary files /dev/null and b/public/images/ethical-dataset-retractions.png differ
diff --git a/public/images/fieldwork.jpg b/public/images/fieldwork.jpg
new file mode 100644
index 00000000..366b5d21
Binary files /dev/null and b/public/images/fieldwork.jpg differ
diff --git a/public/images/fishing.jpg b/public/images/fishing.jpg
new file mode 100644
index 00000000..0c09b690
Binary files /dev/null and b/public/images/fishing.jpg differ
diff --git a/public/images/force11-cope-logos.png b/public/images/force11-cope-logos.png
new file mode 100644
index 00000000..f35d2a85
Binary files /dev/null and b/public/images/force11-cope-logos.png differ
diff --git a/public/images/git-collab-repos.svg b/public/images/git-collab-repos.svg
new file mode 100644
index 00000000..4db4c4c1
--- /dev/null
+++ b/public/images/git-collab-repos.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/public/images/git-conflict-00-lines-changed.png b/public/images/git-conflict-00-lines-changed.png
new file mode 100644
index 00000000..a289551a
Binary files /dev/null and b/public/images/git-conflict-00-lines-changed.png differ
diff --git a/public/images/git-conflict-01-push-error.png b/public/images/git-conflict-01-push-error.png
new file mode 100644
index 00000000..7e1306c6
Binary files /dev/null and b/public/images/git-conflict-01-push-error.png differ
diff --git a/public/images/git-conflict-02-pull-error.png b/public/images/git-conflict-02-pull-error.png
new file mode 100644
index 00000000..609805b4
Binary files /dev/null and b/public/images/git-conflict-02-pull-error.png differ
diff --git a/public/images/git-conflict-03-conflict.png b/public/images/git-conflict-03-conflict.png
new file mode 100644
index 00000000..2d6d9045
Binary files /dev/null and b/public/images/git-conflict-03-conflict.png differ
diff --git a/public/images/git-conflict-04-conflict-tags.png b/public/images/git-conflict-04-conflict-tags.png
new file mode 100644
index 00000000..eb8d5cb0
Binary files /dev/null and b/public/images/git-conflict-04-conflict-tags.png differ
diff --git a/public/images/git-conflict-05-resolved-file.png b/public/images/git-conflict-05-resolved-file.png
new file mode 100644
index 00000000..b558f119
Binary files /dev/null and b/public/images/git-conflict-05-resolved-file.png differ
diff --git a/public/images/git-conflict-06-commit-resolved.png b/public/images/git-conflict-06-commit-resolved.png
new file mode 100644
index 00000000..669d8add
Binary files /dev/null and b/public/images/git-conflict-06-commit-resolved.png differ
diff --git a/public/images/git-conflict-07-push-resolved.png b/public/images/git-conflict-07-push-resolved.png
new file mode 100644
index 00000000..66d7df6c
Binary files /dev/null and b/public/images/git-conflict-07-push-resolved.png differ
diff --git a/public/images/git-conflict-08-history.png b/public/images/git-conflict-08-history.png
new file mode 100644
index 00000000..ba77318d
Binary files /dev/null and b/public/images/git-conflict-08-history.png differ
diff --git a/public/images/git-index-page.png b/public/images/git-index-page.png
new file mode 100644
index 00000000..f549aded
Binary files /dev/null and b/public/images/git-index-page.png differ
diff --git a/public/images/git-xkcd-comic.png b/public/images/git-xkcd-comic.png
new file mode 100644
index 00000000..3f35d2d7
Binary files /dev/null and b/public/images/git-xkcd-comic.png differ
diff --git a/public/images/github-clone-url-owner.png b/public/images/github-clone-url-owner.png
new file mode 100644
index 00000000..0f1e834e
Binary files /dev/null and b/public/images/github-clone-url-owner.png differ
diff --git a/public/images/github-collaborators.png b/public/images/github-collaborators.png
new file mode 100644
index 00000000..e971f578
Binary files /dev/null and b/public/images/github-collaborators.png differ
diff --git a/public/images/github_pages.png b/public/images/github_pages.png
new file mode 100644
index 00000000..2be2e2be
Binary files /dev/null and b/public/images/github_pages.png differ
diff --git a/public/images/gohugo-default-sample-hero-image.jpg b/public/images/gohugo-default-sample-hero-image.jpg
new file mode 100644
index 00000000..06815836
Binary files /dev/null and b/public/images/gohugo-default-sample-hero-image.jpg differ
diff --git a/public/images/group-work.jpg b/public/images/group-work.jpg
new file mode 100644
index 00000000..9875a3de
Binary files /dev/null and b/public/images/group-work.jpg differ
diff --git a/public/images/gsheets-access.png b/public/images/gsheets-access.png
new file mode 100644
index 00000000..26c54af2
Binary files /dev/null and b/public/images/gsheets-access.png differ
diff --git a/public/images/horst_openscapes.jpg b/public/images/horst_openscapes.jpg
new file mode 100644
index 00000000..7877d3b4
Binary files /dev/null and b/public/images/horst_openscapes.jpg differ
diff --git a/public/images/nceas.png b/public/images/nceas.png
new file mode 100644
index 00000000..4a98b7ad
Binary files /dev/null and b/public/images/nceas.png differ
diff --git a/public/images/phdcomics_031305s_authorlist.gif b/public/images/phdcomics_031305s_authorlist.gif
new file mode 100755
index 00000000..a9fd028e
Binary files /dev/null and b/public/images/phdcomics_031305s_authorlist.gif differ
diff --git a/public/images/projections-esri-blog.jpg b/public/images/projections-esri-blog.jpg
new file mode 100644
index 00000000..12df9cdd
Binary files /dev/null and b/public/images/projections-esri-blog.jpg differ
diff --git a/public/images/rocky-mountains.jpg b/public/images/rocky-mountains.jpg
new file mode 100644
index 00000000..5b831cf8
Binary files /dev/null and b/public/images/rocky-mountains.jpg differ
diff --git a/public/images/rstudio-commit-push.png b/public/images/rstudio-commit-push.png
new file mode 100644
index 00000000..62f66eff
Binary files /dev/null and b/public/images/rstudio-commit-push.png differ
diff --git a/public/images/rstudio-merge-conflict.png b/public/images/rstudio-merge-conflict.png
new file mode 100644
index 00000000..83bbce17
Binary files /dev/null and b/public/images/rstudio-merge-conflict.png differ
diff --git a/public/images/shiny-architecture.png b/public/images/shiny-architecture.png
new file mode 100644
index 00000000..95abcdd3
Binary files /dev/null and b/public/images/shiny-architecture.png differ
diff --git a/public/images/shiny-default-app.png b/public/images/shiny-default-app.png
new file mode 100644
index 00000000..6b9b9dfe
Binary files /dev/null and b/public/images/shiny-default-app.png differ
diff --git a/public/images/shiny-io-account.png b/public/images/shiny-io-account.png
new file mode 100644
index 00000000..5349f702
Binary files /dev/null and b/public/images/shiny-io-account.png differ
diff --git a/public/images/shiny-layout-1.png b/public/images/shiny-layout-1.png
new file mode 100644
index 00000000..0c3efb2f
Binary files /dev/null and b/public/images/shiny-layout-1.png differ
diff --git a/public/images/shiny-layout-2.png b/public/images/shiny-layout-2.png
new file mode 100644
index 00000000..eedffe87
Binary files /dev/null and b/public/images/shiny-layout-2.png differ
diff --git a/public/images/shiny-new-app.png b/public/images/shiny-new-app.png
new file mode 100644
index 00000000..6917cc31
Binary files /dev/null and b/public/images/shiny-new-app.png differ
diff --git a/public/images/shiny-publish.png b/public/images/shiny-publish.png
new file mode 100644
index 00000000..ab09692f
Binary files /dev/null and b/public/images/shiny-publish.png differ
diff --git a/public/images/shiny-sasap-app.png b/public/images/shiny-sasap-app.png
new file mode 100644
index 00000000..b639622e
Binary files /dev/null and b/public/images/shiny-sasap-app.png differ
diff --git a/public/images/shiny-yolo-1.png b/public/images/shiny-yolo-1.png
new file mode 100644
index 00000000..e77832b9
Binary files /dev/null and b/public/images/shiny-yolo-1.png differ
diff --git a/public/images/shiny-yolo-2.png b/public/images/shiny-yolo-2.png
new file mode 100644
index 00000000..a409c6b0
Binary files /dev/null and b/public/images/shiny-yolo-2.png differ
diff --git a/public/images/shiny-yolo-app.png b/public/images/shiny-yolo-app.png
new file mode 100644
index 00000000..4b8fddf6
Binary files /dev/null and b/public/images/shiny-yolo-app.png differ
diff --git a/public/images/short-course.jpg b/public/images/short-course.jpg
new file mode 100644
index 00000000..33c01bef
Binary files /dev/null and b/public/images/short-course.jpg differ
diff --git a/public/images/sierra-nevada.jpg b/public/images/sierra-nevada.jpg
new file mode 100644
index 00000000..a70dbd20
Binary files /dev/null and b/public/images/sierra-nevada.jpg differ
diff --git a/public/images/survey_comparison.png b/public/images/survey_comparison.png
new file mode 100644
index 00000000..f80360f4
Binary files /dev/null and b/public/images/survey_comparison.png differ
diff --git a/public/images/survey_consent.png b/public/images/survey_consent.png
new file mode 100644
index 00000000..317a26c4
Binary files /dev/null and b/public/images/survey_consent.png differ
diff --git a/public/images/survey_main.png b/public/images/survey_main.png
new file mode 100644
index 00000000..0f2a2ef6
Binary files /dev/null and b/public/images/survey_main.png differ
diff --git a/public/index.html b/public/index.html
new file mode 100644
index 00000000..60195906
--- /dev/null
+++ b/public/index.html
@@ -0,0 +1,580 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
NCEAS Open Science Synthesis for the Delta Science Program
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Overview
+
+
+
+
+
+
+
+
+
+
+
+
+
+
About this training
+
NCEAS Open Science Synthesis training consists of three 1-week long workshops, geared towards early career researchers. Participants engage in a mix of lectures, exercises, and synthesis research groups to undertake synthesis while learning and implementing best practices for open data science.
+
+
+
+
Why NCEAS
+
The National Center for Ecological Analysis and Synthesis (NCEAS), a research affiliate of UCSB, is a leading expert on interdisciplinary data science and works collaboratively to answer the world’s largest and most complex questions. The NCEAS approach leverages existing data and employs a team science philosophy to squeeze out all potential insights and solutions efficiently - this is called synthesis science.
+
NCEAS has over 25 years of success with this model among working groups and environmental professionals. Together with the Delta Science Program and the Delta Stewardship Council we are excited to pass along skills, workflows, mindsets learn throughout the years.
+
+
Week 2: Open Tools for Analysis and Visualization
+
Aug 28 - Sep 1, 2023
+
+
Strengthen core knowledge of version control and workflow
These written materials are the result of a continuous and collaborative effort at NCEAS with the support of DataONE, to help researchers make their work more transparent and reproducible. This work began in the early 2000’s, and reflects the expertise and diligence of many, many individuals. The primary authors for this version are listed in the citation below, with additional contributors recognized for their role in developing previous iterations of these or similar materials.
+
+
+
+
\ No newline at end of file
diff --git a/public/index.xml b/public/index.xml
new file mode 100644
index 00000000..05e2b44f
--- /dev/null
+++ b/public/index.xml
@@ -0,0 +1,360 @@
+
+
+
+ NCEAS Training Materials Catalog
+ /
+ Recent content on NCEAS Training Materials Catalog
+ Hugo -- gohugo.io
+ en-us
+ Mon, 26 Jun 2023 00:00:00 +0000
+
+
+
+
+
+ Open Science Synthesis for the Delta Science Program
+ /events/2023-06-delta/
+ Mon, 26 Jun 2023 00:00:00 +0000
+
+ /events/2023-06-delta/
+ In collaboration with the Delta Science Program we are running a 12 month facilitated research synthesis activity, supported by 3 one-week intensive training events. Curriculum material will focus on introducing Delta Researchers to best practices in, and application of, scientific computing and scientific software for reproducible science. In addition to developing and delivering learning curriculum, this collaboration will include the provision of data consulting, synthesis facilitation, and a remote workshop to conclude the group synthesis activities.
+
+
+
+ NCEAS Learning Hub coreR Course
+ /events/2023-04-corer/
+ Mon, 03 Apr 2023 00:00:00 +0000
+
+ /events/2023-04-corer/
+ Previously called the Reproducible Research Techniques for Synthesis course
+Dates: April 3-7, 2023
+Location: NCEAS Venue: Santa Barbara, CA
+A five-day immersion in R programming for environmental data science. Researchers will gain experience with essential data science tools and best practices to increase their capacity as collaborators, reproducible coders, and open scientists. This course is taught both in-person and virtually.
+Materials Link to course book
+Instructors Name Email Halina Do-Linh dolinh@nceas.
+
+
+
+ Scalable and Computationally Reproducible Approaches to Arctic Research
+ /events/2023-03-arctic/
+ Thu, 23 Mar 2023 00:00:00 +0000
+
+ /events/2023-03-arctic/
+ Dates: March 27-31, 2023
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an introduction to advanced topics in computationally reproducible research in python, including software and techniques for working with very large datasets. This includes working in cloud computing environments, docker containers, and parallel processing using tools like parsl and dask. The workshop will also cover concrete methods for documenting and uploading data to the Arctic Data Center, advanced approaches to tracking data provenance, responsible research and data management practices including data sovereignty and the CARE principles, and ethical concerns with data-intensive modeling and analysis.
+
+
+
+ Reproducible Practices for Arctic Research Using R
+ /events/2023-02-arctic/
+ Mon, 27 Feb 2023 00:00:00 +0000
+
+ /events/2023-02-arctic/
+ Dates: February 27 - March 3, 2023
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+This 5-day remote workshop will provided researchers with an overview of best data management practices, data science tools for cleaning and analyzing data, and concrete steps and methods for more easily documenting and preserving their data at the Arctic Data Center. Example tools included R, Rmarkdown, and git/GitHub. This course provided background in both the theory and practice of reproducible research, spanning all portions of the research lifecycle, from ethical data collection following the CARE principles to engage with local stakeholders, to data publishing.
+
+
+
+ Fundamentals in Data Management for Qualitative and Quantitative Arctic Research
+ /events/2023-01-arctic/
+ Mon, 30 Jan 2023 00:00:00 +0000
+
+ /events/2023-01-arctic/
+ Dates: January 30 - February 3, 2023
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an overview of reproducible and ethical research practices, steps and methods for more easily documenting and preserving their data at the Arctic Data Center, and an introduction to programming in R. Special attention will be paid to qualitative data management, including practices working with sensitive data. Example datasets will draw from natural and social sciences, and methods for conducting reproducible research will be discussed in the context of both qualitative and quantitative data.
+
+
+
+ Scalable and Computationally Reproducible Approaches to Arctic Research
+ /events/2022-09-arctic/
+ Sun, 18 Sep 2022 00:00:00 +0000
+
+ /events/2022-09-arctic/
+ Dates: September 19 - 23, 2022
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an introduction to advanced topics in computationally reproducible research in python, including software and techniques for working with very large datasets. This includes working in cloud computing environments, docker containers, and parallel processing using tools like parsl and dask. The workshop will also cover concrete methods for documenting and uploading data to the Arctic Data Center, advanced approaches to tracking data provenance, responsible research and data management practices including data sovereignty and the CARE principles, and ethical concerns with data-intensive modeling and analysis.
+
+
+
+ Fundamentals in Data Management for Qualitative and Quantitative Arctic Research
+ /events/2022-04-arctic/
+ Mon, 18 Apr 2022 00:00:00 +0000
+
+ /events/2022-04-arctic/
+ Dates: April 18 - 22, 2022
+Location: NCEAS Venue: Santa Barbara, CA
+This 5-day in-person workshop will provide researchers with an overview of reproducible and ethical research practices, steps and methods for more easily documenting and preserving their data at the Arctic Data Center, and an introduction to programming in R. Special attention will be paid to qualitative data management, including practices working with sensitive data. Example datasets will draw from natural and social sciences, and methods for conducting reproducible research will be discussed in the context of both qualitative and quantitative data.
+
+
+
+ Arctic Data Center Training (February 2022)
+ /events/2022_02_arctic/
+ Mon, 14 Feb 2022 00:00:00 +0000
+
+ /events/2022_02_arctic/
+ Dates: February 14 - February 19, 2022
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Open Science: Best Practices, Data Sovereignty and Co-production
+ /events/2022_03_arctic/
+ Mon, 14 Feb 2022 00:00:00 +0000
+
+ /events/2022_03_arctic/
+ Dates: March 29, 2022
+Location: Arctic Science Summit Week
+Venue: Tromso, Norway
+This workshop is a collaboration between the Arctic Data Center, ELOKA and the NNA Community Office, and will focus on the presentation of open science principles and best practices. Open science will be explored from the lens of reproducibility of research, Indigenous data sovereignty, and community data management. A combination of presentation and discussion will introduce participants to key topics, detail current recommended practices and highlight areas for future research.
+
+
+
+ Reproducible Research Techniques for Synthesis (November 2021)
+ /events/2021_11_nceas/
+ Fri, 05 Nov 2021 00:00:00 +0000
+
+ /events/2021_11_nceas/
+ Dates: November 15-19, 2021
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+Curriculum at a glance: Enable data reuse through better data management Metadata - what is it and how to write a quality data description Data modeling - tidy data for efficient access and storage Data publishing, citation, and credit Build reproducible scientific workflows Data munging with R tidyverse Working collaboratively - git and GitHub Writing functions in R Building packages for publishing reproducible research Communicate results effectively Literate analysis with RMarkdown Publishing analytical web pages with GitHub pages Data visualization with ggplot and leaflet For more detailed information on how to prepare for the workshop, see preparing for the workshop (below).
+
+
+
+ Managing Ecological Data for Effective Use and Re-Use
+ /events/2021_08_esa/
+ Wed, 28 Jul 2021 00:00:00 +0000
+
+ /events/2021_08_esa/
+ Friday, August 6th, 2021 10:30 AM - 1:30 PM
+Session Description While graduate students in ecology learn about methods for collecting and analyzing ecological data, there is less emphasis on managing and using the resulting data effectively. This is an increasingly important skill set as the research landscape changes. Researchers are increasingly engaging in collaboration across networks, many funding agencies require data management plans, journals are requiring that data and code be accessible, and society is increasingly expecting that research be reproducible.
+
+
+
+ Open Science Synthesis for the Delta Science Program
+ /events/2021_09_delta/
+ Thu, 27 May 2021 00:00:00 +0000
+
+ /events/2021_09_delta/
+ In collaboration with the Delta Science Program we are running a 12 month facilitated research synthesis activity, supported by 3 one-week intensive training events. Curriculum material will focus on introducing Delta Researchers to best practices in, and application of, scientific computing and scientific software for reproducible science. In addition to developing and delivering learning curriculum, this collaboration will include the provision of data consulting, synthesis facilitation, and a remote workshop to conclude the group synthesis activities.
+
+
+
+ Reproducible Research Techniques for Synthesis (July 2021)
+ /events/2021_07_nceas/
+ Tue, 25 May 2021 00:00:00 +0000
+
+ /events/2021_07_nceas/
+ Dates: July 8-9, 12-14, 2021
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
+
+ Reproducible Research Techniques for Synthesis (February 2021)
+ /events/2021_02_nceas/
+ Fri, 05 Feb 2021 00:00:00 +0000
+
+ /events/2021_02_nceas/
+ Dates: February 25-26, March 1-3, 2021
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
+
+ NEON Onboarding
+ /events/2020_12_neon/
+ Tue, 01 Dec 2020 00:00:00 +0000
+
+ /events/2020_12_neon/
+ Dates: December, 2020 Location: Virtual NEON Onboarding A self guided learning curricula to support new NEON postdocs as part of their onboarding experience. The curricula builds from the experience of ecological researchers, trainers, developers and information managers to provide resources and training in support of collaborative, reproducible research practices.
+Materials Link to onboarding materials
+
+
+
+ Reproducible Research Techniques for Synthesis (November 2020)
+ /events/2020_11_nceas/
+ Thu, 12 Nov 2020 00:00:00 +0000
+
+ /events/2020_11_nceas/
+ Dates: November 12 - November 18, 2020
+Location: Remote
+This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
+
+ Arctic Data Center Training (October 2020)
+ /events/2020_10_arctic/
+ Mon, 19 Oct 2020 00:00:00 +0000
+
+ /events/2020_10_arctic/
+ Dates: October 19 - October 23, 2020
+Location: Online
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Tools and practices for collaborative, reproducible data science
+ /events/2020_05_nceaswg/
+ Fri, 08 May 2020 00:00:00 +0000
+
+ /events/2020_05_nceaswg/
+ Dates: May 8, 2020
+Location: Remote This module is an introduction to the data science support NCEAS is providing to LTER and SNAPP working groups followed by a discussion on best practices about data management in a distributed team setup. Participants will have the opportunity to brainstorm on their data and computing needs. In the second part of the workshop, an introduction to the use of NCEAS analytical server and the concept of collaborative coding as a distributed team will be demonstrated to empower participants to develop their analytical workflows in a remote setup.
+
+
+
+ Efficient virtual collaboration & facilitation for synthesis science
+ /events/2020_04_nceaswg/
+ Fri, 24 Apr 2020 00:00:00 +0000
+
+ /events/2020_04_nceaswg/
+ Dates: April 24, 2020
+Location: Remote This 3-hour module provides mentorship and facilitation training for Working Groups to develop skill sets, habits, and mindsets to make remote work and collaborative synthesis science more efficient and resilient.
+
+
+
+ Openscapes Champions Workshop with NOAA
+ /events/2020_02_openscapes/
+ Wed, 26 Feb 2020 00:00:00 +0000
+
+ /events/2020_02_openscapes/
+ Dates: February 26 - February 27, 2020
+Location: Woods Hole, Massachusetts. NOAA Northeast Fisheries Science Center. Through in-person Workshops, cohorts of research groups participate over a 2 full days. Workshops are designed to be engaging, requiring active participation through discussion, live-notetaking in Google Docs, and breakout group activities.
+Openscapes is operated by the National Center for Ecological Analysis & Synthesis (NCEAS) and is being incubated by a Mozilla Fellowship awarded to Julia Stewart Lowndes.
+
+
+
+ Data Science and Collaboration Skills for Integrative Conservation Science
+ /events/2020_02_snapp/
+ Tue, 18 Feb 2020 00:00:00 +0000
+
+ /events/2020_02_snapp/
+ Dates: February 18 - February 21, 2020
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+This intensive 4-day workshop on Data Science and Collaboration Skills for Integrative Conservation Science will be held at NCEAS, Santa Barbara, CA from Feb 18 to Feb 21, 2020.
+This training, sponsored by SNAPP, aims to bring together the SNAPP and NCEAS postdoctoral associates to foster communities and collaboration, as well as promote scientific computing and open science best practices.
+
+
+
+ Reproducible Research Techniques for Synthesis (February 2020)
+ /events/2020_02_nceas/
+ Mon, 03 Feb 2020 00:00:00 +0000
+
+ /events/2020_02_nceas/
+ Dates: February 3 - February 7, 2020
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
+
+ Reproducible Research Techniques for Synthesis (November 2019)
+ /events/2019_11_nceas/
+ Mon, 04 Nov 2019 00:00:00 +0000
+
+ /events/2019_11_nceas/
+ Dates: November 4 - November 8, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara This 5-day workshop will provide researchers with an overview of best data management practices, data science tools, and concrete steps and methods for more easily producing transparent, reproducible workflows. This opportunity is for researchers from across career stages and sectors who want to gain fundamental data science skills that will improve their reproducible research techniques, particularly for the purposes of synthesis science.
+
+
+
+ Arctic Data Center Training (October 2019)
+ /events/2019_10_arctic/
+ Mon, 07 Oct 2019 00:00:00 +0000
+
+ /events/2019_10_arctic/
+ Dates: October 7 - October 11, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Arctic Data Center Training (February 2019)
+ /events/2019_02_arctic/
+ Mon, 11 Feb 2019 00:00:00 +0000
+
+ /events/2019_02_arctic/
+ Dates: February 11 - February 15, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Arctic Data Center Training (January 2019)
+ /events/2019_01_arctic/
+ Mon, 14 Jan 2019 00:00:00 +0000
+
+ /events/2019_01_arctic/
+ Dates: January 14 - January 18, 2019
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Openscapes Champions Cohort sponsored by Mozilla
+ /events/2019_01_openscapes/
+ Thu, 10 Jan 2019 00:00:00 +0000
+
+ /events/2019_01_openscapes/
+ Dates: January 10 - May 24, 2019
+Location: Remote In the Long-term Remote Program, Cohorts of research groups participate over a four-month period, with two Cohort Calls each month. Calls are designed to be engaging, requiring discussion and active participation through live-notetaking in Google Docs and video Zoom (group and breakouts).
+Openscapes is operated by the National Center for Ecological Analysis & Synthesis (NCEAS) and is being incubated by a Mozilla Fellowship awarded to Julia Stewart Lowndes.
+
+
+
+ Arctic Data Center Training (August 2018)
+ /events/2018_08_arctic/
+ Mon, 13 Aug 2018 00:00:00 +0000
+
+ /events/2018_08_arctic/
+ Dates: August 13 - August 17, 2018
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Dataset Publishing with the Arctic Data Center (June 2018)
+ /events/2018_06_arctic/
+ Fri, 22 Jun 2018 00:00:00 +0000
+
+ /events/2018_06_arctic/
+ Dates: June 22, 2018 12:30 to 14:00
+Location: Davos, Switzerland
+Venue: POLAR 2018 Open Science Conference
+This hands-on session will cover (1) Open data archives, especially the Arctic Data Center; (2) What science metadata is and how it can be used; (3) How data and code can be documented and published in open data archives; (4) Web-based submission, and (5) Submission using R (pending sufficient time).
+Course overview The Arctic Data Center conducts training in data science and management, both of which are critical skills for stewardship of data, software, and other products of research that are preserved at the Arctic Data Center.
+
+
+
+ Tools for Data Science in Arctic Research (July 2017)
+ /events/2017_07_arctic/
+ Mon, 31 Jul 2017 00:00:00 +0000
+
+ /events/2017_07_arctic/
+ Dates: July 31 - Aug 1, 2017
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara The Arctic Data Center provides training in data science and data management, as these are critical skills for the stewardship of the data, software, and other research products that are preserved in the Arctic Data Center. A goal of the Arctic Data Center is to advance data archiving and promote reproducible science and data reuse.
+
+
+
+ Open Science for Synthesis: Gulf Research Program Workshop
+ /events/2017_07_oss/
+ Mon, 10 Jul 2017 00:00:00 +0000
+
+ /events/2017_07_oss/
+ Dates: July 10 - July 28, 2017
+Location: Santa Barbara, CA
+Venue: NCEAS, 735 State St., Suite 300, UC Santa Barbara
+The primary goal of the Open Science for Synthesis: Gulf Research Program Workshop is to provide hands-on experience with contemporary open science tools from command line to data to communication. Team science is promoted. Practice and real data are used in groups to apply skills we explore.
+Week 1.
+
+
+
+
\ No newline at end of file
diff --git a/public/post/2015-07-23-r-rmarkdown_files/figure-html/pie-1.png b/public/post/2015-07-23-r-rmarkdown_files/figure-html/pie-1.png
new file mode 100644
index 00000000..0edf78b1
Binary files /dev/null and b/public/post/2015-07-23-r-rmarkdown_files/figure-html/pie-1.png differ
diff --git a/public/search.json b/public/search.json
new file mode 100644
index 00000000..0962b123
--- /dev/null
+++ b/public/search.json
@@ -0,0 +1,415 @@
+[
+ {
+ "objectID": "index.html",
+ "href": "index.html",
+ "title": "NCEAS Open Science Synthesis for the Delta Science Program",
+ "section": "",
+ "text": "Overview"
+ },
+ {
+ "objectID": "index.html#about-this-training",
+ "href": "index.html#about-this-training",
+ "title": "NCEAS Open Science Synthesis for the Delta Science Program",
+ "section": "About this training",
+ "text": "About this training\nNCEAS Open Science Synthesis training consists of three 1-week long workshops, geared towards early career researchers. Participants engage in a mix of lectures, exercises, and synthesis research groups to undertake synthesis while learning and implementing best practices for open data science."
+ },
+ {
+ "objectID": "index.html#why-nceas",
+ "href": "index.html#why-nceas",
+ "title": "NCEAS Open Science Synthesis for the Delta Science Program",
+ "section": "Why NCEAS",
+ "text": "Why NCEAS\nThe National Center for Ecological Analysis and Synthesis (NCEAS), a research affiliate of UCSB, is a leading expert on interdisciplinary data science and works collaboratively to answer the world’s largest and most complex questions. The NCEAS approach leverages existing data and employs a team science philosophy to squeeze out all potential insights and solutions efficiently - this is called synthesis science.\nNCEAS has over 25 years of success with this model among working groups and environmental professionals. Together with the Delta Science Program and the Delta Stewardship Council we are excited to pass along skills, workflows, mindsets learn throughout the years.\n\nWeek 2: Open Tools for Analysis and Visualization\nAug 28 - Sep 1, 2023\n\nStrengthen core knowledge of version control and workflow\nIntroduce metaanalysis concepts and tools\nApproaches for geospatial visualization\nData tools for qualitative data"
+ },
+ {
+ "objectID": "index.html#schedule",
+ "href": "index.html#schedule",
+ "title": "NCEAS Open Science Synthesis for the Delta Science Program",
+ "section": "Schedule",
+ "text": "Schedule\nUPDATE IMAGE WITH WEEK 2 SCHEDULE"
+ },
+ {
+ "objectID": "index.html#next-training",
+ "href": "index.html#next-training",
+ "title": "NCEAS Open Science Synthesis for the Delta Science Program",
+ "section": "Next training",
+ "text": "Next training\n\nWeek 3: Scaling up and presenting synthesis\nOctober 23 – 27, 2023\n\nHandling missing data\nBig data workflows and parallel computing\nBuilding scientific websites with R and Shiny\nSynthesis presentations and next steps"
+ },
+ {
+ "objectID": "index.html#code-of-conduct",
+ "href": "index.html#code-of-conduct",
+ "title": "NCEAS Open Science Synthesis for the Delta Science Program",
+ "section": "Code of Conduct",
+ "text": "Code of Conduct\nBy participating in this activity you agree to abide by the NCEAS Code of Conduct."
+ },
+ {
+ "objectID": "index.html#about-this-book",
+ "href": "index.html#about-this-book",
+ "title": "NCEAS Open Science Synthesis for the Delta Science Program",
+ "section": "About this book",
+ "text": "About this book\nThese written materials are the result of a continuous and collaborative effort at NCEAS with the support of DataONE, to help researchers make their work more transparent and reproducible. This work began in the early 2000’s, and reflects the expertise and diligence of many, many individuals. The primary authors for this version are listed in the citation below, with additional contributors recognized for their role in developing previous iterations of these or similar materials.\nThis work is licensed under a Creative Commons Attribution 4.0 International License.\nCitation: Halina Do-Linh, Carmen Galaz García, Matthew B. Jones, Camila Vargas Poulsen. 2023. Open Science Synthesis training Week 2. NCEAS Learning Hub & Delta Stewardship Council.\nAdditional contributors: Ben Bolker, Julien Brun, Amber E. Budden, Jeanette Clark, Samantha Csik, Stephanie Hampton, Natasha Haycock-Chavez, Samanta Katz, Julie Lowndes, Erin McLean, Bryce Mecum, Deanna Pennington, Karthik Ram, Jim Regetz, Tracy Teal, Daphne Virlar-Knight, Leah Wasser.\nThis is a Quarto book. To learn more about Quarto books visit https://quarto.org/docs/books."
+ },
+ {
+ "objectID": "session_01.html#learning-objectives",
+ "href": "session_01.html#learning-objectives",
+ "title": "1 Collaborating using Git and GitHub & Merge Conflicts",
+ "section": "Learning Objectives",
+ "text": "Learning Objectives\n\nApply the principles, features, and collaboration tools of Git and GitHub to effectively collaborate with colleagues on code\nAnalyze and evaluate common causes of conflicts that arise when collaborating on repositories\nDemonstrate the ability to resolve conflicts using Git conflict resolution techniques\nApply workflows and best practices that minimize conflicts on collaborative repositories"
+ },
+ {
+ "objectID": "session_01.html#introduction-to-git-and-github-tools-for-collaboration",
+ "href": "session_01.html#introduction-to-git-and-github-tools-for-collaboration",
+ "title": "1 Collaborating using Git and GitHub & Merge Conflicts",
+ "section": "1.1 Introduction to Git and GitHub Tools for Collaboration",
+ "text": "1.1 Introduction to Git and GitHub Tools for Collaboration\n\n\n\nArtwork by Allison Horst\n\n\nGit is not only a powerful tool for individual work but also an excellent choice for collaborating with friends and colleagues. Git ensures that after you’ve completed your contributions to a repository, you can confidently synchronize your changes with changes made by others.\nOne of the easiest and most effective ways to collaborate using Git is by utilizing a shared repository on a hosting service like GitHub. This shared repository acts as a central hub, enabling collaborators to effortlessly exchange and merge their changes. With Git and a shared repository, you can collaborate seamlessly and work confidently, knowing that your changes will be integrated smoothly with those of your collaborators.\n\n\n\nGraphic from Atlassian\n\n\nThere are many advanced techniques for synchronizing Git repositories, but let’s start with a simple example.\nIn this example, the Collaborator will clone a copy of the Owner’s repository from GitHub, and the Owner will grant them Collaborator status, enabling the Collaborator to directly pull and push from the Owner’s GitHub repository."
+ },
+ {
+ "objectID": "session_01.html#collaborating-with-a-trusted-colleague-without-conflicts",
+ "href": "session_01.html#collaborating-with-a-trusted-colleague-without-conflicts",
+ "title": "1 Collaborating using Git and GitHub & Merge Conflicts",
+ "section": "1.2 Collaborating with a trusted colleague without conflicts",
+ "text": "1.2 Collaborating with a trusted colleague without conflicts\nWe start our collaboration by giving a trusted colleague access to our repository on GitHub. In this example, we define the Owner as the individual who owns the repository, and the Collaborator as the person whom the Owner chooses to give permission to make changes to their repository.\nThe Collaborator will make changes to the repository and then push those changes to the shared repository on GitHub. The Owner will then use pull to retrieve the changes without encountering any conflicts. This is the most ideal workflow.\nThe instructors will demonstrate this process in the next section.\n\nStep 0: Owner adds Collaborator to shared repository\nThe Owner must change the settings of the repository and give the Collaborator access to the repository by inviting them as a collaborator to the repository. Once the Collaborator has accepted the invite, they can contribute to the repository.\n\n\n\n\n\n\n\nStep 1: Collaborator clone\nTo be able to contribute to a repository, the Collaborator must clone the repository from the Owner’s GitHub account. To do this, the Collaborator should visit the GitHub page for the Owner’s repository, and then copy the clone URL. In R Studio, the Collaborator will create a new project from version control by pasting this clone URL into the appropriate dialog (see the earlier chapter introducing GitHub).\n\n\n\nStep 2: Collaborator edit\nWith a clone copied locally, the Collaborator can now make changes to the README.md file in the repository, adding a line or statement somewhere noticeable near the top. Save your changes.\n\n\nStep 3: Collaborator commit and push\nTo sync changes, the Collaborator will need to add, commit, and push their changes to the Owner’s repository. But before doing so, it’s good practice to pull immediately before committing to ensure you have the most recent changes from the Owner. So, in RStudio’s Git tab, first click the “Diff” button to open the Git window, and then press the green “Pull” down arrow button. This will fetch any recent changes from the origin repository and merge them. Next, add the changed README.Rmd file to be committed by clicking the check box next to it, type in a commit message, and click “Commit”. Once that finishes, then the Collaborator can immediately click “Push” to send the commits to the Owner’s GitHub repository.\n\n\n\n\n\n\n\nStep 4: Owner pull\nNow, the Owner can open their local working copy of the code in RStudio, and pull those changes down to their local copy.\nCongrats, the Owner now has your changes!\n\n\nStep 5: Owner edits, commit, and push\nNext, the Owner should do the same. Make changes to a file in the repository, save it, pull to make sure no new changes have been made while editing, and then add, commit, and push the Owner changes to GitHub.\n\n\nStep 6: Collaborator pull\nThe Collaborator can now pull down those Owner changes, and all copies are once again fully synced. And you’re off to collaborating."
+ },
+ {
+ "objectID": "session_01.html#ex1-no-conflict",
+ "href": "session_01.html#ex1-no-conflict",
+ "title": "1 Collaborating using Git and GitHub & Merge Conflicts",
+ "section": "1.3 Exercise 1: With a partner collaborate in a repository without a merge conflict",
+ "text": "1.3 Exercise 1: With a partner collaborate in a repository without a merge conflict\n\n\n\n\n\n\nSetup\n\n\n\n\nGet into pairs, then choose one person as the Owner and one as the Collaborator\nBoth logon to GitHub\n\nThese next steps are for the Owner:\n\nNavigate to the {FIRSTNAME}_test repository\nGo to “Settings” and navigate to “Collaborators” in the “Access” section on the left-hand side\nUnder “Manage Access” click the button “Add people” and type the username of your Collaborator in the search box\nOnce you’ve found the correct username, click “Add {Collaborator username} to this repository\n\n\n\n\n\n\nNow, the Collaborator will follow this step:\n\nCheck your email for an invitation to GitHub or check your notifications (likely under “Your Organizations”) on GitHub to accept the invite to collaborate.\n\n\n\n\n\n\n\n\n\nLast thing, some Git configuration\n\n\n\nWhen Git released version 2.27, a new feature they incorporated allows users to specify how to pull, essentially, otherwise a warning will appear. To suppress this warning we need to configure our Git with this line of code:\ngit config pull.rebase false\npull.rebase false is a default strategy for pulling where it will try to auto-merge the files if possible, and if it can’t it will show a merge conflict\n\n\n\n\n\n\n\n\nInstructions\n\n\n\nYou will do the exercise twice, where each person will get to practice being both the Owner and the Collaborator roles.\n\nStep 0: Designate one person as the Owner and one as the Collaborator.\n\nRound One:\n\nStep 1: Owner adds Collaborator to {FIRSTNAME}_test repository (see Setup block above for detailed steps)\nStep 2: Collaborator clones the Owner’s {FIRSTNAME}_test repository\nStep 3: Collaborator edits the README file:\n\nCollaborator adds a new level 2 heading to README titled “Git Workflow”\n\nStep 4: Collaborator commits and pushes the README file with the new changes to GitHub\nStep 5: Owner pulls the changes that the Collaborator made\nStep 6: Owner edits the README file:\n\nUnder “Git Workflow”, Owner adds the steps of the Git workflow we’ve been practicing\n\nStep 7: Owner commits and pushes the README file with the new changes to GitHub\nStep 8: Collaborator pulls the Owners changes from GitHub\nStep 9: Go back to Step 0, switch roles, and then follow the steps in Round Two.\n\nRound Two:\n\nStep 1: Owner adds Collaborator to {FIRSTNAME}_test repository\nStep 2: Collaborator clones the Owner’s {FIRSTNAME}_test repository\nStep 3: Collaborator edits the README file:\n\nCollaborator adds a new level 2 heading to README titled “How to Create a Git Repository from an existing project” and adds the high level steps for this workflow\n\nStep 4: Collaborator commits and pushes the README file with the new changes to GitHub\nStep 5: Owner pulls the changes that the Collaborator made\nStep 6: Owner edits the README file:\n\nUnder “How to Create a Git Repository”, Owner adds the high level steps for this workflow\n\nStep 7: Owner commits and pushes the README file with the new changes to GitHub\nStep 8: Collaborator pulls the Owners changes from GitHub\n\nHint: If you don’t remember how to create a Git repository, refer to the chapter Intro to Git and GitHub where we created two Git repositories"
+ },
+ {
+ "objectID": "session_01.html#a-note-on-advanced-collaboration-techniques",
+ "href": "session_01.html#a-note-on-advanced-collaboration-techniques",
+ "title": "1 Collaborating using Git and GitHub & Merge Conflicts",
+ "section": "1.4 A Note on Advanced Collaboration Techniques",
+ "text": "1.4 A Note on Advanced Collaboration Techniques\nThere are many Git and GitHub collaboration techniques, some more advanced than others. We won’t be covering advanced strategies in this course. But here is a table for your reference on a few popular Git collaboration workflow strategies and tools.\n\n\n\n\n\n\n\n\n\nCollaboration Technique\nBenefits\nWhen to Use\nWhen Not to Use\n\n\n\n\nBranch Management Strategies\n1. Enables parallel development and experimentation2. Facilitates isolation of features or bug fixes3. Provides flexibility and control over project workflows\nWhen working on larger projects with multiple features or bug fixes simultaneously.When you want to maintain a stable main branch while developing new features or resolving issues on separate branches.When collaborating with teammates on different aspects of a project and later integrating their changes.\nWhen working on small projects with a single developer or limited codebase.When the project scope is simple and doesn’t require extensive branch management.When there is no need to isolate features or bug fixes.\n\n\nCode Review Practices\n1. Enhances code quality and correctness through feedback2. Promotes knowledge sharing and learning within the team3. Helps identify bugs, improve performance, and ensure adherence to coding standards\nWhen collaborating on a codebase with team members to ensure code quality and maintain best practices.When you want to receive feedback and suggestions on your code to improve its readability, efficiency, or functionality.When working on critical or complex code that requires an extra layer of scrutiny before merging it into the main branch.\nWhen working on personal projects or small codebases with no collaboration involved.When time constraints or project size make it impractical to conduct code reviews.When the codebase is less critical or has low complexity.\n\n\nForking\n1. Enables independent experimentation and development2. Provides a way to contribute to a project without direct access3. Allows for creating separate, standalone copies of a repository\nWhen you want to contribute to a project without having direct write access to the original repository.When you want to work on an independent variation or extension of an existing project.When experimenting with changes or modifications to a project while keeping the original repository intact.\nWhen collaborating on a project with direct write access to the original repository.When the project does not allow external contributions or forking.When the project size or complexity doesn’t justify the need for independent variations.\n\n\nPull Requests\n1. Facilitates code review and discussion2. Allows for collaboration and feedback from team members3. Enables better organization and tracking of proposed changes\nWhen working on a shared repository with a team and wanting to contribute changes in a controlled and collaborative manner.When you want to propose changes to a project managed by others and seek review and approval before merging them into the main codebase.\nWhen working on personal projects or individual coding tasks without the need for collaboration.When immediate changes or fixes are required without review processes.When working on projects with a small team or single developer with direct write access to the repository.\n\n\n\nThe “When Not to Use” column provides insights into situations where it may be less appropriate to use each collaboration technique, helping you make informed decisions based on the specific context and requirements of your project.\nThese techniques provide different benefits and are used in various collaboration scenarios, depending on the project’s needs and team dynamics."
+ },
+ {
+ "objectID": "session_01.html#merge-conflicts",
+ "href": "session_01.html#merge-conflicts",
+ "title": "1 Collaborating using Git and GitHub & Merge Conflicts",
+ "section": "1.5 Merge conflicts",
+ "text": "1.5 Merge conflicts\nMerge conflicts occur when both collaborators make conflicting changes to the same file. Resolving merge conflicts involves identifying the root of the problem and restoring the project to a normal state. Good communication, discussing file sections to work on, and avoiding overlaps can help prevent merge conflicts. However, if conflicts do arise, Git warns about potential issues and ensures that changes from different collaborators based on the same file version are not overwritten. To resolve conflicts, you need to explicitly specify whose changes should be used for each conflicting line in the file.\nIn this image, we see collaborators mbjones and metamattj have both made changes to the same line in the same README.md file. This is causing a merge conflict because Git doesn’t know whose changes came first. To resolve it, we need to tell Git whose changes to keep for that line, and whose changes to discard.\n\n\n1.5.1 Common ways to resolve a merge conflict\n1. Abort, abort, abort…\nSometimes you just made a mistake. When you get a merge conflict, the repository is placed in a “Merging” state until you resolve it. There’s a Terminal command to abort doing the merge altogether:\ngit merge --abort\nOf course, after doing that you still haven’t synced with your Collaborator’s changes, so things are still unresolved. But at least your repository is now usable on your local machine.\n2. Checkout\nThe simplest way to resolve a conflict, given that you know whose version of the file you want to keep, is to use the command line Git program to tell Git to use either your changes (the person doing the merge), or their changes (the Collaborator).\n\nkeep your Collaborator’s file: git checkout --theirs conflicted_file.Rmd\nkeep your own file: git checkout --ours conflicted_file.Rmd\n\nOnce you have run that command, then run add (staging), commit, pull, and push the changes as normal.\n3. Pull and edit the file\nBut that requires the command line. If you want to resolve from RStudio, or if you want to pick and choose some of your changes and some of your Collaborator’s, then instead you can manually edit and fix the file. When you pull the file with a conflict, Git notices that there is a conflict and modifies the file to show both your own changes and your Collaborator’s changes in the file. It also shows the file in the Git tab with an orange U icon, which indicates that the file is Unmerged, and therefore awaiting your help to resolve the conflict. It delimits these blocks with a series of less than and greater than signs, so they are easy to find:\n\n\n\n\n\nTo resolve the conflicts, simply find all of these blocks, and edit them so that the file looks how you want (either pick your lines, your Collaborator’s lines, some combination, or something altogether new), and save. Be sure you removed the delimiter lines that started with\n\n<<<<<<<,\n=======,\nand >>>>>>>.\n\nOnce you have made those changes, you simply add (staging), commit, and push the files to resolve the conflict."
+ },
+ {
+ "objectID": "session_01.html#producing-and-resolving-merge-conflicts",
+ "href": "session_01.html#producing-and-resolving-merge-conflicts",
+ "title": "1 Collaborating using Git and GitHub & Merge Conflicts",
+ "section": "1.6 Producing and resolving merge conflicts",
+ "text": "1.6 Producing and resolving merge conflicts\nTo illustrate this process, the instructors are going to carefully create a merge conflict step by step, show how to resolve it, and show how to see the results of the successful merge after it is complete. First, the instructors will walk through the exercise to demonstrate the issues. Then, participants will pair up and try the exercise.\n\nStep 1: Owner and Collaborator ensure all changes are updated\nFirst, start the exercise by ensuring that both the Owner and Collaborator have all of the changes synced to their local copies of the Owner’s repository in RStudio. This includes doing a git pull to ensure that you have all changes local, and make sure that the Git tab in RStudio doesn’t show any changes needing to be committed.\n\n\nStep 2: Owner makes a change and commits\nFrom that clean slate, the Owner first modifies and commits a small change including their name on a specific line of the README.md file (we will change the first line, the title). Work to only change that one line, and add your username to the line in some form and commit the changes (but DO NOT push). We are now in a situation where the Owner has unpushed changes that the Collaborator can not yet see.\n\n\nStep 3: Collaborator makes a change and commits on the same line\nNow the Collaborator also makes changes to the same line (the first line, the title) on the README.md file in their RStudio copy of the project, adding their name to the line. They then commit. At this point, both the Owner and Collaborator have committed changes based on their shared version of the README.md file, but neither has tried to share their changes via GitHub.\n\n\nStep 4: Collaborator pushes the file to GitHub\nSharing starts when the Collaborator pushes their changes to the GitHub repo, which updates GitHub to their version of the file. The Owner is now one revision behind, but doesn’t know it yet.\n\n\nStep 5: Owner pushes their changes and gets an error\nAt this point, the Owner tries to push their change to the repository, which triggers an error from GitHub. While the error message is long, it basically tells you everything needed (that the Owner’s repository doesn’t reflect the changes on GitHub, and that they need to pull before they can push).\n\n\n\nStep 6: Owner pulls from GitHub to get Collaborator changes\nDoing what the message says, the Owner pulls the changes from GitHub, and gets another, different error message. In this case, it indicates that there is a merge conflict because of the conflicting lines.\n\nIn the Git pane of RStudio, the file is also flagged with an orange U, which stands for an unresolved merge conflict.\n\n\n\nStep 7: Owner edits the file to resolve the conflict\nTo resolve the conflict, the Owner now needs to edit the file. Again, as indicated above, Git has flagged the locations in the file where a conflict occurred with <<<<<<<, =======, and >>>>>>>. The Owner should edit the file, merging whatever changes are appropriate until the conflicting lines read how they should, and eliminate all of the marker lines with <<<<<<<, =======, and >>>>>>>.\n\nOf course, for scripts and programs, resolving the changes means more than just merging the text – whoever is doing the merging should make sure that the code runs properly and none of the logic of the program has been broken.\n\n\n\nStep 8: Owner commits the resolved changes\nFrom this point forward, things proceed as normal. The Owner first add the file changes to be made, which changes the orange U to a blue M for modified, and then commits the changes locally. The Owner now has a resolved version of the file on their system.\n\n\n\nStep 9: Owner pushes the resolved changes to GitHub\nHave the Owner push the changes, and it should replicate the changes to GitHub without error.\n\n\n\nStep 10: Collaborator pulls the resolved changes from GitHub\nFinally, the Collaborator can pull from GitHub to get the changes the Owner made.\n\n\nStep 11: Both can view commit history\nWhen either the Collaborator or the Owner view the history, the conflict, associated branch, and the merged changes are clearly visible in the history."
+ },
+ {
+ "objectID": "session_01.html#exercise-2-with-a-partner-collaborate-in-a-repository-and-resolve-a-merge-conflict",
+ "href": "session_01.html#exercise-2-with-a-partner-collaborate-in-a-repository-and-resolve-a-merge-conflict",
+ "title": "1 Collaborating using Git and GitHub & Merge Conflicts",
+ "section": "1.7 Exercise 2: With a partner collaborate in a repository and resolve a merge conflict",
+ "text": "1.7 Exercise 2: With a partner collaborate in a repository and resolve a merge conflict\nNote you will only need to complete the Setup and Git configuration steps again if you are working in a new repository. Return to Exercise 1 for Setup and Git configuration steps.\n\n\n\n\n\n\nInstructions\n\n\n\nNow it’s your turn. In pairs, intentionally create a merge conflict, and then go through the steps needed to resolve the issues and continue developing with the merged files. See the sections above for help with each of the steps below. You will do the exercise twice, where each person will get to practice being both the Owner and the Collaborator roles.\n\nStep 0: Designate one person as the Owner and one as the Collaborator.\n\nRound One:\n\nStep 1: Both Owner and Collaborator pull to ensure both have the most up-to-date changes\nStep 2: Owner edits the README file and makes a change to the title and commits do not push\nStep 3: On the same line, Collaborator edits the README file and makes a change to the title and commits\nStep 4: Collaborator pushes the file to GitHub\nStep 5: Owner pushes their changes and gets an error\nStep 6: Owner pulls from GitHub to get Collaborator changes\nStep 7: Owner edits the README file to resolve the conflict\nStep 8: Owner commits the resolved changes\nStep 9: Owner pushes the resolved changes to GitHub\nStep 10: Collaborator pulls the resolved changes from GitHub\nStep 11: Both view commit history\nStep 12: Go back to Step 0, switch roles, and then follow the steps in Round Two.\n\nRound Two:\n\nStep 1: Both Owner and Collaborator pull to ensure both have the most up-to-date changes\nStep 2: Owner edits the README file and makes a change to line 2 and commits do not push\nStep 3: On the same line, Collaborator edits the README file and makes a change to line 2 and commits\nStep 4: Collaborator pushes the file to GitHub\nStep 5: Owner pushes their changes and gets an error\nStep 6: Owner pulls from GitHub to get Collaborator changes\nStep 7: Owner edits the README file to resolve the conflict\nStep 8: Owner commits the resolved changes\nStep 9: Owner pushes the resolved changes to GitHub\nStep 10: Collaborator pulls the resolved changes from GitHub\nStep 11: Both view commit history"
+ },
+ {
+ "objectID": "session_01.html#best-practices-to-avoid-merge-conflicts",
+ "href": "session_01.html#best-practices-to-avoid-merge-conflicts",
+ "title": "1 Collaborating using Git and GitHub & Merge Conflicts",
+ "section": "1.8 Best practices to avoid merge conflicts",
+ "text": "1.8 Best practices to avoid merge conflicts\nSome basic rules of thumb can avoid the vast majority of merge conflicts, saving a lot of time and frustration. These are words our teams live by:\n\n\n\n\n\nXKCD 1597\n\n\n\nCommunicate often and set up effective communication channels\nTell each other what you are working on\nStart your working session with a pull\nPull immediately before you commit or push\nCommit often in small chunks (this helps you organize your work!)\nMake sure you and who you are collaborating with all fully understand the Git workflow you’re using aka make sure you’re on the same page before you start!\n\nA good workflow is encapsulated as follows:\nPull -> Edit -> Save -> Add (stage) -> Commit -> Pull -> Push\nAlways start your working sessions with a pull to get any outstanding changes, then start your work. Stage your changes, but before you commit, pull again to see if any new changes have arrived. If so, they should merge in easily if you are working in different parts of the program. You can then commit and immediately push your changes safely.\nGood luck, and try to not get frustrated. Once you figure out how to handle merge conflicts, they can be avoided or dispatched when they occur, but it does take a bit of practice."
+ },
+ {
+ "objectID": "session_02.html#developing-a-code-of-conduct",
+ "href": "session_02.html#developing-a-code-of-conduct",
+ "title": "2 Social Aspects of Collaboration",
+ "section": "2.1 Developing a Code of Conduct",
+ "text": "2.1 Developing a Code of Conduct\nWhether you are joining a lab group or establishing a new collaboration, articulating a set of shared agreements about how people in the group will treat each other will help create the conditions for successful collaboration. If agreements or a code of conduct do not yet exist, invite a conversation among all members to create them. Co-creation of a code of conduct will foster collaboration and engagement as a process in and of itself, and is important to ensure all voices heard such that your code of conduct represents the perspectives of your community. If a code of conduct already exists, and your community will be a long-acting collaboration, you might consider revising the code of conduct. Having your group ‘sign off’ on the code of conduct, whether revised or not, supports adoption of the principles.\nWhen creating a code of conduct, consider both the behaviors you want to encourage and those that will not be tolerated. For example, the Openscapes code of conduct includes Be respectful, honest, inclusive, accommodating, appreciative, and open to learning from everyone else. Do not attack, demean, disrupt, harass, or threaten others or encourage such behavior.\nBelow are other example codes of conduct:\n\nNCEAS Code of Conduct\nCarpentries Code of Conduct\nArctic Data Center Code of Conduct\nMozilla Community Participation Guidelines\nEcological Society of America Code of Conduct"
+ },
+ {
+ "objectID": "session_02.html#authorship-and-credit-policies",
+ "href": "session_02.html#authorship-and-credit-policies",
+ "title": "2 Social Aspects of Collaboration",
+ "section": "2.2 Authorship and Credit Policies",
+ "text": "2.2 Authorship and Credit Policies\n\nNavigating issues of intellectual property and credit can be a challenge, particularly for early career researchers. Open communication is critical to avoiding misunderstandings and conflicts. Talk to your coauthors and collaborators about authorship, credit, and data sharing early and often. This is particularly important when working with new collaborators and across lab groups or disciplines which may have divergent views on authorship and data sharing. If you feel uncomfortable talking about issues surrounding credit or intellectual property, seek the advice or assistance of a mentor to support you in having these important conversations.\nThe “Publication” section of the Ecological Society of America’s Code of Ethics is a useful starting point for discussions about co-authorship, as are the International Committee of Medical Journal Editors guidelines for authorship and contribution. You should also check guidelines published by the journal(s) to which you anticipate submitting your work.\nFor collaborative research projects, develop an authorship agreement for your group early in the project and refer to it for each product. This example authorship agreement from the Arctic Data Center provides a useful template. It builds from information contained within Weltzin et al (2006) and provides a rubric for inclusion of individuals as authors. Your collaborative team may not choose to adopt the agreement in the current form, however it will prompt thought and discussion in advance of developing a consensus. Some key questions to consider as you are working with your team to develop the agreement:\n\nWhat roles do we anticipate contributors will play? e.g., the NISO Contributor Roles Taxonomy (CRediT) identifies 14 distinct roles:\n\nConceptualization\nData curation\nFormal Analysis\nFunding acquisition\nInvestigation\nMethodology\nProject administration\nResources\nSoftware\nSupervision\nValidation\nVisualization\nWriting – original draft\nWriting – review & editing\n\nWhat are our criteria for authorship? (See the ICMJE guidelines for potential criteria)\nWill we extend the opportunity for authorship to all group members on every paper or product?\nDo we want to have an opt in or opt out policy? (In an opt out policy, all group members are considered authors from the outset and must request removal from the paper if they don’t want think they meet the criteria for authorship)\nWho has the authority to make decisions about authorship? Lead author? PI? Group?\nHow will we decide authorship order?\nIn what other ways will we acknowledge contributions and extend credit to collaborators?\nHow will we resolve conflicts if they arise?"
+ },
+ {
+ "objectID": "session_02.html#data-sharing-and-reuse-policies",
+ "href": "session_02.html#data-sharing-and-reuse-policies",
+ "title": "2 Social Aspects of Collaboration",
+ "section": "2.3 Data Sharing and Reuse Policies",
+ "text": "2.3 Data Sharing and Reuse Policies\nAs with authorship agreements, it is valuable to establish a shared agreement around handling of data when embarking on collaborative projects. Data collected as part of a funded research activity will typically have been managed as part of the Data Management Plan (DMP) associated with that project. However, collaborative research brings together data from across research projects with different data management plans and can include publicly accessible data from repositories where no management plan is available. For these reasons, a discussion and agreement around the handling of data brought into and resulting from the collaboration is warranted and management of this new data may benefit from going through a data management planning process. Below we discuss example data agreements.\nThe example data policy template provided by the Arctic Data Center addresses three categories of data.\n\nIndividual data not in the public domain\nIndividual data with public access\nDerived data resulting from the project\n\nFor the first category, the agreement considers conditions under which those data may be used and permissions associated with use. It also addresses access and sharing. In the case of individual, publicly accessible data, the agreement stipulates that the team will abide by the attribution and usage policies that the data were published under, noting how those requirements we met. In the case of derived data, the agreement reads similar to a DMP with consideration of making the data public; management, documentation and archiving; pre-publication sharing; and public sharing and attribution. As research data objects receive a persistent identifier (PID), often a DOI, there are citable objects and consideration should be given to authorship of data, as with articles.\nThe following example lab policy from the Wolkovich Lab combines data management practices with authorship guidelines and data sharing agreements. It provides a lot of detail about how this lab approaches data use, attribution and authorship. For example:\n\nSection 6: Co-authorship & data\nIf you agree to take on existing data you cannot offer co-authorship for use of the data unless four criteria are met:\n\nThe co-author agrees to (and does) make substantial intellectual contribution to the work, which includes the reading and editing of all manuscripts on which you are a co-author through the submission-for-publication stage. This includes helping with interpretation of the data, system, study questions.\nAgreement of co-authorship is made at the start of the project.\nAgreement is approved of by Lizzie.\nAll data-sharers are given an equal opportunity at authorship. It is not allowed to offer or give authorship to one data-sharer unless all other data-sharers are offered an equal opportunity at authorship—this includes data that are publicly-available, meaning if you offer authorship to one data-sharer and were planning to use publicly-available data you must reach out to the owner of the publicly-available data and strongly offer equivalent authorship as offered to the other data-sharer. As an example, if five people share data freely with you for a meta-analysis and and a sixth wants authorship you either must strongly offer equivalent authorship to all five or deny authorship to the sixth person. Note that the above requirements must also be met in this situation. If one or more datasets are more central or critical to a paper to warrant selective authorship this must be discussed and approved by Lizzie (and has not, to date, occurred within the lab).\n\n\n\n\n\n\n2.3.0.1 Policy Preview\n\n\nThis policy is communicated with all incoming lab members, from undergraduate to postdocs and visiting scholars, and is shared here with permission from Dr Elizabeth Wolkovich.\n\n\n2.3.1 Community Principles: CARE and FAIR\nThe CARE and FAIR Principles were introduced previously in the context of introducing the Arctic Data Center and our data submission and documentation process. In this section we will dive a little deeper.\nTo recap, the Arctic Data Center is an openly-accessible data repository and the data published through the repository is open for anyone to reuse, subject to conditions of the license (at the Arctic Data Center, data is released under one of two licenses: CC-0 Public Domain and CC-By Attribution 4.0). In facilitating use of data resources, the data stewardship community have converged on principles surrounding best practices for open data management One set of these principles is the FAIR principles. FAIR stands for Findable, Accessible, Interoperable, and Reproducible.\n\nThe “Fostering FAIR Data Practices in Europe” project found that it is more monetarily and timely expensive when FAIR principles are not used, and it was estimated that 10.2 billion dollars per years are spent through “storage and license costs to more qualitative costs related to the time spent by researchers on creation, collection and management of data, and the risks of research duplication.” FAIR principles and open science are overlapping concepts, but are distinctive concepts. Open science supports a culture of sharing research outputs and data, and FAIR focuses on how to prepare the data.\n\nAnother set of community developed principles surrounding open data are the CARE Principles. The CARE principles for Indigenous Data Governance complement the more data-centric approach of the FAIR principles, introducing social responsibility to open data management practices. The CARE Principles stand for:\n\nCollective Benefit - Data ecosystems shall be designed and function in ways that enable Indigenous Peoples to derive benefit from the data\nAuthority to Control - Indigenous Peoples’ rights and interests in Indigenous data must be recognised and their authority to control such data be empowered. Indigenous data governance enables Indigenous Peoples and governing bodies to determine how Indigenous Peoples, as well as Indigenous lands, territories, resources, knowledges and geographical indicators, are represented and identified within data.\nResponsibility - Those working with Indigenous data have a responsibility to share how those data are used to support Indigenous Peoples’ self-determination and collective benefit. Accountability requires meaningful and openly available evidence of these efforts and the benefits accruing to Indigenous Peoples.\nEthics - Indigenous Peoples’ rights and wellbeing should be the primary concern at all stages of the data life cycle and across the data ecosystem.\n\nThe CARE principles align with the FAIR principles by outlining guidelines for publishing data that is findable, accessible, interoperable, and reproducible while at the same time, accounts for Indigenous’ Peoples rights and interests. Initially designed to support Indigenous data sovereignty, CARE principles are now being adopted across domains, and many researchers argue they are relevant for both Indigenous Knowledge and data, as well as data from all disciplines (Carroll et al., 2021). These principles introduce a “game changing perspective” that encourages transparency in data ethics, and encourages data reuse that is purposeful and intentional that aligns with human well-being aligns with human well-being (Carroll et al., 2021)."
+ },
+ {
+ "objectID": "session_02.html#research-data-publishing-ethics",
+ "href": "session_02.html#research-data-publishing-ethics",
+ "title": "2 Social Aspects of Collaboration",
+ "section": "2.4 Research Data Publishing Ethics",
+ "text": "2.4 Research Data Publishing Ethics\nFor over 20 years, the Committee on Publication Ethics (COPE) has provided trusted guidance on ethical practices for scholarly publishing. The COPE guidelines have been broadly adopted by academic publishers across disciplines, and represent a common approach to identify, classify, and adjudicate potential breaches of ethics in publication such as authorship conflicts, peer review manipulation, and falsified findings, among many other areas. Despite these guidelines, there has been a lack of ethics standards, guidelines, or recommendations for data publications, even while some groups have begun to evaluate and act upon reported issues in data publication ethics.\n\n\n\nData retractions\n\n\nTo address this gap, the Force 11 Working Group on Research Data Publishing Ethics was formed as a collaboration among research data professionals and the Committee on Publication Ethics (COPE) “to develop industry-leading guidance and recommended best practices to support repositories, journal publishers, and institutions in handling the ethical responsibilities associated with publishing research data.” The group released the “Joint FORCE11 & COPE Research Data Publishing Ethics Working Group Recommendations” (Puebla, Lowenberg, and WG 2021), which outlines recommendations for four categories of potential data ethics issues:\n\n\n\nForce11/COPE\n\n\n\nAuthorship and Contribution Conflicts\n\nAuthorship omissions\nAuthorship ordering changes / conflicts\nInstitutional investigation of author finds misconduct\n\nLegal/regulatory restrictions\n\nCopyright violation\nInsufficient rights for deposit\nBreaches of national privacy laws (GPDR, CCPA)\nBreaches of biosafety and biosecurity protocols\nBreaches of contract law governing data redistribution\n\nRisks of publication or release\n\nRisks to human subjects\n\nLack of consent\nBreaches of himan rights\nRelease of personally identifiable information (PII)\n\nRisks to species, ecosystems, historical sites\n\nLocations of endangered species or historical sites\n\nRisks to communities or societies\n\nData harvested for profit or surveillance\nBreaches of data sovereignty\n\n\nRigor of published data\n\nUnintentional errors in collection, calculation, display\nUn-interpretable data due to lack of adequate documentation\nErrors of of study design and inference\nData manipulation or fabrication\n\n\nGuidelines cover what actions need to be taken, depending on whether the data are already published or not, as well as who should be involved in decisions, who should be notified of actions, and when the public should be notified. The group has also published templates for use by publishers and repositories to announce the extent to which they plan to conform to the data ethics guidelines.\n\nDiscussion: Data publishing policies\nAt the Arctic Data Center, we need to develop policies and procedures governing how we react to potential breaches of data publication ethics. In this exercise, break into groups to provide advice on how the Arctic Data Center should respond to reports of data ethics issues, and whether we should adopt the Joint FORCE11 & COPE Research Data Publishing Ethics Working Group Policy Templates for repositories. In your discussion, consider:\n\nShould the repository adopt the repository policy templates from Force11?\nWho should be involved in evaluation of the merits of ethical cases reported to ADC?\nWho should be involved in deciding the actions to take?\nWhat are the range of responses that the repository should consider for ethical breaches?\nWho should be notified when a determination has been made that a breach has occurred?\n\nYou might consider a hypothetical scenario such as the following in considering your response.\n\nThe data coordinator at the Arctic Data Center receives an email in 2022 from a prior postdoctoral fellow who was employed as part of an NSF-funded project on microbial diversity in Alaskan tundra ecosystems. The email states that a dataset from 2014 in the Arctic Data Center was published with the project PI as author, but omits two people, the postdoc and an undergraduate student, as co-authors on the dataset. The PI retired in 2019, and the postdoc asks that they be added to the author list of the dataset to correct the historical record and provide credit."
+ },
+ {
+ "objectID": "session_02.html#extra-reading",
+ "href": "session_02.html#extra-reading",
+ "title": "2 Social Aspects of Collaboration",
+ "section": "2.5 Extra Reading",
+ "text": "2.5 Extra Reading\n\nCheruvelil, K. S., Soranno, P. A., Weathers, K. C., Hanson, P. C., Goring, S. J., Filstrup, C. T., & Read, E. K. (2014). Creating and maintaining high-performing collaborative research teams: The importance of diversity and interpersonal skills. Frontiers in Ecology and the Environment, 12(1), 31-38. DOI: 10.1890/130001\nCarroll, S. R., Garba, I., Figueroa-Rodríguez, O. L., Holbrook, J., Lovett, R., Materechera, S., … Hudson, M. (2020). The CARE Principles for Indigenous Data Governance. Data Science Journal, 19(1), 43. DOI: http://doi.org/10.5334/dsj-2020-043\n\n\n\n\n\nPuebla, Iratxe, Daniella Lowenberg, and FORCE11 Research Data Publishing Ethics WG. 2021. “Joint FORCE11 & COPE Research Data Publishing Ethics Working Group Recommendations.” Zenodo. https://doi.org/10.5281/zenodo.5391293."
+ },
+ {
+ "objectID": "session_03.html",
+ "href": "session_03.html",
+ "title": "3 Thinking Preferences",
+ "section": "",
+ "text": "INSERT ONE OF THE THIKING PREFERENCES VERSIONS"
+ },
+ {
+ "objectID": "session_05.html#learning-objectives",
+ "href": "session_05.html#learning-objectives",
+ "title": "5 Publishing your Analysis to the Web",
+ "section": "Learning Objectives",
+ "text": "Learning Objectives\n\nHow to use Git, GitHub (+Pages), and R Markdown to publish an analysis to the web"
+ },
+ {
+ "objectID": "session_05.html#introduction",
+ "href": "session_05.html#introduction",
+ "title": "5 Publishing your Analysis to the Web",
+ "section": "5.1 Introduction",
+ "text": "5.1 Introduction\nSharing your work with others in engaging ways is an important part of the scientific process.\nSo far in this course, we’ve introduced a small set of powerful tools for doing open science:\n\nR and its many packages\nRStudio\nGit\nGitHub\nR Markdown\n\nR Markdown, in particular, is amazingly powerful for creating scientific reports but, so far, we haven’t tapped its full potential for sharing our work with others.\nIn this lesson, we’re going to take our training_{USERNAME} GitHub repository and turn it into a beautiful and easy to read web page using the tools listed above.\n\n\n\n\n\n\nSet up\n\n\n\n\nMake sure you are in training_{USERNAME} project\nAdd a new R Markdown file at the top level called index.Rmd\n\nGo to the RStudio menu File > New File > R Markdown\nThis will bring up a dialog box. Add the title “GitHub Pages Example”, keep the Default Output Format as “HTML”, and then click “OK”\n\nSave the R Markdown file you just created. Use index.Rmd as the file name\n\nBe sure to use the exact case (lower case ‘index’) as different operating systems handle case differently and it can interfere with loading your web page later\n\nPress “Knit” and observe the rendered output\n\nNotice the new file in the same directory index.html\nThis is our R Markdown file rendered as HTML (a web page)\n\nCommit your changes (for both index.Rmd and index.html) with a commit message, and push to GitHub\nOpen your web browser to the GitHub.com and navigate to the page for your training_{USERNAME} repository\nActivate GitHub Pages for the main branch\n\nGo to Settings > Pages (underneath the Code and Automation section)\nKeep the “Source” as “Deploy from a branch”\nUnder “Branch” you’ll see a message that says “GitHub Pages is currently disabled”. To change this, change the branch from “None” to main. Keep the folder as the root and then click “Save”\nYou should see the message change to “Your GitHub Pages site is currently being built from the main branch”\n\n\nNote: index.Rmd represents the default file for a web site, and is returned whenever you visit the web site but doesn’t specify an explicit file to be returned.\n\n\nNow, the rendered website version of your repo will show up at a special URL.\nGitHub Pages follows a convention like this:\n\nNote that it changes from github.com to github.io\n\nGo to https://{username}.github.io/{repo_name}/ (Note the trailing /)\nObserve the awesome rendered output\n\nNow that we’ve successfully published a web page from an R Markdown document, let’s make a change to our R Markdown document and follow the steps to publish the change on the web:\n\n\n\n\n\n\nUpdate content in your published page\n\n\n\n\nGo back to your index.Rmd\nDelete all the content, except the YAML frontmatter\nType “Hello world”\nUse Git workflow: Stage > Commit > Pull > Push\nGo back to https://{username}.github.io/{repo_name}/\n\n\n\nNext, we will show how you can link different Rmds rendered into html so you can easily share different parts of your work.\n\n\n\n\n\n\nExercise\n\n\n\nIn this exercise, you’ll create a table of contents with the lessons of this course on the main page, and link some of the files we have work on so far.\n\nGo back to the RStudio server and to your index.Rmd file\nCreate a table of contents with the names of the main technical lessons of this course, like so:\n\n## coreR workshop\n\n- Introduction to RMarkdown \n- Cleaning and Wrangling data\n- Data Visualization\n- Spatial Analysis\n\nMake sure you have the html versions of your intro-to-rmd.Rmd and data-cleaning.Rmd files. If you only see the Rmd version, you need to “Knit” your files first\nIn your index.Rmd let’s add the links to the html files we want to show on our webpage. Do you remember the Markdown syntax to create a link?\n\n\n\nMarkdown syntax to create a link:\n\n\n[Text you want to hyperlink](link)\n\nExample: [Data wrangling and cleaning](data-wrangling-cleaning.html)\n\n\n\n\nUse Git workflow: Stage > Commit > Pull > Push\n\nNow when you visit your web site, you’ll see the table of contents, and can navigate to the others file you linked.\n\n\nR Markdown web pages are a great way to share work in progress with your colleagues. Here we showed an example with the materials we have created in this course. However, you can use these same steps to share the different files and progress of a project you’ve been working on. To do so simply requires thinking through your presentation so that it highlights the workflow to be reviewed. You can include multiple pages and build a simple web site and make your work accessible to people who aren’t set up to open your project in R. Your site could look something like this:"
+ },
+ {
+ "objectID": "session_06.html#learning-objectives",
+ "href": "session_06.html#learning-objectives",
+ "title": "6 Data Visualization in R",
+ "section": "Learning Objectives",
+ "text": "Learning Objectives\n\nThe basics of the ggplot2 package to create static plots\nHow to use ggplot2’s theme abilities to create publication-grade graphics\nThe basics of the leaflet package to create interactive maps"
+ },
+ {
+ "objectID": "session_06.html#overview",
+ "href": "session_06.html#overview",
+ "title": "6 Data Visualization in R",
+ "section": "6.1 Overview",
+ "text": "6.1 Overview\nggplot2 is a popular package for visualizing data in R. From the home page:\n\nggplot2 is a system for declaratively creating graphics, based on The Grammar of Graphics. You provide the data, tell ggplot2 how to map variables to aesthetics, what graphical primitives to use, and it takes care of the details.\n\nIt’s been around for years and has pretty good documentation and tons of example code around the web (like on StackOverflow). The goal of this lesson is to introduce you to the basic components of working with ggplot2 and inspire you to go and explore this awesome resource for visualizing your data.\n\n\n\n\n\n\nggplot2 vs base graphics in R vs others\n\n\n\nThere are many different ways to plot your data in R. All of them work! However, ggplot2 excels at making complicated plots easy and easy plots simple enough\nBase R graphics (plot(), hist(), etc) can be helpful for simple, quick and dirty plots. ggplot2 can be used for almost everything else.\n\n\nLet’s dive into creating and customizing plots with ggplot2.\n\n\n\n\n\n\nSetup\n\n\n\n\nMake sure you’re in the right project (training_{USERNAME}) and use the Git workflow by Pulling to check for any changes. Then, create a new R Markdown document and remove the default text.\nLoad the packages we’ll need:\n\n\nlibrary(readr)\nlibrary(dplyr)\nlibrary(tidyr)\nlibrary(forcats)\nlibrary(ggplot2)\nlibrary(leaflet)\nlibrary(DT)\nlibrary(scales)\n\n\nLoad the data table directly from the KNB Data Repository: Daily salmon escapement counts from the OceanAK database, Alaska, 1921-2017. Navegate to the link above, hover over the “Download” button for the ADFG_fisrtAttempt_reformatted.csv, right click, and select “Copy Link”.\n\n\nescape <- read_csv(\"https://knb.ecoinformatics.org/knb/d1/mn/v2/object/urn%3Auuid%3Af119a05b-bbe7-4aea-93c6-85434dcb1c5e\")\n\n\nLearn about the data. For this session we are going to be working with data on daily salmon escapement counts in Alaska. Check out the documentation.\nFinally, let’s explore the data we just read into our working environment.\n\n\n## Check out column names\ncolnames(escape)\n\n## Peak at each column and class\nglimpse(escape)\n\n## From when to when\nrange(escape$sampleDate)\n\n## How frequent?\nhead(escape$sampleDate)\ntail(escape$sampleDate)\n\n## Which species?\nunique(escape$Species)"
+ },
+ {
+ "objectID": "session_06.html#getting-the-data-ready",
+ "href": "session_06.html#getting-the-data-ready",
+ "title": "6 Data Visualization in R",
+ "section": "6.2 Getting the data ready",
+ "text": "6.2 Getting the data ready\nIt is more frequent than not, that we need to do some wrangling before we can plot our data the way we want to. Now that we have read out data and have done some exploration, we’ll put our data wrangling skills to practice to get our data in the desired format.\n\n\n\n\n\n\nExercise\n\n\n\n\nCalculate the annual escapement by Species and SASAP.Region,\nFilter the main 5 salmon species (Chinook, Sockeye, Chum, Coho and Pink)\n\n\n\n\nannual_esc <- escape %>%\n separate(sampleDate, c(\"Year\", \"Month\", \"Day\"), sep = \"-\") %>%\n mutate(Year = as.numeric(Year)) %>%\n group_by(Species, SASAP.Region, Year) %>%\n summarize(escapement = sum(DailyCount)) %>%\n filter(Species %in% c(\"Chinook\", \"Sockeye\", \"Chum\", \"Coho\", \"Pink\"))\n\nhead(annual_esc)\n\n# A tibble: 6 × 4\n# Groups: Species, SASAP.Region [1]\n Species SASAP.Region Year escapement\n <chr> <chr> <dbl> <dbl>\n1 Chinook Alaska Peninsula and Aleutian Islands 1974 1092\n2 Chinook Alaska Peninsula and Aleutian Islands 1975 1917\n3 Chinook Alaska Peninsula and Aleutian Islands 1976 3045\n4 Chinook Alaska Peninsula and Aleutian Islands 1977 4844\n5 Chinook Alaska Peninsula and Aleutian Islands 1978 3901\n6 Chinook Alaska Peninsula and Aleutian Islands 1979 10463\n\n\nThe chunk above used a lot of the dplyr commands that we’ve used, and some that are new. The separate() function is used to divide the sampleDate column up into Year, Month, and Day columns, and then we use group_by() to indicate that we want to calculate our results for the unique combinations of species, region, and year. We next use summarize() to calculate an escapement value for each of these groups. Finally, we use a filter and the %in% operator to select only the salmon species."
+ },
+ {
+ "objectID": "session_06.html#plotting-with-ggplot2",
+ "href": "session_06.html#plotting-with-ggplot2",
+ "title": "6 Data Visualization in R",
+ "section": "6.3 Plotting with ggplot2",
+ "text": "6.3 Plotting with ggplot2\n\n6.3.1 Essentials components\nFirst, we’ll cover some ggplot2 basics to create the foundation of our plot. Then, we’ll add on to make our great customized data visualization.\n\n\n\n\n\n\nThe basics\n\n\n\n\nIndicate we are using ggplot() (call the ggplot2::ggplot() function)\nWhat data do we want to plot? (data = my_data)\nWhat is my mapping aesthetics? What variables do we want to plot? (define usingaes() function)\nDefine the geometry of our plot. This specifies the type of plot we’re making (use geom_*() to indicate the type of plot e.g: point, bar, etc.)\n\nNote To add layers to our plot, for example, additional geometries/aesthetics and theme elements or any ggplot object we use +.\n\n\nFor example, let’s plot total escapement by species. We will show this by creating the same plot in 3 slightly different ways. Each of the options below have the essential pieces of a ggplot.\n\n## Option 1 - data and mapping called in the ggplot() function\nggplot(data = annual_esc,\n aes(x = Species, y = escapement)) +\n geom_col()\n\n## Option 2 - data called in ggplot function; mapping called in geom\nggplot(data = annual_esc) +\n geom_col(aes(x = Species, y = escapement))\n\n\n## Option 3 - data and mapping called in geom\nggplot() +\n geom_col(data = annual_esc,\n aes(x = Species, y = escapement))\n\nThey all will create the same plot:\n\n\n\n\n\n\n\n6.3.2 Looking at different geoms\nHaving the basic structure with the essential components in mind, we can easily change the type of graph by updating the geom_*().\n\n\n\n\n\n\nggplot2 and the pipe operator\n\n\n\nJust like in dplyr and tidyr, we can also pipe a data.frame directly into the first argument of the ggplot function using the %>% operator.\nThis can certainly be convenient, but use it carefully! Combining too many data-tidying or subsetting operations with your ggplot call can make your code more difficult to debug and understand.\n\n\nNext, we will use the pipe operator to pass into ggplot() a filtered version of annual_esc, and make a plot with different geometries.\nBoxplot\n\nannual_esc %>%\n filter(Year == 1974,\n Species %in% c(\"Chum\", \"Pink\")) %>%\n ggplot(aes(x = Species, y = escapement)) +\n geom_boxplot()\n\n\n\n\nViolin plot\n\nannual_esc %>%\n filter(Year == 1974,\n Species %in% c(\"Chum\", \"Pink\")) %>%\n ggplot(aes(x = Species, y = escapement)) +\n geom_violin()\n\n\n\n\nLine and point\n\nannual_esc %>%\n filter(Species == \"Sockeye\",\n SASAP.Region == \"Bristol Bay\") %>%\n ggplot(aes(x = Year, y = escapement)) +\n geom_line() +\n geom_point()\n\n\n\n\n\n\n6.3.3 Customizing our plot\nLet’s go back to our base bar graph. What if we want our bars to be blue instead of gray? You might think we could run this:\n\nggplot(annual_esc,\n aes(x = Species, y = escapement,\n fill = \"blue\")) +\n geom_col()\n\n\n\n\nWhy did that happen?\nNotice that we tried to set the fill color of the plot inside the mapping aesthetic call. What we have done, behind the scenes, is create a column filled with the word “blue” in our data frame, and then mapped it to the fill aesthetic, which then chose the default fill color of red.\nWhat we really wanted to do was just change the color of the bars. If we want do do that, we can call the color option in the geom_col() function, outside of the mapping aesthetics function call.\n\nggplot(annual_esc,\n aes(x = Species, y = escapement)) +\n geom_col(fill = \"blue\")\n\n\n\n\nWhat if we did want to map the color of the bars to a variable, such as region. ggplot() is really powerful because we can easily get this plot to visualize more aspects of our data.\n\nggplot(annual_esc,\n aes(x = Species, y = escapement,\n fill = SASAP.Region)) +\n geom_col()\n\n\n\n\n\n\n\n\n\n\nKeep in mind\n\n\n\n\nIf you want to map a variable onto a graph aesthetic (e.g., point color should be based on a specific region), put it within aes().\nIf you want to update your plot base on a constant (e.g. “Make ALL the points BLUE”), you can add the information directly to the relevant geom_ layer.\n\n\n\n\n6.3.3.1 Creating multiple plots\nWe know that in the graph we just plotted, each bar includes escapements for multiple years. Let’s leverage the power of ggplot to plot more aspects of our data in one plot.\nWe are going to plot escapement by species over time, from 2000 to 2016, for each region.\nAn easy way to plot another aspect of your data is using the function facet_wrap(). This function takes a mapping to a variable using the syntax ~{variable_name}. The ~ (tilde) is a model operator which tells facet_wrap() to model each unique value within variable_name to a facet in the plot.\nThe default behavior of facet wrap is to put all facets on the same x and y scale. You can use the scales argument to specify whether to allow different scales between facet plots (e.g scales = \"free_y\" to free the y axis scale). You can also specify the number of columns using the ncol = argument or number of rows using nrow =.\n\n## Subset with data from years 2000 to 2016\n\nannual_esc_2000s <- annual_esc %>%\n filter(Year %in% c(2000:2016))\n\n## Quick check\nunique(annual_esc_2000s$Year)\n\n [1] 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014\n[16] 2015 2016\n\n## Plot with facets\nggplot(annual_esc_2000s,\n aes(x = Year,\n y = escapement,\n color = Species)) +\n geom_line() +\n geom_point() +\n facet_wrap( ~ SASAP.Region,\n scales = \"free_y\")\n\n\n\n\n\n\n6.3.3.2 Setting ggplot themes\nNow let’s work on making this plot look a bit nicer. We are going to”\n\nAdd a title using ggtitle()\nAdjust labels using ylab()\nInclude a built in theme using theme_bw()\n\nThere are a wide variety of built in themes in ggplot that help quickly set the look of the plot. Use the RStudio autocomplete theme_ <TAB> to view a list of theme functions.\n\nggplot(annual_esc_2000s,\n aes(x = Year,\n y = escapement,\n color = Species)) +\n geom_line() +\n geom_point() +\n facet_wrap( ~ SASAP.Region,\n scales = \"free_y\") +\n ylab(\"Escapement\") +\n ggtitle(\"Annual Salmon Escapement by Region\") +\n theme_bw()\n\n\n\n\nYou can see that the theme_bw() function changed a lot of the aspects of our plot! The background is white, the grid is a different color, etc. There are lots of other built in themes like this that come with the ggplot2 package.\n\n\n\n\n\n\nExercise\n\n\n\nUse the RStudio auto complete, the ggplot2 documentation, a cheat sheet, or good old Google to find other built in themes. Pick out your favorite one and add it to your plot.\n\n\n\n\nThemes\n## Useful baseline themes are\ntheme_minimal()\ntheme_light()\ntheme_classic()\n\n\nThe built in theme functions (theme_*()) change the default settings for many elements that can also be changed individually using thetheme() function. The theme() function is a way to further fine-tune the look of your plot. This function takes MANY arguments (just have a look at ?theme). Luckily there are many great ggplot resources online so we don’t have to remember all of these, just Google “ggplot cheat sheet” and find one you like.\nLet’s look at an example of a theme() call, where we change the position of the legend from the right side to the bottom, and remove its title.\n\nggplot(annual_esc_2000s,\n aes(x = Year,\n y = escapement,\n color = Species)) +\n geom_line() +\n geom_point() +\n facet_wrap( ~ SASAP.Region,\n scales = \"free_y\") +\n ylab(\"Escapement\") +\n ggtitle(\"Annual Salmon Escapement by Region\") +\n theme_light() +\n theme(legend.position = \"bottom\",\n legend.title = element_blank())\n\n\n\n\nNote that the theme() call needs to come after any built-in themes like theme_bw() are used. Otherwise, theme_bw() will likely override any theme elements that you changed using theme().\nYou can also save the result of a series of theme() function calls to an object to use on multiple plots. This prevents needing to copy paste the same lines over and over again!\n\nmy_theme <- theme_light() +\n theme(legend.position = \"bottom\",\n legend.title = element_blank())\n\nSo now our code will look like this:\n\nggplot(annual_esc_2000s,\n aes(x = Year,\n y = escapement,\n color = Species)) +\n geom_line() +\n geom_point() +\n facet_wrap( ~ SASAP.Region,\n scales = \"free_y\") +\n ylab(\"Escapement\") +\n ggtitle(\"Annual Salmon Escapement by Region\") +\n my_theme\n\n\n\n\n\n\n\n\n\n\nExercise\n\n\n\n\nUsing whatever method you like, figure out how to rotate the x-axis tick labels to a 45 degree angle.\n\nHint: You can start by looking at the documentation of the function by typing ?theme() in the console. And googling is a great way to figure out how to do the modifications you want to your plot.\n\nWhat changes do you expect to see in your plot by adding the following line of code? Discuss with your neighbor and then try it out!\n\nscale_x_continuous(breaks = seq(2000,2016, 2))\n\n\n\n\nAnswer\n## Useful baseline themes are\nggplot(annual_esc_2000s,\n aes(x = Year,\n y = escapement,\n color = Species)) +\n geom_line() +\n geom_point() +\n scale_x_continuous(breaks = seq(2000, 2016, 2)) +\n facet_wrap( ~ SASAP.Region,\n scales = \"free_y\") +\n ylab(\"Escapement\") +\n ggtitle(\"Annual Salmon Escapement by Region\") +\n my_theme +\n theme(axis.text.x = element_text(angle = 45,\n vjust = 0.5))\n\n\n\n\n6.3.3.3 Smarter tick labels using scales\nFixing tick labels in ggplot can be super annoying. The y-axis labels in the plot above don’t look great. We could manually fix them, but it would likely be tedious and error prone.\nThe scales package provides some nice helper functions to easily rescale and relabel your plots. Here, we use scale_y_continuous() from ggplot2, with the argument labels, which is assigned to the function name comma, from the scales package. This will format all of the labels on the y-axis of our plot with comma-formatted numbers.\n\nggplot(annual_esc_2000s,\n aes(x = Year,\n y = escapement,\n color = Species)) +\n geom_line() +\n geom_point() +\n scale_x_continuous(breaks = seq(2000, 2016, 2)) +\n scale_y_continuous(labels = comma) +\n facet_wrap( ~ SASAP.Region,\n scales = \"free_y\") +\n ylab(\"Escapement\") +\n ggtitle(\"Annual Salmon Escapement by Region\") +\n my_theme +\n theme(axis.text.x = element_text(angle = 45,\n vjust = 0.5))\n\n\n\n\nYou can also save all your code into an object in your working environment by assigning a name to the ggplot() code.\n\nannual_region_plot <- ggplot(annual_esc_2000s,\n aes(x = Year,\n y = escapement,\n color = Species)) +\n geom_line() +\n geom_point() +\n scale_x_continuous(breaks = seq(2000, 2016, 2)) +\n scale_y_continuous(labels = comma) +\n facet_wrap( ~ SASAP.Region,\n scales = \"free_y\") +\n ylab(\"Escapement\") +\n xlab(\"\\nYear\") +\n ggtitle(\"Annual Salmon Escapement by Region\") +\n my_theme +\n theme(axis.text.x = element_text(angle = 45,\n vjust = 0.5))\n\nAnd then call your object to see your plot.\n\nannual_region_plot\n\n\n\n\n\n\n6.3.3.4 Reordering things\nggplot() loves putting things in alphabetical order. But more frequent than not, that’s not the order you actually want things to be plotted if you have categorical groups. Let’s find some total years of data by species for Kuskokwim.\n\n## Number Years of data for each salmon species at Kuskokwim\nn_years <- annual_esc %>%\n group_by(SASAP.Region, Species) %>%\n summarize(n = n()) %>%\n filter(SASAP.Region == \"Kuskokwim\")\n\nNow let’s plot this using geom_bar().\n\n## base plot\nggplot(n_years,\n aes(x = Species,\n y = n)) +\n geom_bar(aes(fill = Species),\n stat = \"identity\")\n\n\n\n\nNow, let’s apply some of the customizations we have seen so far and learn some new ones.\n\n## Reordering, flipping coords and other customization\nggplot(n_years,\n aes(\n x = fct_reorder(Species, n),\n y = n,\n fill = Species\n )) +\n geom_bar(stat = \"identity\") +\n coord_flip() +\n theme_minimal() +\n ## another way to customize labels\n labs(x = \"Species\",\n y = \"Number of years of data\",\n title = \"Number of years of escapement data for salmon species in Kuskokwim\") +\n theme(legend.position = \"none\")\n\n\n\n\n\n\n6.3.3.5 Saving plots\nSaving plots using ggplot is easy! The ggsave() function will save either the last plot you created, or any plot that you have saved to a variable. You can specify what output format you want, size, resolution, etc. See ?ggsave() for documentation.\n\nggsave(\"figures/nyears_data_kus.jpg\", width = 8, height = 6, units = \"in\")\n\nWe can also save our facet plot showing annual escapements by region calling the plot’s object.\n\nggsave(annual_region_plot, \"figures/annual_esc_region.png\", width = 12, height = 8, units = \"in\")"
+ },
+ {
+ "objectID": "session_06.html#interactive-visualization",
+ "href": "session_06.html#interactive-visualization",
+ "title": "6 Data Visualization in R",
+ "section": "6.4 Interactive visualization",
+ "text": "6.4 Interactive visualization\n\n6.4.1 Tables with DT\nNow that we know how to make great static visualizations, let’s introduce two other packages that allow us to display our data in interactive ways. These packages really shine when used with GitHub Pages, so at the end of this lesson we will publish our figures to the website we created earlier.\nFirst let’s show an interactive table of unique sampling locations using DT. Write a data.frame containing unique sampling locations with no missing values using two new functions from dplyr and tidyr: distinct() and drop_na().\n\nlocations <- escape %>%\n distinct(Location, Latitude, Longitude) %>%\n drop_na()\n\nAnd display it as an interactive table using datatable() from the DT package.\n\ndatatable(locations)\n\n\n\n\n\n\n\n\n6.4.2 Maps with leaflet\nSimilar to ggplot2, you can make a basic leaflet map using just a couple lines of code. Note that unlike ggplot2, the leaflet package uses pipe operators (%>%) and not the additive operator (+).\nThe addTiles() function without arguments will add base tiles to your map from OpenStreetMap. addMarkers() will add a marker at each location specified by the latitude and longitude arguments. Note that the ~ symbol is used here to model the coordinates to the map (similar to facet_wrap() in ggplot).\n\nleaflet(locations) %>%\n addTiles() %>%\n addMarkers(\n lng = ~ Longitude,\n lat = ~ Latitude,\n popup = ~ Location\n )\n\n\n\n\n\n\nYou can also use leaflet to import Web Map Service (WMS) tiles. Here is an example that utilizes the General Bathymetric Map of the Oceans (GEBCO) WMS tiles. In this example, we also demonstrate how to create a more simple circle marker, the look of which is explicitly set using a series of style-related arguments.\n\nleaflet(locations) %>%\n addWMSTiles(\n \"https://www.gebco.net/data_and_products/gebco_web_services/web_map_service/mapserv?request=getmap&service=wms&BBOX=-90,-180,90,360&crs=EPSG:4326&format=image/jpeg&layers=gebco_latest&width=1200&height=600&version=1.3.0\",\n layers = 'GEBCO_LATEST',\n attribution = \"Imagery reproduced from the GEBCO_2022 Grid, WMS 1.3.0 GetMap, www.gebco.net\"\n ) %>%\n addCircleMarkers(\n lng = ~ Longitude,\n lat = ~ Latitude,\n popup = ~ Location,\n radius = 5,\n # set fill properties\n fillColor = \"salmon\",\n fillOpacity = 1,\n # set stroke properties\n stroke = T,\n weight = 0.5,\n color = \"white\",\n opacity = 1\n )\n\n\n\n\n\n\nLeaflet has a ton of functionality that can enable you to create some beautiful, functional maps with relative ease. Here is an example of some we created as part of the State of Alaskan Salmon and People (SASAP) project, created using the same tools we showed you here. This map hopefully gives you an idea of how powerful the combination of R Markdown and GitHub Pages can be."
+ },
+ {
+ "objectID": "session_06.html#publish-the-data-visualization-lesson-to-your-webpage",
+ "href": "session_06.html#publish-the-data-visualization-lesson-to-your-webpage",
+ "title": "6 Data Visualization in R",
+ "section": "6.5 Publish the Data Visualization lesson to your webpage",
+ "text": "6.5 Publish the Data Visualization lesson to your webpage\n\n\n\n\n\n\nSteps\n\n\n\n\nSave the Rmd you have been working on for this lesson.\n“Knit” the Rmd. This is a good way to test if everything in your code is working.\nGo to your index.Rmd and the link to the html file with this lesson’s content.\nSave and render index.Rmd to an html.\nUse the Git workflow: Stage > Commit > Pull > Push"
+ },
+ {
+ "objectID": "session_06.html#ggplot2-resources",
+ "href": "session_06.html#ggplot2-resources",
+ "title": "6 Data Visualization in R",
+ "section": "6.6 ggplot2 Resources",
+ "text": "6.6 ggplot2 Resources\n\nWhy not to use two axes, and what to use instead: The case against dual axis charts by Lisa Charlotte Rost.\nCustomized Data Visualization in ggplot2 by Allison Horst.\nA ggplot2 tutorial for beautiful plotting in R by Cedric Scherer."
+ },
+ {
+ "objectID": "session_07.html",
+ "href": "session_07.html",
+ "title": "7 Systematic Reviews",
+ "section": "",
+ "text": "ADD LINK TO MATERIAL"
+ },
+ {
+ "objectID": "session_09.html#learning-objectives",
+ "href": "session_09.html#learning-objectives",
+ "title": "9 Using sf for Spatia Data & Intro to Making Maps",
+ "section": "Learning Objectives",
+ "text": "Learning Objectives\n\nHow to use the sf package to wrangle spatial data\nStatic mapping with ggplot\nAdding basemaps to static maps\nInteractive mapping with leaflet"
+ },
+ {
+ "objectID": "session_09.html#brief-introduction-to-sf",
+ "href": "session_09.html#brief-introduction-to-sf",
+ "title": "9 Using sf for Spatia Data & Intro to Making Maps",
+ "section": "9.1 Brief introduction to sf",
+ "text": "9.1 Brief introduction to sf\nFrom the sf vignette:\n\nSimple features or simple feature access refers to a formal standard (ISO 19125-1:2004) that describes how objects in the real world can be represented in computers, with emphasis on the spatial geometry of these objects. It also describes how such objects can be stored in and retrieved from databases, and which geometrical operations should be defined for them.\n\nThe sf package is an R implementation of Simple Features. This package incorporates:\n\na new spatial data class system in R\n\nfunctions for reading and writing spatial data\n\ntools for spatial operations on vectors\n\nMost of the functions in this package starts with prefix st_ which stands for spatial and temporal.\nIn this lesson, our goal is to use a shapefile of Alaska regions and rivers, and data on population in Alaska by community to create a map that looks like this:"
+ },
+ {
+ "objectID": "session_09.html#about-the-data",
+ "href": "session_09.html#about-the-data",
+ "title": "9 Using sf for Spatia Data & Intro to Making Maps",
+ "section": "9.2 About the data",
+ "text": "9.2 About the data\nAll of the data used in this tutorial are simplified versions of real datasets available on the KNB Data Repository. We are using simplified datasets to ease the processing burden on all our computers since the original geospatial datasets are high-resolution. These simplified versions of the datasets may contain topological errors.\nThe spatial data we will be using to create the map are:\n\n\n\nData\nOriginal datasets\n\n\n\n\nAlaska regional boundaries\nJared Kibele and Jeanette Clark. 2018. State of Alaska’s Salmon and People Regional Boundaries. Knowledge Network for Biocomplexity. doi:10.5063/F1125QWP.\n\n\nCommunity locations and population\nJeanette Clark, Sharis Ochs, Derek Strong, and National Historic Geographic Information System. 2018. Languages used in Alaskan households, 1990-2015. Knowledge Network for Biocomplexity. doi:10.5063/F11G0JHX.\n\n\nAlaska rivers\nThe rivers shapefile is a simplified version of Jared Kibele and Jeanette Clark. Rivers of Alaska grouped by SASAP region, 2018. Knowledge Network for Biocomplexity. doi:10.5063/F1SJ1HVW.\n\n\n\n\n\n\n\n\n\nSetup\n\n\n\n\nNavigate to this dataset on KNB’s test site and download the zip folder.\nUpload the zip folder to the data folder in the training_{USERNAME} project. You don’t need to unzip the folder ahead of time, uploading will automatically unzip the folder.\nCreate a new R Markdown file.\n\nTitle it “Intro to sf package for Spatial Data and Making Maps”\nSave the file and name it “intro-sf-spatial-data-maps”.\n\nLoad the following libraries at the top of your R Markdown file.\n\n\nlibrary(readr)\nlibrary(sf)\nlibrary(ggplot2)\nlibrary(leaflet)\nlibrary(scales)\nlibrary(ggmap)\nlibrary(dplyr)"
+ },
+ {
+ "objectID": "session_09.html#exploring-the-data-using-plot-and-st_crs",
+ "href": "session_09.html#exploring-the-data-using-plot-and-st_crs",
+ "title": "9 Using sf for Spatia Data & Intro to Making Maps",
+ "section": "9.3 Exploring the data using plot() and st_crs()",
+ "text": "9.3 Exploring the data using plot() and st_crs()\nFirst let’s read in the shapefile of regional boundaries in Alaska using read_sf() and then create a basic plot of the data plot().\n\n# read in shapefile using read_sf()\nak_regions <- read_sf(\"data/ak_regions_simp.shp\")\n\n\n# quick plot\nplot(ak_regions)\n\n\n\n\nWe can also examine it’s class using class().\n\nclass(ak_regions)\n\n[1] \"sf\" \"tbl_df\" \"tbl\" \"data.frame\"\n\n\nsf objects usually have two types of classes: sf and data.frame.\nUnlike a typical data.frame, an sf object has spatial metadata (geometry type, dimension, bbox, epsg (SRID), proj4string) and an additional column typically named geometry that contains the spatial data.\nSince our shapefile object has the data.frame class, viewing the contents of the object using the head() function or other exploratory functions shows similar results as if we read in data using read.csv() or read_csv().\n\nhead(ak_regions)\n\nSimple feature collection with 6 features and 3 fields\nGeometry type: MULTIPOLYGON\nDimension: XY\nBounding box: xmin: -179.2296 ymin: 51.15702 xmax: 179.8567 ymax: 71.43957\nGeodetic CRS: WGS 84\n# A tibble: 6 × 4\n region_id region mgmt_area geometry\n <int> <chr> <dbl> <MULTIPOLYGON [°]>\n1 1 Aleutian Islands 3 (((-171.1345 52.44974, -171.1686 52.4174…\n2 2 Arctic 4 (((-139.9552 68.70597, -139.9893 68.7051…\n3 3 Bristol Bay 3 (((-159.8745 58.62778, -159.8654 58.6137…\n4 4 Chignik 3 (((-155.8282 55.84638, -155.8049 55.8655…\n5 5 Copper River 2 (((-143.8874 59.93931, -143.9165 59.9403…\n6 6 Kodiak 3 (((-151.9997 58.83077, -152.0358 58.8271…\n\nglimpse(ak_regions)\n\nRows: 13\nColumns: 4\n$ region_id <int> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13\n$ region <chr> \"Aleutian Islands\", \"Arctic\", \"Bristol Bay\", \"Chignik\", \"Cop…\n$ mgmt_area <dbl> 3, 4, 3, 3, 2, 3, 4, 4, 2, 4, 2, 1, 4\n$ geometry <MULTIPOLYGON [°]> MULTIPOLYGON (((-171.1345 5..., MULTIPOLYGON (((-139.9552 6.…\n\n\n\n9.3.1 Coordinate Reference System (CRS)\n\n\n\nSource: ESRI\n\n\nEvery sf object needs a coordinate reference system (or crs) defined in order to work with it correctly. A coordinate reference system contains both a datum and a projection. The datum is how you georeference your points (in 3 dimensions!) onto a spheroid. The projection is how these points are mathematically transformed to represent the georeferenced point on a flat piece of paper. All coordinate reference systems require a datum. However, some coordinate reference systems are “unprojected” (also called geographic coordinate systems). Coordinates in latitude/longitude use a geographic (unprojected) coordinate system. One of the most commonly used geographic coordinate systems is WGS 1984.\nESRI has a blog post that explains these concepts in more detail with very helpful diagrams and examples.\nYou can view what crs is set by using the function st_crs().\n\nst_crs(ak_regions)\n\nCoordinate Reference System:\n User input: WGS 84 \n wkt:\nGEOGCRS[\"WGS 84\",\n DATUM[\"World Geodetic System 1984\",\n ELLIPSOID[\"WGS 84\",6378137,298.257223563,\n LENGTHUNIT[\"metre\",1]]],\n PRIMEM[\"Greenwich\",0,\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n CS[ellipsoidal,2],\n AXIS[\"latitude\",north,\n ORDER[1],\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n AXIS[\"longitude\",east,\n ORDER[2],\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n ID[\"EPSG\",4326]]\n\n\nThis is pretty confusing looking. Without getting into the details, that long string says that this data has a geographic coordinate system (WGS84) with no projection. A convenient way to reference crs quickly is by using the EPSG code, a number that represents a standard projection and datum. You can check out a list of (lots!) of EPSG codes here.\nWe will use multiple EPSG codes in this lesson. Here they are, along with their more readable names:\n\n3338: Alaska Albers (projected CRS)\n4326: WGS84 (World Geodetic System 1984), used in GPS (unprojected CRS)\n3857: Pseudo-Mercator, used in Google Maps, OpenStreetMap, Bing, ArcGIS, ESRI (projected CRS)\n\nYou will often need to transform your geospatial data from one coordinate system to another. The st_transform() function does this quickly for us. You may have noticed the maps above looked wonky because of the dateline. We might want to set a different projection for this data so it plots nicer. A good one for Alaska is called the Alaska Albers projection, with an EPSG code of 3338.\n\nak_regions_3338 <- ak_regions %>%\n st_transform(crs = 3338)\n\nst_crs(ak_regions_3338)\n\nCoordinate Reference System:\n User input: EPSG:3338 \n wkt:\nPROJCRS[\"NAD83 / Alaska Albers\",\n BASEGEOGCRS[\"NAD83\",\n DATUM[\"North American Datum 1983\",\n ELLIPSOID[\"GRS 1980\",6378137,298.257222101,\n LENGTHUNIT[\"metre\",1]]],\n PRIMEM[\"Greenwich\",0,\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n ID[\"EPSG\",4269]],\n CONVERSION[\"Alaska Albers (meters)\",\n METHOD[\"Albers Equal Area\",\n ID[\"EPSG\",9822]],\n PARAMETER[\"Latitude of false origin\",50,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8821]],\n PARAMETER[\"Longitude of false origin\",-154,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8822]],\n PARAMETER[\"Latitude of 1st standard parallel\",55,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8823]],\n PARAMETER[\"Latitude of 2nd standard parallel\",65,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8824]],\n PARAMETER[\"Easting at false origin\",0,\n LENGTHUNIT[\"metre\",1],\n ID[\"EPSG\",8826]],\n PARAMETER[\"Northing at false origin\",0,\n LENGTHUNIT[\"metre\",1],\n ID[\"EPSG\",8827]]],\n CS[Cartesian,2],\n AXIS[\"easting (X)\",east,\n ORDER[1],\n LENGTHUNIT[\"metre\",1]],\n AXIS[\"northing (Y)\",north,\n ORDER[2],\n LENGTHUNIT[\"metre\",1]],\n USAGE[\n SCOPE[\"Topographic mapping (small scale).\"],\n AREA[\"United States (USA) - Alaska.\"],\n BBOX[51.3,172.42,71.4,-129.99]],\n ID[\"EPSG\",3338]]\n\n\n\nplot(ak_regions_3338)\n\n\n\n\nMuch better!"
+ },
+ {
+ "objectID": "session_09.html#sf-the-tidyverse",
+ "href": "session_09.html#sf-the-tidyverse",
+ "title": "9 Using sf for Spatia Data & Intro to Making Maps",
+ "section": "9.4 sf & the Tidyverse",
+ "text": "9.4 sf & the Tidyverse\nsf objects can be used as a regular data.frame object in many operations. We already saw the results of plot() and head().\nSince sf objects are data.frames, they play nicely with packages in the tidyverse. Here are a couple of simple examples:\n\n9.4.1 select()\n\n# returns the names of all the columns in dataset\ncolnames(ak_regions_3338)\n\n[1] \"region_id\" \"region\" \"mgmt_area\" \"geometry\" \n\n\n\nak_regions_3338 %>%\n select(region)\n\nSimple feature collection with 13 features and 1 field\nGeometry type: MULTIPOLYGON\nDimension: XY\nBounding box: xmin: -2175328 ymin: 405653 xmax: 1579226 ymax: 2383770\nProjected CRS: NAD83 / Alaska Albers\n# A tibble: 13 × 2\n region geometry\n <chr> <MULTIPOLYGON [m]>\n 1 Aleutian Islands (((-1156666 420855.1, -1159837 417990.3, -1161898 41694…\n 2 Arctic (((571289.9 2143072, 569941.5 2142691, 569158.2 2142146…\n 3 Bristol Bay (((-339688.6 973904.9, -339302 972297.3, -339229.2 9710…\n 4 Chignik (((-114381.9 649966.8, -112866.8 652065.8, -108836.8 65…\n 5 Copper River (((561012 1148301, 559393.7 1148169, 557797.7 1148492, …\n 6 Kodiak (((115112.5 983293, 113051.3 982825.9, 110801.3 983211.…\n 7 Kotzebue (((-678815.3 1819519, -677555.2 1820698, -675557.8 1821…\n 8 Kuskokwim (((-1030125 1281198, -1029858 1282333, -1028980 1284032…\n 9 Cook Inlet (((35214.98 1002457, 36660.3 1002038, 36953.11 1001186,…\n10 Norton Sound (((-848357 1636692, -846510 1635203, -840513.7 1632225,…\n11 Prince William Sound (((426007.1 1087250, 426562.5 1088591, 427711.6 1089991…\n12 Southeast (((1287777 744574.1, 1290183 745970.8, 1292940 746262.7…\n13 Yukon (((-375318 1473998, -373723.9 1473487, -373064.8 147393…\n\n\nNote the sticky geometry column! The geometry column will stay with your sf object even if it is not called explicitly.\n\n\n9.4.2 filter()\n\nunique(ak_regions_3338$region)\n\n [1] \"Aleutian Islands\" \"Arctic\" \"Bristol Bay\" \n [4] \"Chignik\" \"Copper River\" \"Kodiak\" \n [7] \"Kotzebue\" \"Kuskokwim\" \"Cook Inlet\" \n[10] \"Norton Sound\" \"Prince William Sound\" \"Southeast\" \n[13] \"Yukon\" \n\n\n\nak_regions_3338 %>%\n filter(region == \"Southeast\")\n\nSimple feature collection with 1 feature and 3 fields\nGeometry type: MULTIPOLYGON\nDimension: XY\nBounding box: xmin: 559475.7 ymin: 722450 xmax: 1579226 ymax: 1410576\nProjected CRS: NAD83 / Alaska Albers\n# A tibble: 1 × 4\n region_id region mgmt_area geometry\n* <int> <chr> <dbl> <MULTIPOLYGON [m]>\n1 12 Southeast 1 (((1287777 744574.1, 1290183 745970.8, 1292940 …"
+ },
+ {
+ "objectID": "session_09.html#spatial-joins",
+ "href": "session_09.html#spatial-joins",
+ "title": "9 Using sf for Spatia Data & Intro to Making Maps",
+ "section": "9.5 Spatial Joins",
+ "text": "9.5 Spatial Joins\nYou can also use the sf package to create spatial joins, useful for when you want to utilize two datasets together.\n\n\n\n\n\n\nExercise: How many people live in each of these Alaska regions?\n\n\n\nWe have some population data, but it gives the population by city, not by region. To determine the population per region we will need to:\n\nRead in the population data from a csv and turn it into an sf object\nUse a spatial join (st_join()) to assign each city to a region\nUse group_by() and summarize() to calculate the total population by region\nSave the spatial object you created using write_sf()\n\n\n\n1. Read in alaska_population.csv using read.csv()\n\n# read in population data\npop <- read_csv(\"data/alaska_population.csv\")\n\nTurn pop into a spatial object\nThe st_join() function is a spatial left join. The arguments for both the left and right tables are objects of class sf which means we will first need to turn our population data.frame with latitude and longitude coordinates into an sf object.\nWe can do this easily using the st_as_sf() function, which takes as arguments the coordinates and the crs. The remove = F specification here ensures that when we create our geometry column, we retain our original lat lng columns, which we will need later for plotting. Although it isn’t said anywhere explicitly in the file, let’s assume that the coordinate system used to reference the latitude longitude coordinates is WGS84, which has a crs number of 4326.\n\npop_4326 <- st_as_sf(pop,\n coords = c('lng', 'lat'),\n crs = 4326,\n remove = F)\n\nhead(pop_4326)\n\nSimple feature collection with 6 features and 5 fields\nGeometry type: POINT\nDimension: XY\nBounding box: xmin: -176.6581 ymin: 51.88 xmax: -154.1703 ymax: 62.68889\nGeodetic CRS: WGS 84\n# A tibble: 6 × 6\n year city lat lng population geometry\n <dbl> <chr> <dbl> <dbl> <dbl> <POINT [°]>\n1 2015 Adak 51.9 -177. 122 (-176.6581 51.88)\n2 2015 Akhiok 56.9 -154. 84 (-154.1703 56.94556)\n3 2015 Akiachak 60.9 -161. 562 (-161.4314 60.90944)\n4 2015 Akiak 60.9 -161. 399 (-161.2139 60.91222)\n5 2015 Akutan 54.1 -166. 899 (-165.7731 54.13556)\n6 2015 Alakanuk 62.7 -165. 777 (-164.6153 62.68889)\n\n\n2. Join population data with Alaska regions data using st_join()\nNow we can do our spatial join! You can specify what geometry function the join uses (st_intersects, st_within, st_crosses, st_is_within_distance…) in the join argument. The geometry function you use will depend on what kind of operation you want to do, and the geometries of your shapefiles.\nIn this case, we want to find what region each city falls within, so we will use st_within.\n\npop_joined <- st_join(pop_4326, ak_regions_3338, join = st_within)\n\nThis gives an error!\nError: st_crs(x) == st_crs(y) is not TRUE\nTurns out, this won’t work right now because our coordinate reference systems are not the same. Luckily, this is easily resolved using st_transform(), and projecting our population object into Alaska Albers.\n\npop_3338 <- st_transform(pop_4326, crs = 3338)\n\n\npop_joined <- st_join(pop_3338, ak_regions_3338, join = st_within)\n\nhead(pop_joined)\n\nSimple feature collection with 6 features and 8 fields\nGeometry type: POINT\nDimension: XY\nBounding box: xmin: -1537925 ymin: 472626.9 xmax: -10340.71 ymax: 1456223\nProjected CRS: NAD83 / Alaska Albers\n# A tibble: 6 × 9\n year city lat lng population geometry region_id region \n <dbl> <chr> <dbl> <dbl> <dbl> <POINT [m]> <int> <chr> \n1 2015 Adak 51.9 -177. 122 (-1537925 472626.9) 1 Aleutian I…\n2 2015 Akhiok 56.9 -154. 84 (-10340.71 770998.4) 6 Kodiak \n3 2015 Akiac… 60.9 -161. 562 (-400885.5 1236460) 8 Kuskokwim \n4 2015 Akiak 60.9 -161. 399 (-389165.7 1235475) 8 Kuskokwim \n5 2015 Akutan 54.1 -166. 899 (-766425.7 526057.8) 1 Aleutian I…\n6 2015 Alaka… 62.7 -165. 777 (-539724.9 1456223) 13 Yukon \n# ℹ 1 more variable: mgmt_area <dbl>\n\n\n\n\n\n\n\n\nExploring types of joins\n\n\n\nThere are many different types of joins you can do with geospatial data. Examine the help page for these joins (?st_within() will get you there). What other joins types might be appropriate for examining the relationship between points and polygyons? What about two sets of polygons?\n\n\n3. Calculate the total population by region using group_by() and summarize()\nNext we compute the total population for each region. In this case, we want to do a group_by() and summarise() as this were a regular data.frame. Otherwise all of our point geometries would be included in the aggregation, which is not what we want. Our goal is just to get the total population by region. We remove the sticky geometry using as.data.frame(), on the advice of the sf::tidyverse help page.\n\npop_region <- pop_joined %>%\n as.data.frame() %>%\n group_by(region) %>%\n summarise(total_pop = sum(population))\n\nhead(pop_region)\n\n# A tibble: 6 × 2\n region total_pop\n <chr> <dbl>\n1 Aleutian Islands 8840\n2 Arctic 8419\n3 Bristol Bay 6947\n4 Chignik 311\n5 Cook Inlet 408254\n6 Copper River 2294\n\n\nAnd use a regular left_join() to get the information back to the Alaska region shapefile. Note that we need this step in order to regain our region geometries so that we can make some maps.\n\npop_region_3338 <- left_join(ak_regions_3338, pop_region, by = \"region\")\n\n# plot to check\nplot(pop_region_3338[\"total_pop\"])\n\n\n\n\nSo far, we have learned how to use sf and dplyr to use a spatial join on two datasets and calculate a summary metric from the result of that join.\n\n\n\n\n\n\nsf and tidyverse best practices\n\n\n\nThe group_by() and summarize() functions can also be used on sf objects to summarize within a dataset and combine geometries. Many of the tidyverse functions have methods specific for sf objects, some of which have additional arguments that wouldn’t be relevant to the data.frame methods. You can run ?sf::tidyverse to get documentation on the tidyverse sf methods.\n\n\nSay we want to calculate the population by Alaska management area, as opposed to region.\n\npop_mgmt_338 <- pop_region_3338 %>%\n group_by(mgmt_area) %>%\n summarize(total_pop = sum(total_pop))\n\nplot(pop_mgmt_338[\"total_pop\"])\n\n\n\n\nNotice that the region geometries were combined into a single polygon for each management area.\nIf we don’t want to combine geometries, we can specify do_union = F as an argument.\n\npop_mgmt_3338 <- pop_region_3338 %>%\n group_by(mgmt_area) %>%\n summarize(total_pop = sum(total_pop), do_union = F)\n\nplot(pop_mgmt_3338[\"total_pop\"])\n\n\n\n\n4. Save the spatial object to a new file using write_sf()\nSave the spatial object to disk using write_sf() and specifying the filename. Writing your file with the extension .shp will assume an ESRI driver driver, but there are many other format options available.\n\nwrite_sf(pop_region_3338, \"data/ak_regions_population.shp\")\n\n\n9.5.1 Visualize with ggplot\nggplot2 now has integrated functionality to plot sf objects using geom_sf().\nWe can plot sf objects just like regular data.frames using geom_sf.\n\nggplot(pop_region_3338) +\n geom_sf(aes(fill = total_pop)) +\n labs(fill = \"Total Population\") +\n scale_fill_continuous(low = \"khaki\",\n high = \"firebrick\",\n labels = comma) +\n theme_bw()\n\n\n\n\nWe can also plot multiple shapefiles in the same plot. Say if we want to visualize rivers in Alaska, in addition to the location of communities, since many communities in Alaska are on rivers. We can read in a rivers shapefile, doublecheck the crs to make sure it is what we need, and then plot all three shapefiles - the regional population (polygons), the locations of cities (points), and the rivers (linestrings).\n\n\nCoordinate Reference System:\n User input: Albers \n wkt:\nPROJCRS[\"Albers\",\n BASEGEOGCRS[\"GCS_GRS 1980(IUGG, 1980)\",\n DATUM[\"D_unknown\",\n ELLIPSOID[\"GRS80\",6378137,298.257222101,\n LENGTHUNIT[\"metre\",1,\n ID[\"EPSG\",9001]]]],\n PRIMEM[\"Greenwich\",0,\n ANGLEUNIT[\"Degree\",0.0174532925199433]]],\n CONVERSION[\"unnamed\",\n METHOD[\"Albers Equal Area\",\n ID[\"EPSG\",9822]],\n PARAMETER[\"Latitude of false origin\",50,\n ANGLEUNIT[\"Degree\",0.0174532925199433],\n ID[\"EPSG\",8821]],\n PARAMETER[\"Longitude of false origin\",-154,\n ANGLEUNIT[\"Degree\",0.0174532925199433],\n ID[\"EPSG\",8822]],\n PARAMETER[\"Latitude of 1st standard parallel\",55,\n ANGLEUNIT[\"Degree\",0.0174532925199433],\n ID[\"EPSG\",8823]],\n PARAMETER[\"Latitude of 2nd standard parallel\",65,\n ANGLEUNIT[\"Degree\",0.0174532925199433],\n ID[\"EPSG\",8824]],\n PARAMETER[\"Easting at false origin\",0,\n LENGTHUNIT[\"metre\",1],\n ID[\"EPSG\",8826]],\n PARAMETER[\"Northing at false origin\",0,\n LENGTHUNIT[\"metre\",1],\n ID[\"EPSG\",8827]]],\n CS[Cartesian,2],\n AXIS[\"(E)\",east,\n ORDER[1],\n LENGTHUNIT[\"metre\",1,\n ID[\"EPSG\",9001]]],\n AXIS[\"(N)\",north,\n ORDER[2],\n LENGTHUNIT[\"metre\",1,\n ID[\"EPSG\",9001]]]]\n\n\n\nrivers_3338 <- read_sf(\"data/ak_rivers_simp.shp\")\nst_crs(rivers_3338)\n\nNote that although no EPSG code is set explicitly, with some sluething we can determine that this is EPSG:3338. This site is helpful for looking up EPSG codes.\n\nggplot() +\n geom_sf(data = pop_region_3338, aes(fill = total_pop)) +\n geom_sf(data = pop_3338, size = 0.5) +\n geom_sf(data = rivers_3338,\n aes(linewidth = StrOrder)) +\n scale_linewidth(range = c(0.05, 0.5), guide = \"none\") +\n labs(title = \"Total Population by Alaska Region\",\n fill = \"Total Population\") +\n scale_fill_continuous(low = \"khaki\",\n high = \"firebrick\",\n labels = comma) +\n theme_bw()"
+ },
+ {
+ "objectID": "session_09.html#incorporate-base-maps-into-static-maps-using-ggmap",
+ "href": "session_09.html#incorporate-base-maps-into-static-maps-using-ggmap",
+ "title": "9 Using sf for Spatia Data & Intro to Making Maps",
+ "section": "9.6 Incorporate base maps into static maps using ggmap",
+ "text": "9.6 Incorporate base maps into static maps using ggmap\nThe ggmap package has some functions that can render base maps (as raster objects) from open tile servers like Google Maps, Stamen, OpenStreetMap, and others.\nWe’ll need to transform our shapefile with population data by community to EPSG:3857 which is the crs used for rendering maps in Google Maps, Stamen, and OpenStreetMap, among others.\n\npop_3857 <- pop_3338 %>%\n st_transform(crs = 3857)\n\nNext, let’s grab a base map from the Stamen map tile server covering the region of interest. First we include a function that transforms the bounding box (which starts in EPSG:4326) to also be in the EPSG:3857 CRS, which is the projection that the map raster is returned in from Stamen. This is an issue with ggmap described in more detail here\n\n# Define a function to fix the bbox to be in EPSG:3857\n# See https://github.com/dkahle/ggmap/issues/160#issuecomment-397055208\nggmap_bbox_to_3857 <- function(map) {\n if (!inherits(map, \"ggmap\"))\n stop(\"map must be a ggmap object\")\n # Extract the bounding box (in lat/lon) from the ggmap to a numeric vector,\n # and set the names to what sf::st_bbox expects:\n map_bbox <- setNames(unlist(attr(map, \"bb\")),\n c(\"ymin\", \"xmin\", \"ymax\", \"xmax\"))\n \n # Coonvert the bbox to an sf polygon, transform it to 3857,\n # and convert back to a bbox (convoluted, but it works)\n bbox_3857 <-\n st_bbox(st_transform(st_as_sfc(st_bbox(map_bbox, crs = 4326)), 3857))\n \n # Overwrite the bbox of the ggmap object with the transformed coordinates\n attr(map, \"bb\")$ll.lat <- bbox_3857[\"ymin\"]\n attr(map, \"bb\")$ll.lon <- bbox_3857[\"xmin\"]\n attr(map, \"bb\")$ur.lat <- bbox_3857[\"ymax\"]\n attr(map, \"bb\")$ur.lon <- bbox_3857[\"xmax\"]\n map\n}\n\nNext, we define the bounding box of interest, and use get_stamenmap() to get the basemap. Then we run our function defined above on the result of the get_stamenmap() call.\n\nbbox <- c(-170, 52,-130, 64) # this is roughly southern Alaska\nak_map <- get_stamenmap(bbox, zoom = 4) # get base map\nak_map_3857 <- ggmap_bbox_to_3857(ak_map) # fix the bbox to be in EPSG:3857\n\nFinally, plot both the base raster map with the population data overlayed, which is easy now that everything is in the same projection (3857):\n\nggmap(ak_map_3857) +\n geom_sf(data = pop_3857,\n aes(color = population),\n inherit.aes = F) +\n scale_color_continuous(low = \"khaki\",\n high = \"firebrick\",\n labels = comma)"
+ },
+ {
+ "objectID": "session_09.html#visualize-sf-objects-with-leaflet",
+ "href": "session_09.html#visualize-sf-objects-with-leaflet",
+ "title": "9 Using sf for Spatia Data & Intro to Making Maps",
+ "section": "9.7 Visualize sf objects with leaflet",
+ "text": "9.7 Visualize sf objects with leaflet\nWe can also make an interactive map from our data above using leaflet.\nleaflet (unlike ggplot) will project data for you. The catch is that you have to give it both a projection (like Alaska Albers), and that your shapefile must use a geographic coordinate system. This means that we need to use our shapefile with the 4326 EPSG code. Remember you can always check what crs you have set using st_crs.\nHere we define a leaflet projection for Alaska Albers, and save it as a variable to use later.\n\nepsg3338 <- leaflet::leafletCRS(\n crsClass = \"L.Proj.CRS\",\n code = \"EPSG:3338\",\n proj4def = \"+proj=aea +lat_1=55 +lat_2=65 +lat_0=50 +lon_0=-154 +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs\",\n resolutions = 2 ^ (16:7)\n)\n\nYou might notice that this looks familiar! The syntax is a bit different, but most of this information is also contained within the crs of our shapefile:\n\nst_crs(pop_region_3338)\n\nCoordinate Reference System:\n User input: EPSG:3338 \n wkt:\nPROJCRS[\"NAD83 / Alaska Albers\",\n BASEGEOGCRS[\"NAD83\",\n DATUM[\"North American Datum 1983\",\n ELLIPSOID[\"GRS 1980\",6378137,298.257222101,\n LENGTHUNIT[\"metre\",1]]],\n PRIMEM[\"Greenwich\",0,\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n ID[\"EPSG\",4269]],\n CONVERSION[\"Alaska Albers (meters)\",\n METHOD[\"Albers Equal Area\",\n ID[\"EPSG\",9822]],\n PARAMETER[\"Latitude of false origin\",50,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8821]],\n PARAMETER[\"Longitude of false origin\",-154,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8822]],\n PARAMETER[\"Latitude of 1st standard parallel\",55,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8823]],\n PARAMETER[\"Latitude of 2nd standard parallel\",65,\n ANGLEUNIT[\"degree\",0.0174532925199433],\n ID[\"EPSG\",8824]],\n PARAMETER[\"Easting at false origin\",0,\n LENGTHUNIT[\"metre\",1],\n ID[\"EPSG\",8826]],\n PARAMETER[\"Northing at false origin\",0,\n LENGTHUNIT[\"metre\",1],\n ID[\"EPSG\",8827]]],\n CS[Cartesian,2],\n AXIS[\"easting (X)\",east,\n ORDER[1],\n LENGTHUNIT[\"metre\",1]],\n AXIS[\"northing (Y)\",north,\n ORDER[2],\n LENGTHUNIT[\"metre\",1]],\n USAGE[\n SCOPE[\"Topographic mapping (small scale).\"],\n AREA[\"United States (USA) - Alaska.\"],\n BBOX[51.3,172.42,71.4,-129.99]],\n ID[\"EPSG\",3338]]\n\n\nSince leaflet requires that we use an unprojected coordinate system, let’s use st_transform() yet again to get back to WGS84.\n\npop_region_4326 <- pop_region_3338 %>% st_transform(crs = 4326)\n\n\nm <- leaflet(options = leafletOptions(crs = epsg3338)) %>%\n addPolygons(data = pop_region_4326,\n fillColor = \"gray\",\n weight = 1)\n\nm\n\n\n\n\n\nWe can add labels, legends, and a color scale.\n\npal <- colorNumeric(palette = \"Reds\", domain = pop_region_4326$total_pop)\n\nm <- leaflet(options = leafletOptions(crs = epsg3338)) %>%\n addPolygons(\n data = pop_region_4326,\n fillColor = ~ pal(total_pop),\n weight = 1,\n color = \"black\",\n fillOpacity = 1,\n label = ~ region\n ) %>%\n addLegend(\n position = \"bottomleft\",\n pal = pal,\n values = range(pop_region_4326$total_pop),\n title = \"Total Population\"\n )\n\nm\n\n\n\n\n\nWe can also add the individual communities, with popup labels showing their population, on top of that!\n\npal <- colorNumeric(palette = \"Reds\", domain = pop_region_4326$total_pop)\n\nm <- leaflet(options = leafletOptions(crs = epsg3338)) %>%\n addPolygons(\n data = pop_region_4326,\n fillColor = ~ pal(total_pop),\n weight = 1,\n color = \"black\",\n fillOpacity = 1\n ) %>%\n addCircleMarkers(\n data = pop_4326,\n lat = ~ lat,\n lng = ~ lng,\n radius = ~ log(population / 500),\n # arbitrary scaling\n fillColor = \"gray\",\n fillOpacity = 1,\n weight = 0.25,\n color = \"black\",\n label = ~ paste0(pop_4326$city, \", population \", comma(pop_4326$population))\n ) %>%\n addLegend(\n position = \"bottomleft\",\n pal = pal,\n values = range(pop_region_4326$total_pop),\n title = \"Total Population\"\n )\n\nm"
+ },
+ {
+ "objectID": "session_09.html#more-spatial-resources",
+ "href": "session_09.html#more-spatial-resources",
+ "title": "9 Using sf for Spatia Data & Intro to Making Maps",
+ "section": "9.8 More Spatial Resources",
+ "text": "9.8 More Spatial Resources\nThere is a lot more functionality to sf including the ability to intersect polygons, calculate distance, create a buffer, and more. Here are some more great resources and tutorials for a deeper dive into this great package:\n\nRaster analysis in R\n\nSpatial analysis in R with the sf package\n\nIntro to Spatial Analysis\n\nsf github repo\n\nTidy spatial data in R: using dplyr, tidyr, and ggplot2 with sf\n\nmapping-fall-foliage-with-sf"
+ },
+ {
+ "objectID": "session_10.html",
+ "href": "session_10.html",
+ "title": "10 Introduction to Meta-Analysis",
+ "section": "",
+ "text": "ADD LINK TO MATERIALS"
+ },
+ {
+ "objectID": "session_11.html#unstructured-text",
+ "href": "session_11.html#unstructured-text",
+ "title": "11 Working with Text Data in R",
+ "section": "11.1 Unstructured Text",
+ "text": "11.1 Unstructured Text\nThe above example showed how to analyze text that was contained within a tabular format (a csv file). There are many other text formats that you might want to analyze, however. This might include pdf documents, websites, word documents, etc. Here, we’ll look at how to read in the text from a PDF document into an analysis pipeline like above.\nBefore we begin, it is important to understand that not all PDF documents can be processed this way. PDF files can store information in many ways, including both images and text. Some PDF documents, particularly older ones, or scanned documents, are images of text and the bytes making up the document do not contain a ‘readable’ version of the text in the image, it is an image not unlike one you would take with a camera. Other PDF documents will contain the text as character strings, along with the information on how to render it on the page (such as position and font). The analysis that follows will only work on PDF files that fit the second description of the format. If the PDF document you are trying to analyze is more like the first, you would need to first use a technique called Optical Character Recognition (OCR) to interpret the text in the image and store it in a parsable way. Since this document can be parsed, we’ll proceed without doing OCR.\nFirst we’ll load another library, pdftools, which will read in our PDF, and the stringr library, which helps manipulate character strings.\n\nlibrary(pdftools)\nlibrary(stringr)\n\nNext, navigate to the dataset Elizabeth Rink and Gitte Adler Reimer. 2022. Population Dynamics in Greenland: A Multi-component Mixed-methods Study of Pregnancy Dynamics in Greenland (2014-2022). Arctic Data Center. doi:10.18739/A21Z41V1R.. Right click the download button next to the top PDF data file called ‘Translation_of_FG_8_Ilulissat_170410_0077.pdf’.\nFirst we create a variable with a path to a location where we want to save the file.\n\npath <- \"data/Translation_of_FG_8_Ilulissat_170410_0077.pdf\"\n\nThen use download.file to download it and save it to that path.\n\ndownload.file(\"https://arcticdata.io/metacat/d1/mn/v2/object/urn%3Auuid%3A34999083-2fa1-4222-ab27-53204327e8fc\", path)\n\nThe pdf_text function extracts the text from the PDF file, returning a vector of character strings with a length equal to the number of pages in the file. So, our return value is loaded into R, but maybe not that useful yet because it is just a bunch of really long strings.\n\ntxt <- pdf_text(path)\n\nclass(txt)\n\n[1] \"character\"\n\n\nLuckily, there is a function that will turn the pdf text data we just read in to a form that is compatible with the rest of the tidytext tools. The tibble::enframe function, converts the list into a data.frame. We then change one column name to describe what the column actually is (page number).\n\ntxt_clean <- txt %>%\n enframe() %>% \n rename(page = name) \n\nWe can do the same analysis as above, unnesting the tokens and removing stop words to get the most frequent words:\n\npdf_summary <- txt_clean %>% \n unnest_tokens(output = word, input = value) %>%\n anti_join(stop_words) %>% \n count(word) %>% \n arrange(-n) %>% \n slice_head(n = 10)\n\nJoining with `by = join_by(word)`\n\n\n\n\n\n\n\n\n\nIf we look at the result, and then back at the original document, it is clear that there is more work needed to get the data to an analyzable state. The header and footer of each page of the PDF were included in the text we analyzed, and since they are repeated every page (and aren’t really the subject of our inquiry anyway), should be removed from the text after we read it into R but before we try to calculate the most used words. It might also be beneficial to try and separate out the questions from responses, if we wanted to analyze just the responses or just the questions.\nTo help us clean things up, first let’s split our value column currently containing full pages of text by where there are double newlines (\\n\\n). You can see in the original PDF how this demarcates the responses, which contain single newlines within each paragraph, and two new lines (an empty line) between paragraphs. You can see an example of this within the text we have read in by examining just the first 500 characters of the first page of data.\n\nsubstr(txt_clean$value[1], 1,500)\n\n[1] \" Population Dynamics in Greenland\\n Focus Group Meetings\\n\\nDate of the focus group meeting: Ilulissat April 10th, 2017\\nName and title of the Researchers: Q3: Dr. Elizabeth Rink & Q1: Dr. Gitte Adler\\nReimer\\nName of the facilitator: Q2: Majbritt Didriksen Raal\\nRecord No.: 170410_0077\\n\\nFG # 8\\n\\nQ2: Ilulissat the April 10th, 2017, we are going to talk to the Professional Group.\\n\\nQ1: Welcome, we are working on the final part of t\"\n\n\nTo split our character vectors, we will use the str_split function. It splits a character vector according to a separator, and stores the values in a list. To show more clearly, let’s look at a dummy example. We can split a string of comma separated numbers into a list with each individual number.\n\nx <- \"1,2,3,4,5\"\nstr_split(x, \",\")\n\n[[1]]\n[1] \"1\" \"2\" \"3\" \"4\" \"5\"\n\n\nIn the real dataset, we’ll use str_split and mutate, which will create a list of values within each row of the value column. So each cell in the value column contains a list of values like the result of the example above. We can “flatten” this data so that each cell only has one value by using the unnest function, which takes as arguments the columns to flatten. Let’s take the example above, and make it a little more like our real data.\nFirst turn the original dummy vector into a data frame, and do our split as before, this time using mutate.\n\nx_df <- data.frame(x = x) %>% \n mutate(x = str_split(x, \",\"))\nx_df\n\n x\n1 1, 2, 3, 4, 5\n\n\nThen you can run the unnest on the column of split values we just created.\n\nx_df_flat <- x_df %>% \n tidyr::unnest(cols = x)\n\nx_df_flat\n\n# A tibble: 5 × 1\n x \n <chr>\n1 1 \n2 2 \n3 3 \n4 4 \n5 5 \n\n\nNow that we know how this works, let’s do it on our dataset with the double newline character as the separator.\n\ntxt_clean <- txt_clean %>%\n mutate(value = str_split(value, \"\\n\\n\")) %>% \n tidyr::unnest(cols = value)\n\n\nDT::datatable(txt_clean, rownames = F)\n\n\n\n\n\n\nYou can see that our questions and answers are now easily visible because they all start with wither Q or A. The other lines are blank lines or header/footer lines from the document. So, let’s extract the first few characters of each line into a new column using substr, with the goal that we’ll run a filter for rows that start with Q or A, thus discarding all the other rows.\nFirst, we extract the first 4 characters of each row and using mutate create a new column with those values called id.\n\ntxt_clean <- txt_clean %>% \n mutate(id = substr(value, 1, 4))\n\nLet’s have a look at the unique values there:\n\nunique(txt_clean$id)\n\n [1] \" \" \"Date\" \"FG #\" \"Q2: \" \"Q1: \" \"A1: \" \"PDG \" \"A2: \" \"\\nQ2:\"\n[10] \"\\nQ2.\" \"\\nPDG\" \"\" \"A1 \" \"Q3: \" \n\n\nSo unfortunately some of the text is a tiny bit garbled, there are newlines before at least some Q and A ids. We can use mutate again with str_replace to replace those \\n with a blank value, which will remove them.\n\ntxt_clean <- txt_clean %>% \n mutate(id = substr(value, 1, 4)) %>% \n mutate(id = str_replace(id, \"\\n\", \"\"))\n\n\nunique(txt_clean$id)\n\n [1] \" \" \"Date\" \"FG #\" \"Q2: \" \"Q1: \" \"A1: \" \"PDG \" \"A2: \" \"Q2:\" \"Q2.\" \n[11] \"PDG\" \"\" \"A1 \" \"Q3: \"\n\n\nNow we will use substr again to get the first two characters of each id.\n\ntxt_clean <- txt_clean %>% \n mutate(id = substr(value, 1, 4)) %>% \n mutate(id = str_replace(id, \"\\n\", \"\")) %>% \n mutate(id = substr(id, 1, 2))\n\n\nunique(txt_clean$id)\n\n [1] \" \" \"Da\" \"FG\" \"Q2\" \"Q1\" \"A1\" \"PD\" \"A2\" \"\" \"Q3\"\n\n\nFinally, we can run the filter. Here, we filter for id values that start with either a Q or an A using the grepl function and a regular expression. We won’t go much into regular expression details, but there is a chapter in the appendix for more about how they work.\nHere is an example of grepl in action. It returns a true or false for whether the value of x starts with (signified by ^) a Q or A (signified by QA in square brackets).\n\nx <- c(\"Q3\", \"F1\", \"AAA\", \"FA\")\ngrepl(\"^[QA]\", x)\n\n[1] TRUE FALSE TRUE FALSE\n\n\nSo let’s run that within a filter which will return only rows where the grepl would return TRUE.\n\ntxt_clean <- txt_clean %>% \n mutate(id = substr(value, 1, 4)) %>% \n mutate(id = str_replace(id, \"\\n\", \"\")) %>% \n mutate(id = substr(id, 1, 2)) %>% \n filter(grepl(\"^[QA]\", id))\n\n\n\n\n\n\n\n\nFinally, as our last cleaning step we replace all instances of the start of a string that contains a Q or A, followed by a digit and a colon, with an empty string (removing them from the beginning of the line.\n\ntxt_clean <- txt_clean %>% \n mutate(id = substr(value, 1, 4)) %>% \n mutate(id = str_replace(id, \"\\n\", \"\")) %>% \n mutate(id = substr(id, 1, 2)) %>% \n filter(grepl(\"^[QA]\", id)) %>% \n mutate(value = str_replace_all(value, \"[QA][0-9]\\\\:\", \"\"))\n\n\n\n\n\n\n\n\nFinally, we can try the same analysis again as above to look for the most commonly used words.\n\npdf_summary <- txt_clean %>% \n unnest_tokens(output = word, input = value) %>%\n anti_join(stop_words) %>% \n count(word) %>% \n arrange(-n) %>% \n slice_head(n = 10)\n\nJoining with `by = join_by(word)`"
+ },
+ {
+ "objectID": "session_11.html#sentiment-analysis",
+ "href": "session_11.html#sentiment-analysis",
+ "title": "11 Working with Text Data in R",
+ "section": "11.2 Sentiment Analysis",
+ "text": "11.2 Sentiment Analysis\nIn sentiment analysis, tokens (in this case our single words) are evaluated against a dictionary of words where a sentiment is assigned to the word. There are many different sentiment lexicons, some with single words, some with more than one word, and some that are aimed at particular disciplines. When embarking on a sentiment analysis project, choosing your lexicon is one that should be done with care. Sentiment analysis can also be done using machine learning algorithms.\nWith that in mind, we will next do a very simple sentiment analysis on our Q3 and Q4 answers using the bing lexicon from Bing Liu and collaborators, which ships with the tidytext package.\nFirst we will use the get_sentiments function to load the lexicon.\n\nbing <- get_sentiments(\"bing\")\n\nNext we do an inner join to return the words from question 3 that are contained within the lexicon.\n\nq3_sent <- inner_join(q3, bing, by = \"word\")\n\n\n\n\n\n\n\n\nThere are a variety of directions you could go from here, analysis wise, such as calculating an overall sentiment index for that question, plotting sentiment against some other variable, or, making a fun word cloud like below! Here we bring in reshape2::acast to create a sentiment matrix for each word, and pass that into wordcloud::comparison.cloud to look at a wordcloud that indicates the frequency and sentiment of the words in our responses.\n\nq3_sent %>% \n count(word, sentiment, sort = TRUE) %>%\n acast(word ~ sentiment, value.var = \"n\", fill = 0) %>%\n comparison.cloud(colors = c(\"gray20\", \"gray80\"),\n max.words = 100, title.size = 2)\n\n\n\n\nLet’s look at the question 4 word cloud:\n\nq4 %>%\n inner_join(bing, by = \"word\") %>% \n count(word, sentiment, sort = TRUE) %>%\n acast(word ~ sentiment, value.var = \"n\", fill = 0) %>%\n comparison.cloud(colors = c(\"gray20\", \"gray80\"),\n max.words = 100, title.size = 2)"
+ },
+ {
+ "objectID": "session_11.html#summary",
+ "href": "session_11.html#summary",
+ "title": "11 Working with Text Data in R",
+ "section": "11.3 Summary",
+ "text": "11.3 Summary\nIn this lesson, we learned:\n\nhow to analyze structured text data from a survey using stop words and sentiment analysis\nhow to give structure to unstructured text data from a PDF to do some analysis using stop words and times words are used"
+ },
+ {
+ "objectID": "session_12.html#learning-objectives",
+ "href": "session_12.html#learning-objectives",
+ "title": "12 Working with US Census Data",
+ "section": "Learning Objectives",
+ "text": "Learning Objectives"
+ },
+ {
+ "objectID": "session_12.html#overview",
+ "href": "session_12.html#overview",
+ "title": "12 Working with US Census Data",
+ "section": "12.1 Overview",
+ "text": "12.1 Overview\n(Chapter 1 - 5 min) - General view of US Census Data"
+ },
+ {
+ "objectID": "session_12.html#introduction-to-tidycensus",
+ "href": "session_12.html#introduction-to-tidycensus",
+ "title": "12 Working with US Census Data",
+ "section": "12.2 Introduction to tidycensus",
+ "text": "12.2 Introduction to tidycensus\n(Chapter 2 - 25-30 min)\n\nBasic data requests\nFundamentals of data package and the options it offers"
+ },
+ {
+ "objectID": "session_12.html#getting-census-data-ready-for-analysis",
+ "href": "session_12.html#getting-census-data-ready-for-analysis",
+ "title": "12 Working with US Census Data",
+ "section": "12.3 Getting Census Data ready for analysis",
+ "text": "12.3 Getting Census Data ready for analysis\n(Chapter 3 - 20-25 min)\n\nData wranglw again? Yes!\nHandling errors in data"
+ },
+ {
+ "objectID": "session_12.html#visualizing-censis-data-with-ggplot2",
+ "href": "session_12.html#visualizing-censis-data-with-ggplot2",
+ "title": "12 Working with US Census Data",
+ "section": "12.4 Visualizing Censis Data with ggplot2",
+ "text": "12.4 Visualizing Censis Data with ggplot2\n(Chapter 4 - 20 min)"
+ },
+ {
+ "objectID": "session_12.html#maps-and-census-data",
+ "href": "session_12.html#maps-and-census-data",
+ "title": "12 Working with US Census Data",
+ "section": "12.5 Maps and Census Data",
+ "text": "12.5 Maps and Census Data\n( Chapter 5 and 6 - 10 min?)"
+ },
+ {
+ "objectID": "session_13.html",
+ "href": "session_13.html",
+ "title": "13 Reproducible Surveys",
+ "section": "",
+ "text": "13.0.1 Learning Objectives\n\nOverview of survey tools\nGenerating a reproducible survey report with Qualtrics\n\n\n\n13.0.2 Introduction\nSurveys and questionnaires are commonly used research methods within social science and other fields. For example, understanding regional and national population demographics, income, and education as part of the National Census activity, assessing audience perspectives on specific topics of research interest (e.g. the work by Tenopir and colleagues on Data Sharing by Scientists), evaluation of learning deliverables and outcomes, and consumer feedback on new and upcoming products. These are distinct from the use of the term survey within natural sciences, which might include geographical surveys (“the making of measurement in the field from which maps are drawn”), ecological surveys (“the process whereby a proposed development site is assess to establish any environmental impact the development may have”) or biodiversity surveys (“provide detailed information about biodiversity and community structure”) among others.\nAlthough surveys can be conducted on paper or verbally, here we focus on surveys done via software tools. Needs will vary according to the nature of the research being undertaken. However, there is fundamental functionality that survey software should provide including:\n\nThe ability to create and customize questions\nThe ability to include different types of questions\nThe ability to distribute the survey and manage response collection\nThe ability to collect, summarize, and (securely) store response data\n\nMore advanced features can include:\n\nVisual design and templates - custom design might include institutional branding or aesthetic elements. Templates allow you to save these designs and apply to other surveys\nQuestion piping - piping inserts answers from previous questions into upcoming questions and can personalize the survey experience for users\nSurvey logic - with question logic and skip logic you can control the inclusion / exclusion of questions based on previous responses\nRandomization - the ability to randomize the presentation of questions within (blocks of) the survey\nBranching - this allows for different users to take different paths through the survey. Similar to question logic but at a bigger scale\nLanguage support - automated translation or multi-language presentation support\nShared administration - enables collaboration on the survey and response analysis\nSurvey export - ability to download (export) the survey instrument\nReports - survey response visualization and reporting tools\nInstitutional IRB approved - institutional IRB policy may require certain software be used for research purposes\n\nCommonly used survey software within academic (vs market) research include Qualtrics, Survey Monkey and Google Forms. Both qualtrics and survey monkey are licensed (with limited functionality available at no cost) and google forms is free.\n\n\n\n13.0.3 Building workflows using Qualtrics\nIn this lesson we will use the qualtRics package to reproducible access some survey results set up for this course.\n\n13.0.3.1 Survey Instrument\nThe survey is very short, only four questions. The first question is on it’s own page and is a consent question, after a couple of short paragraphs describing what the survey is, it’s purpose, how long it will take to complete, and who is conducting it. This type of information is required if the survey is governed by an IRB, and the content will depend on the type of research being conducted. In this case, this survey is not for research purposes, and thus is not governed by IRB, but we still include this information as it conforms to the Belmont Principles. The Belmont Principles identify the basic ethical principles that should underlie research involving human subjects.\n\nThe three main questions of the survey have three types of responses: a multiple choice answer, a multiple choice answer which also includes an “other” write in option, and a free text answer. We’ll use the results of this survey, which was sent out to NCEAS staff to fill out, to learn about how to create a reproducible survey report.\n\nFirst, open a new RMarkdown document and add a chunk to load the libraries we’ll need for this lesson:\n\nlibrary(qualtRics)\nlibrary(tidyr)\nlibrary(knitr)\nlibrary(ggplot2)\nlibrary(kableExtra)\nlibrary(dplyr)\n\nNext, we need to set the API credentials. This function modifies the .Renviron file to set your API key and base URL so that you can access Qualtrics programmatically.\nThe API key is as good as a password, so care should be taken to not share it publicly. For example, you would never want to save it in a script. The function below is the rare exception of code that should be run in the console and not saved. It works in a way that you only need to run it once, unless you are working on a new computer or your credentials changed. Note that in this book, we have not shared the actual API key, for the reasons outlined above. You should have an e-mail with the API key in it. Copy and paste it as a string to the api_key argument in the function below:\n\nqualtrics_api_credentials(api_key = \"\", base_url = \"ucsb.co1.qualtrics.com\", install = TRUE)\n\n\n\nAside\nThe .Renviron file is a special user controlled file that can create environment variables. Every time you open Rstudio, the variables in your environment file are loaded as…environment variables! Environment variables are named values that are accessible by your R process. They will not show up in your environment pane, but you can get a list of all of them using Sys.getenv(). Many are system defaults.\n\n\n\nTo view or edit your .Renviron file, you can use usethis::edit_r_environ().\nTo get a list of all the surveys in your Qualtrics instance, use the all_surveys function.\n\nsurveys <- all_surveys()\nkable(surveys) %>%\n kable_styling()\n\nThis function returns a list of surveys, in this case only one, and information about each, including an identifier and it’s name. We’ll need that identifier later, so let’s go ahead and extract it using base R from the data frame.\n\ni <- which(surveys$name == \"Survey for Data Science Training\")\nid <- surveys$id[i]\n\nYou can retrieve a list of the questions the survey asked using the survey_questions function and the survey id.\n\nquestions <- survey_questions(id)\nkable(questions) %>%\n kable_styling()\n\nThis returns a data.frame with one row per question with columns for question id, question name, question text, and whether the question was required. This is helpful to have as a reference for when you are looking at the full survey results.\nTo get the full survey results, run fetch_survey with the survey id.\n\nsurvey_results <- fetch_survey(id)\n\nThe survey results table has tons of information in it, not all of which will be relevant depending on your survey. The table has identifying information for the respondents (eg: ResponseID, IPaddress, RecipientEmail, RecipientFirstName, etc), much of which will be empty for this survey since it is anonymous. It also has information about the process of taking the survey, such as the StartDate, EndDate, Progress, and Duration. Finally, there are the answers to the questions asked, with columns labeled according to the qname column in the questions table (eg: Q1, Q2, Q3). Depending on the type of question, some questions might have multiple columns associated with them. We’ll have a look at this more closely in a later example.\n\n\nQuestion 2\nLet’s look at the responses to the second question in the survey, “How long have you been programming?” Remember, the first question was the consent question.\nWe’ll use the dplyr and tidyr tools we learned earlier to extract the information. Here are the steps:\n\nselect the column we want (Q1)\ngroup_by and summarize the values\n\n\nq2 <- survey_results %>% \n select(Q2) %>% \n group_by(Q2) %>% \n summarise(n = n())\n\nWe can show these results in a table using the kable function from the knitr package:\n\nkable(q2, col.names = c(\"How long have you been programming?\",\n \"Number of responses\")) %>%\n kable_styling()\n\n\n\n13.0.3.2 Question 3\nFor question 3, we’ll use a similar workflow. For this question, however there are two columns containing survey answers. One contains the answers from the controlled vocabulary, the other contains any free text answers users entered.\nTo present this information, we’ll first show the results of the controlled answers as a plot. Below the plot, we’ll include a table showing all of the free text answers for the “other” option.\n\nq3 <- survey_results %>% \n select(Q3) %>% \n group_by(Q3) %>% \n summarise(n = n())\n\n\nggplot(data = q3, mapping = aes(x = Q3, y = n)) +\n geom_col() +\n labs(x = \"What language do you currently use most frequently?\", y = \"Number of reponses\") +\n theme_minimal()\n\nNow we’ll extract the free text responses:\n\nq3_text <- survey_results %>% \n select(Q3_7_TEXT) %>% \n drop_na()\n\nkable(q3_text, col.names = c(\"Other responses to 'What language do you currently use mose frequently?'\")) %>% \n kable_styling()\n\n\n\n13.0.3.3 Question 4\nThe last question is just a free text question, so we can just display the results as is.\n\nq4 <- survey_results %>% \n select(Q4) %>% \n rename(`What data science tool or language are you most excited to learn next?` = Q4) %>% \n drop_na()\n\nkable(q4, col.names = \"What data science tool or language are you most excited to learn next?\") %>% \n kable_styling()\n\n\n\n\n13.0.4 Other survey tools\n\nGoogle forms\nGoogle forms can be a great way to set up surveys, and it is very easy to interact with the results using R. The benefits of using google forms are a simple interface and easy sharing between collaborators, especially when writing the survey instrument.\nThe downside is that google forms has far fewer features than Qualtrics in terms of survey flow and appearance.\nTo show how we can link R into our survey workflows, I’ve set up a simple example survey here.\nI’ve set up the results so that they are in a new spreadsheet here:. To access them, we will use the googlesheets4 package.\nFirst, open up a new R script and load the googlesheets4 library:\n\nlibrary(googlesheets4)\n\nNext, we can read the sheet in using the same URL that you would use to share the sheet with someone else. Right now, this sheet is public\n\nresponses <- read_sheet(\"https://docs.google.com/spreadsheets/d/1CSG__ejXQNZdwXc1QK8dKouxphP520bjUOnZ5SzOVP8/edit?usp=sharing\")\n\n✔ Reading from \"Example Survey Form (Responses)\".\n\n\n✔ Range 'Form Responses 1'.\n\n\nThe first time you run this, you should get a popup window in your web browser asking you to confirm that you want to provide access to your google sheets via the tidyverse (googlesheets) package.\nMy dialog box looked like this:\n\nMake sure you click the third check box enabling the Tidyverse API to see, edit, create, and delete your sheets. Note that you will have to tell it to do any of these actions via the R code you write.\nWhen you come back to your R environment, you should have a data frame containing the data in your sheet! Let’s take a quick look at the structure of that sheet.\n\ndplyr::glimpse(responses)\n\nRows: 10\nColumns: 5\n$ Timestamp <dttm> 2022-04-15 13:…\n$ `To what degree did the event meet your expectations?` <chr> \"Met expectatio…\n$ `To what degree did your knowledge improve?` <chr> \"Increase\", \"Si…\n$ `What did you like most about the event?` <chr> \"the cool instr…\n$ `What might you change about the event?` <chr> \"more snacks\", …\n\n\nSo, now that we have the data in a standard R data.frame, we can easily summarize it and plot results. By default, the column names in the sheet are the long fully descriptive questions that were asked, which can be hard to type. We can save those questions into a vector for later reference, like when we want to use the question text for plot titles.\n\nquestions <- colnames(responses)[2:5]\ndplyr::glimpse(questions)\n\n chr [1:4] \"To what degree did the event meet your expectations?\" ...\n\n\nWe can make the responses data frame more compact by renaming the columns of the vector with short numbered names of the form Q1. Note that, by using a sequence, this should work for sheets from just a few columns to many hundreds of columns, and provides a consistent question naming convention.\n\nnames(questions) <- paste0(\"Q\", seq(1:4))\ncolnames(responses) <- c(\"Timestamp\", names(questions))\ndplyr::glimpse(responses)\n\nRows: 10\nColumns: 5\n$ Timestamp <dttm> 2022-04-15 13:48:58, 2022-04-15 13:49:43, 2022-04-15 13:50:…\n$ Q1 <chr> \"Met expectations\", \"Above expectations\", \"Above expectation…\n$ Q2 <chr> \"Increase\", \"Significant increase\", \"Significant increase\", …\n$ Q3 <chr> \"the cool instructors\", \"R is rad!\", \"everything\", \"the pizz…\n$ Q4 <chr> \"more snacks\", \"no pineapple pizza!\", \"nothing\", \"needs more…\n\n\nNow that we’ve renamed our columns, let’s summarize the responses for the first question. We can use the same pattern that we usually do to split the data from Q1 into groups, then summarize it by counting the number of records in each group, and then merge the count of each group back together into a summarized data frame. We can then plot the Q1 results using ggplot:\n\nq1 <- responses %>% \n dplyr::select(Q1) %>% \n dplyr::group_by(Q1) %>% \n dplyr::summarise(n = dplyr::n())\n\nggplot2::ggplot(data = q1, mapping = aes(x = Q1, y = n)) +\n geom_col() +\n labs(x = questions[1], \n y = \"Number of reponses\",\n title = \"To what degree did the course meet expectations?\") +\n theme_minimal()\n\n\nBypassing authentication for public sheets\nIf you don’t want to go through a little interactive dialog every time you read in a sheet, and your sheet is public, you can run the function gs4_deauth() to access the sheet as a public user. This is helpful for cases when you want to run your code non-interactively. This is actually how I set it up for this book to build!\n\n\nChallenge\nNow that you have some background in accessing survey data from common tools, let’s do a quick exercise with Google Sheets. First, create a google sheet with the following columns that reflect a hypothetical survey result:\n\nTimestamp\nQ1: How much did your proficiency with survey tools in R change? 1 = None, 2 = A little, 3 = A lot\nQ2: How many years or partial years had you used R prior to this course?\nQ3: How many years or partial years had you used statistics before this course?\n\nNext populate the spreadhsheet with 5 to 10 rows of sample data that you make up. Now that you have the Google sheet in place, copy its URL and use it to do the following in R:\n\nLoad the google sheet into an R data.frame using the googlesheets package\nSave the column headers as a vector of questions\nRename the question columns with short, consistent names\nSummarize and plot the results for Q1 as a bar chart.\n\n\n\n\nSurvey Monkey\nSimilar to Qualtrics and qualtRics, there is an open source R package for working with data in Survey Monkey: Rmonkey. However, the last updates were made 5 years ago, an eternity in the software world, so it may or may not still function as intended.\nThere are also commercial options available. For example, cdata have a driver and R package that enable access to an analysis of Survey Monkey data through R."
+ },
+ {
+ "objectID": "session_14.html",
+ "href": "session_14.html",
+ "title": "14 Guest Speaker",
+ "section": "",
+ "text": "Add material"
+ },
+ {
+ "objectID": "session_16.html",
+ "href": "session_16.html",
+ "title": "16 Shiny",
+ "section": "",
+ "text": "16.0.1 Learning Objectives\nIn this lesson we will:\n\nreview the capabilities in Shiny applications\nlearn about the basic layout for Shiny interfaces\nlearn about the server component for Shiny applications\nbuild a simple shiny application for interactive plotting\n\n\n\n16.0.2 Overview\nShiny is an R package for creating interactive data visualizations embedded in a web application that you and your colleagues can view with just a web browser. Shiny apps are relatively easy to construct, and provide interactive features for letting others share and explore data and analyses.\nThere are some really great examples of what Shiny can do on the RStudio webite like this one exploring movie metadata. A more scientific example is a tool from the SASAP project exploring proposal data from the Alaska Board of Fisheries. There is also an app for Delta monitoring efforts.\n\nMost any kind of analysis and visualization that you can do in R can be turned into a useful interactive visualization for the web that lets people explore your data more intuitively But, a Shiny application is not the best way to preserve or archive your data. Instead, for preservation use a repository that is archival in its mission like the KNB Data Repository, Zenodo, or Dryad. This will assign a citable identifier to the specific version of your data, which you can then read in an interactive visualiztion with Shiny.\nFor example, the data for the Alaska Board of Fisheries application is published on the KNB and is citable as:\nMeagan Krupa, Molly Cunfer, and Jeanette Clark. 2017. Alaska Board of Fisheries Proposals 1959-2016. Knowledge Network for Biocomplexity. doi:10.5063/F1QN652R.\nWhile that is the best citation and archival location of the dataset, using Shiny, one can also provide an easy-to-use exploratory web application that you use to make your point that directly loads the data from the archival site. For example, the Board of Fisheries application above lets people who are not inherently familiar with the data to generate graphs showing the relationships between the variables in the dataset.\nWe’re going to create a simple shiny app with two sliders so we can interactively control inputs to an R function. These sliders will allow us to interactively control a plot.\n\n\n16.0.3 Create a sample shiny application\n\nFile > New > Shiny Web App…\nSet some fields: \n\nName it “myapp” or something else\nSelect “Single File”\nChoose to create it in a new folder called ‘shiny-demo’\nClick Create\n\n\nRStudio will create a new file called app.R that contains the Shiny application.\nRun it by choosing Run App from the RStudio editor header bar. This will bring up the default demo Shiny application, which plots a histogram and lets you control the number of bins in the plot.\n\nNote that you can drag the slider to change the number of bins in the histogram.\n\n\n16.0.4 Shiny architecture\nA Shiny application consists of two functions, the ui and the server. The ui function is responsible for drawing the web page, while the server is responsible for any calculations and for creating any dynamic components to be rendered.\nEach time that a user makes a change to one of the interactive widgets, the ui grabs the new value (say, the new slider min and max) and sends a request to the server to re-render the output, passing it the new input values that the user had set. These interactions can sometimes happen on one computer (e.g., if the application is running in your local RStudio instance). Other times, the ui runs on the web browser on one computer, while the server runs on a remote computer somewhere else on the Internet (e.g., if the application is deployed to a web server).\n\n\n\n16.0.5 Interactive scatterplots\nLet’s modify this application to plot Yolo bypass secchi disk data in a time-series, and allow aspects of the plot to be interactively changed.\n\n16.0.5.1 Load data for the example\nUse this code to load the data at the top of your app.R script. Note we are using contentId again, and we have filtered for some species of interest.\n\nlibrary(shiny)\nlibrary(contentid)\nlibrary(dplyr)\nlibrary(ggplot2)\nlibrary(lubridate)\n\nsha1 <- 'hash://sha1/317d7f840e598f5f3be732ab0e04f00a8051c6d0'\ndelta.file <- contentid::resolve(sha1, registries=c(\"dataone\"), store = TRUE)\n\n# fix the sample date format, and filter for species of interest\ndelta_data <- read.csv(delta.file) %>% \n mutate(SampleDate = mdy(SampleDate)) %>% \n filter(grepl(\"Salmon|Striped Bass|Smelt|Sturgeon\", CommonName))\n\nnames(delta_data)\n\n\n\n16.0.5.2 Add a simple timeseries using ggplot\nWe know there has been a lot of variation through time in the delta, so let’s plot a time-series of Secchi depth. We do so by switching out the histogram code for a simple ggplot, like so:\n\nserver <- function(input, output) {\n \n output$distPlot <- renderPlot({\n \n ggplot(delta_data, mapping = aes(SampleDate, Secchi)) +\n geom_point(colour=\"red\", size=4) +\n theme_light()\n })\n}\n\nIf you now reload the app, it will display the simple time-series instead of the histogram. At this point, we haven’t added any interactivity.\nIn a Shiny application, the server function provides the part of the application that creates our interactive components, and returns them to the user interface (ui) to be displayed on the page.\n\n\n16.0.5.3 Add sliders to set the start and end date for the X axis\nTo make the plot interactive, first we need to modify our user interface to include widgits that we’ll use to control the plot. Specifically, we will add a new slider for setting the minDate parameter, and modify the existing slider to be used for the maxDate parameter. To do so, modify the sidebarPanel() call to include two sliderInput() function calls:\n\nsidebarPanel(\n sliderInput(\"minDate\",\n \"Min Date:\",\n min = as.Date(\"1998-01-01\"),\n max = as.Date(\"2020-01-01\"),\n value = as.Date(\"1998-01-01\")),\n sliderInput(\"maxDate\",\n \"Max Date:\",\n min = as.Date(\"1998-01-01\"),\n max = as.Date(\"2020-01-01\"),\n value = as.Date(\"2005-01-01\"))\n)\n\nIf you reload the app, you’ll see two new sliders, but if you change them, they don’t make any changes to the plot. Let’s fix that.\n\n\n16.0.5.4 Connect the slider values to the plot\nFinally, to make the plot interactive, we can use the input and output variables that are passed into the server function to access the current values of the sliders. In Shiny, each UI component is given an input identifier when it is created, which is used as the name of the value in the input list. So, we can access the minimum depth as input$minDate and the max as input$maxDate. Let’s use these values now by adding limits to our X axis in the ggplot:\n\n ggplot(delta_data, mapping = aes(SampleDate, Secchi)) +\n geom_point(colour=\"red\", size=4) +\n xlim(c(input$minDate,input$maxDate)) +\n theme_light()\n\nAt this point, we have a fully interactive plot, and the sliders can be used to change the min and max of the Depth axis.\n\nLooks so shiny!\n\n\n16.0.5.5 Reversed Axes?\nWhat happens if a clever user sets the minimum for the X axis at a greater value than the maximum? You’ll see that the direction of the X axis becomes reversed, and the plotted points display right to left. This is really an error condition. Rather than use two independent sliders, we can modify the first slider to output a range of values, which will prevent the min from being greater than the max. You do so by setting the value of the slider to a vector of length 2, representing the default min and max date for the slider, such as c(as.Date(\"1998-01-01\"), as.Date(\"2020-01-01\")). So, delete the second slider, rename the first, and provide a vector for the value, like this:\n\nsliderInput(\"date\",\n \"Date:\",\n min = as.Date(\"1998-01-01\"),\n max = as.Date(\"2020-01-01\"),\n value = c(as.Date(\"1998-01-01\"), as.Date(\"2020-01-01\")))\n)\n\nNow, modify the ggplot to use this new date slider value, which now will be returned as a vector of length 2. The first element of the depth vector is the min, and the second is the max value on the slider.\n\n ggplot(delta_data, mapping = aes(SampleDate, Secchi)) +\n geom_point(colour=\"red\", size=4) +\n xlim(c(input$date[1],input$date[2])) +\n theme_light()\n\n\n\n\n\n16.0.6 Extending the user interface with dynamic plots\nIf you want to display more than one plot in your application, and provide a different set of controls for each plot, the current layout would be too simple. Next we will extend the application to break the page up into vertical sections, and add a new plot in which the user can choose which variables are plotted. The current layout is set up such that the FluidPage contains the title element, and then a sidebarLayout, which is divided horizontally into a sidebarPanel and a mainPanel.\n\n\n16.0.6.1 Vertical layout\nTo extend the layout, we will first nest the existing sidebarLayout in a new verticalLayout, which simply flows components down the page vertically. Then we will add a new sidebarLayout to contain the bottom controls and graph.\n\nThis mechanism of alternately nesting vertical and horizontal panels can be used to segment the screen into boxes with rules about how each of the panels is resized, and how the content flows when the browser window is resized. The sidebarLayout works to keep the sidebar about 1/3 of the box, and the main panel about 2/3, which is a good proportion for our controls and plots. Add the verticalLayout, and the second sidebarLayout for the second plot as follows:\n\n verticalLayout(\n # Sidebar with a slider input for depth axis\n sidebarLayout(\n sidebarPanel(\n sliderInput(\"date\",\n \"Date:\",\n min = as.Date(\"1998-01-01\"),\n max = as.Date(\"2020-01-01\"),\n value = c(as.Date(\"1998-01-01\"), as.Date(\"2020-01-01\")))\n ),\n # Show a plot of the generated distribution\n mainPanel(\n plotOutput(\"distPlot\")\n )\n ),\n\n tags$hr(),\n\n sidebarLayout(\n sidebarPanel(\n selectInput(\"x_variable\", \"X Variable\", cols, selected = \"SampleDate\"),\n selectInput(\"y_variable\", \"Y Variable\", cols, selected = \"Count\"),\n selectInput(\"color_variable\", \"Color\", cols, selected = \"CommonName\")\n ),\n\n # Show a plot with configurable axes\n mainPanel(\n plotOutput(\"varPlot\")\n )\n ),\n tags$hr()\n\nNote that the second sidebarPanel uses three selectInput elements to provide dropdown menus with the variable columns (cols) from our data frame. To manage that, we need to first set up the cols variable, which we do by saving the variables names from the delta_data data frame to a variable:\n\nsha1 <- 'hash://sha1/317d7f840e598f5f3be732ab0e04f00a8051c6d0'\ndelta.file <- contentid::resolve(sha1, registries=c(\"dataone\"), store = TRUE)\n\n# fix the sample date format, and filter for species of interest\ndelta_data <- read.csv(delta.file) %>% \n mutate(SampleDate = mdy(SampleDate)) %>% \n filter(grepl(\"Salmon|Striped Bass|Smelt|Sturgeon\", CommonName))\n\ncols <- names(delta_data)\n\n\n\n16.0.6.2 Add the dynamic plot\nBecause we named the second plot varPlot in our UI section, we now need to modify the server to produce this plot. Its very similar to the first plot, but this time we want to use the selected variables from the user controls to choose which variables are plotted. These variable names from the $input are character strings, and so would not be recognized as symbols in the aes mapping in ggplot. As recommended by the tidyverse authors, we use the non-standard evaluation syntax of .data[[\"colname\"]] to access the variables.\n\n output$varPlot <- renderPlot({\n ggplot(delta_data, aes(x = .data[[input$x_variable]],\n y = .data[[input$y_variable]],\n color = .data[[input$color_variable]])) +\n geom_point(size = 4)+\n theme_light()\n })\n\n\n\n\n16.0.7 Finishing touches: data citation\nCiting the data that we used for this application is the right thing to do, and easy. You can add arbitrary HTML to the layout using utility functions in the tags list.\n\n # Application title\n titlePanel(\"Yolo Bypass Fish and Water Quality Data\"),\n p(\"Data for this application are from: \"),\n tags$ul(\n tags$li(\"Interagency Ecological Program: Fish catch and water quality data from the Sacramento River floodplain and tidal slough, collected by the Yolo Bypass Fish Monitoring Program, 1998-2018.\",\n tags$a(\"doi:10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f\", href=\"http://doi.org/10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f\")\n )\n ),\n tags$br(),\n tags$hr(),\n\nThe final application shows the data citation, the depth plot, and the configurable scatterplot in three distinct panels.\n\n\n\n16.0.8 Publishing Shiny applications\nOnce you’ve finished your app, you’ll want to share it with others. To do so, you need to publish it to a server that is set up to handle Shiny apps.\nYour main choices are:\n\nshinyapps.io (Hosted by RStudio)\n\nThis is a service offered by RStudio, which is initially free for 5 or fewer apps and for limited run time, but has paid tiers to support more demanding apps. You can deploy your app using a single button push from within RStudio.\n\nShiny server (On premises)\n\nThis is an open source server which you can deploy for free on your own hardware. It requires more setup and configuration, but it can be used without a fee.\n\nRStudio connect (On premises)\n\nThis is a paid product you install on your local hardware, and that contains the most advanced suite of services for hosting apps and RMarkdown reports. You can publish using a single button click from RStudio.\n\n\nA comparison of publishing features is available from RStudio.\n\n16.0.8.1 Publishing to shinyapps.io\nThe easiest path is to create an account on shinyapps.io, and then configure RStudio to use that account for publishing. Instructions for enabling your local RStudio to publish to your account are displayed when you first log into shinyapps.io:\n\nOnce your account is configured locally, you can simply use the Publish button from the application window in RStudio, and your app will be live before you know it!\n\n\n\n\n16.0.9 Summary\nShiny is a fantastic way to quickly and efficiently provide data exploration for your data and code. We highly recommend it for its interactivity, but an archival-quality repository is the best long-term home for your data and products. In this example, we used data drawn directly from the EDI repository in our Shiny app, which offers both the preservation guarantees of an archive, plus the interactive data exploration from Shiny. You can utilize the full power of R and the tidyverse for writing your interactive applications.\n\n\n16.0.10 Full source code for the final application\n\nlibrary(shiny)\nlibrary(contentid)\nlibrary(dplyr)\nlibrary(ggplot2)\nlibrary(lubridate)\n\n# read in the data from EDI\nsha1 <- 'hash://sha1/317d7f840e598f5f3be732ab0e04f00a8051c6d0'\ndelta.file <- contentid::resolve(sha1, registries=c(\"dataone\"), store = TRUE)\n\n# fix the sample date format, and filter for species of interest\ndelta_data <- read.csv(delta.file) %>% \n mutate(SampleDate = mdy(SampleDate)) %>% \n filter(grepl(\"Salmon|Striped Bass|Smelt|Sturgeon\", CommonName))\n\ncols <- names(delta_data)\n \n\n\n# Define UI for application that draws a two plots\nui <- fluidPage(\n \n # Application title and data source\n titlePanel(\"Sacramento River floodplain fish and water quality dataa\"),\n p(\"Data for this application are from: \"),\n tags$ul(\n tags$li(\"Interagency Ecological Program: Fish catch and water quality data from the Sacramento River floodplain and tidal slough, collected by the Yolo Bypass Fish Monitoring Program, 1998-2018.\",\n tags$a(\"doi:10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f\", href=\"http://doi.org/10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f\")\n )\n ),\n tags$br(),\n tags$hr(),\n \n verticalLayout(\n # Sidebar with a slider input for time axis\n sidebarLayout(\n sidebarPanel(\n sliderInput(\"date\",\n \"Date:\",\n min = as.Date(\"1998-01-01\"),\n max = as.Date(\"2020-01-01\"),\n value = c(as.Date(\"1998-01-01\"), as.Date(\"2020-01-01\")))\n ),\n # Show a plot of the generated timeseries\n mainPanel(\n plotOutput(\"distPlot\")\n )\n ),\n \n tags$hr(),\n \n sidebarLayout(\n sidebarPanel(\n selectInput(\"x_variable\", \"X Variable\", cols, selected = \"SampleDate\"),\n selectInput(\"y_variable\", \"Y Variable\", cols, selected = \"Count\"),\n selectInput(\"color_variable\", \"Color\", cols, selected = \"CommonName\")\n ),\n \n # Show a plot with configurable axes\n mainPanel(\n plotOutput(\"varPlot\")\n )\n ),\n tags$hr()\n )\n)\n\n# Define server logic required to draw the two plots\nserver <- function(input, output) {\n \n # turbidity plot\n output$distPlot <- renderPlot({\n \n ggplot(delta_data, mapping = aes(SampleDate, Secchi)) +\n geom_point(colour=\"red\", size=4) +\n xlim(c(input$date[1],input$date[2])) +\n theme_light()\n })\n \n # mix and match plot\n output$varPlot <- renderPlot({\n ggplot(delta_data, aes(x = .data[[input$x_variable]],\n y = .data[[input$y_variable]],\n color = .data[[input$color_variable]])) +\n geom_point(size = 4) +\n theme_light()\n })\n}\n\n\n# Run the application \nshinyApp(ui = ui, server = server)\n\n\n\n16.0.11 A shinier app with tabs and a map!\n\nlibrary(shiny)\nlibrary(contentid)\nlibrary(dplyr)\nlibrary(tidyr)\nlibrary(ggplot2)\nlibrary(lubridate)\nlibrary(shinythemes)\nlibrary(sf)\nlibrary(leaflet)\nlibrary(snakecase)\n\n# read in the data from EDI\nsha1 <- 'hash://sha1/317d7f840e598f5f3be732ab0e04f00a8051c6d0'\ndelta.file <- contentid::resolve(sha1, registries=c(\"dataone\"), store = TRUE)\n\n# fix the sample date format, and filter for species of interest\ndelta_data <- read.csv(delta.file) %>% \n mutate(SampleDate = mdy(SampleDate)) %>% \n filter(grepl(\"Salmon|Striped Bass|Smelt|Sturgeon\", CommonName)) %>% \n rename(DissolvedOxygen = DO,\n Ph = pH,\n SpecificConductivity = SpCnd)\n\ncols <- names(delta_data)\n\nsites <- delta_data %>% \n distinct(StationCode, Latitude, Longitude) %>% \n drop_na() %>% \n st_as_sf(coords = c('Longitude','Latitude'), crs = 4269, remove = FALSE)\n\n\n\n# Define UI for application\nui <- fluidPage(\n navbarPage(theme = shinytheme(\"flatly\"), collapsible = TRUE,\n HTML('<a style=\"text-decoration:none;cursor:default;color:#FFFFFF;\" class=\"active\" href=\"#\">Sacramento River Floodplain Data</a>'), id=\"nav\",\n windowTitle = \"Sacramento River floodplain fish and water quality data\",\n \n tabPanel(\"Data Sources\",\n verticalLayout(\n # Application title and data source\n titlePanel(\"Sacramento River floodplain fish and water quality data\"),\n p(\"Data for this application are from: \"),\n tags$ul(\n tags$li(\"Interagency Ecological Program: Fish catch and water quality data from the Sacramento River floodplain and tidal slough, collected by the Yolo Bypass Fish Monitoring Program, 1998-2018.\",\n tags$a(\"doi:10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f\", href=\"http://doi.org/10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f\")\n )\n ),\n tags$br(),\n tags$hr(),\n p(\"Map of sampling locations\"),\n mainPanel(leafletOutput(\"map\"))\n )\n ),\n \n tabPanel(\n \"Explore\",\n verticalLayout(\n mainPanel(\n plotOutput(\"distPlot\"),\n width = 12,\n absolutePanel(id = \"controls\",\n class = \"panel panel-default\",\n top = 175, left = 75, width = 300, fixed=TRUE,\n draggable = TRUE, height = \"auto\",\n sliderInput(\"date\",\n \"Date:\",\n min = as.Date(\"1998-01-01\"),\n max = as.Date(\"2020-01-01\"),\n value = c(as.Date(\"1998-01-01\"), as.Date(\"2020-01-01\")))\n \n )\n ),\n \n tags$hr(),\n \n sidebarLayout(\n sidebarPanel(\n selectInput(\"x_variable\", \"X Variable\", cols, selected = \"SampleDate\"),\n selectInput(\"y_variable\", \"Y Variable\", cols, selected = \"Count\"),\n selectInput(\"color_variable\", \"Color\", cols, selected = \"CommonName\")\n ),\n \n # Show a plot with configurable axes\n mainPanel(\n plotOutput(\"varPlot\")\n )\n ),\n tags$hr()\n )\n )\n )\n)\n\n# Define server logic required to draw the two plots\nserver <- function(input, output) {\n \n \n output$map <- renderLeaflet({leaflet(sites) %>% \n addTiles() %>% \n addCircleMarkers(data = sites,\n lat = ~Latitude,\n lng = ~Longitude,\n radius = 10, # arbitrary scaling\n fillColor = \"gray\",\n fillOpacity = 1,\n weight = 0.25,\n color = \"black\",\n label = ~StationCode)\n })\n \n # turbidity plot\n output$distPlot <- renderPlot({\n \n ggplot(delta_data, mapping = aes(SampleDate, Secchi)) +\n geom_point(colour=\"red\", size=4) +\n xlim(c(input$date[1],input$date[2])) +\n labs(x = \"Sample Date\", y = \"Secchi Depth (m)\") +\n theme_light()\n })\n \n # mix and match plot\n output$varPlot <- renderPlot({\n ggplot(delta_data, mapping = aes(x = .data[[input$x_variable]],\n y = .data[[input$y_variable]],\n color = .data[[input$color_variable]])) +\n labs(x = to_any_case(input$x_variable, case = \"title\"),\n y = to_any_case(input$y_variable, case = \"title\"),\n color = to_any_case(input$color_variable, case = \"title\")) +\n geom_point(size=4) +\n theme_light()\n })\n}\n\n\n# Run the application \nshinyApp(ui = ui, server = server)\n\n\n\n16.0.12 Resources\n\nMain Shiny site\nOfficial Shiny Tutorial"
+ },
+ {
+ "objectID": "session_17.html",
+ "href": "session_17.html",
+ "title": "17 Appendix",
+ "section": "",
+ "text": "Configuring Two-factor Authentication on GitHub"
+ },
+ {
+ "objectID": "session_17.html#learning-objectives",
+ "href": "session_17.html#learning-objectives",
+ "title": "17 Appendix",
+ "section": "Learning Objectives",
+ "text": "Learning Objectives\n\nSuccessfully setup two-factor authentication on GitHub\nRecognize two-factor authentication jargon"
+ },
+ {
+ "objectID": "session_17.html#why-set-up-two-factor-authentication-2fa",
+ "href": "session_17.html#why-set-up-two-factor-authentication-2fa",
+ "title": "17 Appendix",
+ "section": "17.1 Why Set up Two-factor Authentication (2FA)",
+ "text": "17.1 Why Set up Two-factor Authentication (2FA)\n\nPrevents unauthorized access\nStrengthens your web security, especially if you have a compromised password\nIt is an increasing requirement for most websites and online applications or services\n\nIn March 2023, GitHub announced that it will require 2FA for “all developers who contribute code on GitHub.com” (GitHub Blog). This rollout will be completed by the end of 2023.\nAll users have the flexibility to use their preferred 2FA method, including: TOTP, SMS, security keys, or GitHub Mobile app. GitHub strongly recommends using security keys and TOTPs. While SMS-based 2FA is available to use, it does not provide the same level of protection, and is no longer recommended under NIST (National Institute of Standards and Technology) 800-63B.\n\n17.1.1 Additional information about 2FA on GitHub:\n\nSecuring your account with two-factor authentication (2FA)\nConfiguring two-factor authentication\nRaising the bar for software security: GitHub 2FA begins March 13\nSoftware security starts with the developer: Securing developer accounts with 2FA\n\n\n\n\n\n\n\nFor Your Reference\n\n\n\nReview the Glossary table to see a comprehensive list of two-factor authentication related terms and definitions"
+ },
+ {
+ "objectID": "session_17.html#steps-for-configuring-2fa-using-a-totp-app",
+ "href": "session_17.html#steps-for-configuring-2fa-using-a-totp-app",
+ "title": "17 Appendix",
+ "section": "17.2 Steps for Configuring 2FA Using a TOTP App",
+ "text": "17.2 Steps for Configuring 2FA Using a TOTP App\n\n\n\n\n\n\nAdditional Resource\n\n\n\nGitHub outlines these steps online in an article: Configuring two-factor authentication.\n\n\n\nDownload a TOTP app\nNavigate to your account Settings (click your profile photo in the top right-hand corner)\nIn the “Access” section, click “Password and Authenticate”\nIn the “Two-factor authentication” section, click Enable two-factor authentication\nUnder “Setup authenticator app”, either:\n\nScan the QR code with your TOTP app. After scanning, the app displays a six-digit code that you can enter on GitHub\nIf you can’t scan the QR code, click “enter this text code” to see a code that you can manually enter in your TOTP app instead\n\nOn GitHub, type the code into the field under “Verify the code from the app”\nUnder “Save your recovery codes”, click “Download” to download your recovery codes. Save them to a secure location because your recovery codes can help you get back into your account if you lose access.\n\nAfter saving your two-factor recovery codes, click “I have saved my recovery codes” to enable two-factor authentication for your account\n\nConfigure additional 2FA methods, if desired"
+ },
+ {
+ "objectID": "session_17.html#glossary",
+ "href": "session_17.html#glossary",
+ "title": "17 Appendix",
+ "section": "17.3 Glossary",
+ "text": "17.3 Glossary\n\n\n\n\n\n\n\nTerm\nDefinition\n\n\n\n\nQuick Response (QR) Code\nA type of two-dimensional matrix barcode that contains specific information\n\n\nRecovery Code\nA unique code(s) used to reset passwords or regain access to accounts\n\n\nShort Message Service (SMS)\nA text messaging service that allows mobile devices to exchange short text messages\n\n\nTime-based one-time password (TOTP)\nA string of unique codes that changes based on time. Often, these appear as six-digit numbers that regenerate every 30 seconds\n\n\nTwo-factor Authentication (2FA)\nAn identity and access management security method that requires two forms of identification to access accounts, resources, or data"
+ }
+]
\ No newline at end of file
diff --git a/public/session_01.html b/public/session_01.html
new file mode 100644
index 00000000..d48f4c0b
--- /dev/null
+++ b/public/session_01.html
@@ -0,0 +1,961 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 1 Collaborating using Git and GitHub & Merge Conflicts
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
1Collaborating using Git and GitHub & Merge Conflicts
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Learning Objectives
+
+
Apply the principles, features, and collaboration tools of Git and GitHub to effectively collaborate with colleagues on code
+
Analyze and evaluate common causes of conflicts that arise when collaborating on repositories
+
Demonstrate the ability to resolve conflicts using Git conflict resolution techniques
+
Apply workflows and best practices that minimize conflicts on collaborative repositories
+
+
+
+
1.1 Introduction to Git and GitHub Tools for Collaboration
+
+
+
+Artwork by Allison Horst
+
+
+
Git is not only a powerful tool for individual work but also an excellent choice for collaborating with friends and colleagues. Git ensures that after you’ve completed your contributions to a repository, you can confidently synchronize your changes with changes made by others.
+
One of the easiest and most effective ways to collaborate using Git is by utilizing a shared repository on a hosting service like GitHub. This shared repository acts as a central hub, enabling collaborators to effortlessly exchange and merge their changes. With Git and a shared repository, you can collaborate seamlessly and work confidently, knowing that your changes will be integrated smoothly with those of your collaborators.
+
+
+
+Graphic from Atlassian
+
+
+
There are many advanced techniques for synchronizing Git repositories, but let’s start with a simple example.
+
In this example, the Collaborator will clone a copy of the Owner’s repository from GitHub, and the Owner will grant them Collaborator status, enabling the Collaborator to directly pull and push from the Owner’s GitHub repository.
+
+
+
1.2 Collaborating with a trusted colleague without conflicts
+
We start our collaboration by giving a trusted colleague access to our repository on GitHub. In this example, we define the Owner as the individual who owns the repository, and the Collaborator as the person whom the Owner chooses to give permission to make changes to their repository.
+
The Collaborator will make changes to the repository and then push those changes to the shared repository on GitHub. The Owner will then use pull to retrieve the changes without encountering any conflicts. This is the most ideal workflow.
+
The instructors will demonstrate this process in the next section.
+
+
Step 0: Owner adds Collaborator to shared repository
+
The Owner must change the settings of the repository and give the Collaborator access to the repository by inviting them as a collaborator to the repository. Once the Collaborator has accepted the invite, they can contribute to the repository.
+
+
+
+
+
+
+
+
Step 1: Collaborator clone
+
To be able to contribute to a repository, the Collaborator must clone the repository from the Owner’s GitHub account. To do this, the Collaborator should visit the GitHub page for the Owner’s repository, and then copy the clone URL. In R Studio, the Collaborator will create a new project from version control by pasting this clone URL into the appropriate dialog (see the earlier chapter introducing GitHub).
+
+
+
+
Step 2: Collaborator edit
+
With a clone copied locally, the Collaborator can now make changes to the README.md file in the repository, adding a line or statement somewhere noticeable near the top. Save your changes.
+
+
+
Step 3: Collaborator commit and push
+
To sync changes, the Collaborator will need to add, commit, and push their changes to the Owner’s repository. But before doing so, it’s good practice to pull immediately before committing to ensure you have the most recent changes from the Owner. So, in RStudio’s Git tab, first click the “Diff” button to open the Git window, and then press the green “Pull” down arrow button. This will fetch any recent changes from the origin repository and merge them. Next, add the changed README.Rmd file to be committed by clicking the check box next to it, type in a commit message, and click “Commit”. Once that finishes, then the Collaborator can immediately click “Push” to send the commits to the Owner’s GitHub repository.
+
+
+
+
+
+
+
+
Step 4: Owner pull
+
Now, the Owner can open their local working copy of the code in RStudio, and pull those changes down to their local copy.
+
Congrats, the Owner now has your changes!
+
+
+
Step 5: Owner edits, commit, and push
+
Next, the Owner should do the same. Make changes to a file in the repository, save it, pull to make sure no new changes have been made while editing, and then add, commit, and push the Owner changes to GitHub.
+
+
+
Step 6: Collaborator pull
+
The Collaborator can now pull down those Owner changes, and all copies are once again fully synced. And you’re off to collaborating.
+
+
+
+
1.3 Exercise 1: With a partner collaborate in a repository without a merge conflict
+
+
+
+
+
+
+Setup
+
+
+
+
+
Get into pairs, then choose one person as the Owner and one as the Collaborator
Go to “Settings” and navigate to “Collaborators” in the “Access” section on the left-hand side
+
Under “Manage Access” click the button “Add people” and type the username of your Collaborator in the search box
+
Once you’ve found the correct username, click “Add {Collaborator username} to this repository
+
+
+
+
+
+
+
Now, the Collaborator will follow this step:
+
+
Check your email for an invitation to GitHub or check your notifications (likely under “Your Organizations”) on GitHub to accept the invite to collaborate.
+
+
+
+
+
+
+
+
+
+Last thing, some Git configuration
+
+
+
+
When Git released version 2.27, a new feature they incorporated allows users to specify how to pull, essentially, otherwise a warning will appear. To suppress this warning we need to configure our Git with this line of code:
+
git config pull.rebase false
+
pull.rebase false is a default strategy for pulling where it will try to auto-merge the files if possible, and if it can’t it will show a merge conflict
+
+
+
+
+
+
+
+
+Instructions
+
+
+
+
You will do the exercise twice, where each person will get to practice being both the Owner and the Collaborator roles.
+
+
Step 0: Designate one person as the Owner and one as the Collaborator.
+
+
Round One:
+
+
Step 1: Owner adds Collaborator to {FIRSTNAME}_test repository (see Setup block above for detailed steps)
+
Step 2: Collaborator clones the Owner’s {FIRSTNAME}_test repository
+
Step 3: Collaborator edits the README file:
+
+
Collaborator adds a new level 2 heading to README titled “Git Workflow”
+
+
Step 4: Collaborator commits and pushes the README file with the new changes to GitHub
+
Step 5: Owner pulls the changes that the Collaborator made
+
Step 6: Owner edits the README file:
+
+
Under “Git Workflow”, Owner adds the steps of the Git workflow we’ve been practicing
+
+
Step 7: Owner commits and pushes the README file with the new changes to GitHub
+
Step 8: Collaborator pulls the Owners changes from GitHub
+
Step 9: Go back to Step 0, switch roles, and then follow the steps in Round Two.
+
+
Round Two:
+
+
Step 1: Owner adds Collaborator to {FIRSTNAME}_test repository
+
Step 2: Collaborator clones the Owner’s {FIRSTNAME}_test repository
+
Step 3: Collaborator edits the README file:
+
+
Collaborator adds a new level 2 heading to README titled “How to Create a Git Repository from an existing project” and adds the high level steps for this workflow
+
+
Step 4: Collaborator commits and pushes the README file with the new changes to GitHub
+
Step 5: Owner pulls the changes that the Collaborator made
+
Step 6: Owner edits the README file:
+
+
Under “How to Create a Git Repository”, Owner adds the high level steps for this workflow
+
+
Step 7: Owner commits and pushes the README file with the new changes to GitHub
+
Step 8: Collaborator pulls the Owners changes from GitHub
+
+
Hint: If you don’t remember how to create a Git repository, refer to the chapter Intro to Git and GitHub where we created two Git repositories
+
+
+
+
+
1.4 A Note on Advanced Collaboration Techniques
+
There are many Git and GitHub collaboration techniques, some more advanced than others. We won’t be covering advanced strategies in this course. But here is a table for your reference on a few popular Git collaboration workflow strategies and tools.
+
+
+
+
+
+
+
+
+
+
Collaboration Technique
+
Benefits
+
When to Use
+
When Not to Use
+
+
+
+
+
Branch Management Strategies
+
1. Enables parallel development and experimentation 2. Facilitates isolation of features or bug fixes 3. Provides flexibility and control over project workflows
+
When working on larger projects with multiple features or bug fixes simultaneously. When you want to maintain a stable main branch while developing new features or resolving issues on separate branches. When collaborating with teammates on different aspects of a project and later integrating their changes.
+
When working on small projects with a single developer or limited codebase. When the project scope is simple and doesn’t require extensive branch management. When there is no need to isolate features or bug fixes.
+
+
+
Code Review Practices
+
1. Enhances code quality and correctness through feedback 2. Promotes knowledge sharing and learning within the team 3. Helps identify bugs, improve performance, and ensure adherence to coding standards
+
When collaborating on a codebase with team members to ensure code quality and maintain best practices. When you want to receive feedback and suggestions on your code to improve its readability, efficiency, or functionality. When working on critical or complex code that requires an extra layer of scrutiny before merging it into the main branch.
+
When working on personal projects or small codebases with no collaboration involved. When time constraints or project size make it impractical to conduct code reviews. When the codebase is less critical or has low complexity.
+
+
+
Forking
+
1. Enables independent experimentation and development 2. Provides a way to contribute to a project without direct access 3. Allows for creating separate, standalone copies of a repository
+
When you want to contribute to a project without having direct write access to the original repository. When you want to work on an independent variation or extension of an existing project. When experimenting with changes or modifications to a project while keeping the original repository intact.
+
When collaborating on a project with direct write access to the original repository. When the project does not allow external contributions or forking. When the project size or complexity doesn’t justify the need for independent variations.
+
+
+
Pull Requests
+
1. Facilitates code review and discussion 2. Allows for collaboration and feedback from team members 3. Enables better organization and tracking of proposed changes
+
When working on a shared repository with a team and wanting to contribute changes in a controlled and collaborative manner. When you want to propose changes to a project managed by others and seek review and approval before merging them into the main codebase.
+
When working on personal projects or individual coding tasks without the need for collaboration. When immediate changes or fixes are required without review processes. When working on projects with a small team or single developer with direct write access to the repository.
+
+
+
+
The “When Not to Use” column provides insights into situations where it may be less appropriate to use each collaboration technique, helping you make informed decisions based on the specific context and requirements of your project.
+
These techniques provide different benefits and are used in various collaboration scenarios, depending on the project’s needs and team dynamics.
+
+
+
1.5 Merge conflicts
+
Merge conflicts occur when both collaborators make conflicting changes to the same file. Resolving merge conflicts involves identifying the root of the problem and restoring the project to a normal state. Good communication, discussing file sections to work on, and avoiding overlaps can help prevent merge conflicts. However, if conflicts do arise, Git warns about potential issues and ensures that changes from different collaborators based on the same file version are not overwritten. To resolve conflicts, you need to explicitly specify whose changes should be used for each conflicting line in the file.
+
In this image, we see collaborators mbjones and metamattj have both made changes to the same line in the same README.md file. This is causing a merge conflict because Git doesn’t know whose changes came first. To resolve it, we need to tell Git whose changes to keep for that line, and whose changes to discard.
+
+
+
1.5.1 Common ways to resolve a merge conflict
+
1. Abort, abort, abort…
+
Sometimes you just made a mistake. When you get a merge conflict, the repository is placed in a “Merging” state until you resolve it. There’s a Terminal command to abort doing the merge altogether:
+
git merge --abort
+
Of course, after doing that you still haven’t synced with your Collaborator’s changes, so things are still unresolved. But at least your repository is now usable on your local machine.
+
2. Checkout
+
The simplest way to resolve a conflict, given that you know whose version of the file you want to keep, is to use the command line Git program to tell Git to use either your changes (the person doing the merge), or their changes (the Collaborator).
+
+
keep your Collaborator’s file: git checkout --theirs conflicted_file.Rmd
+
keep your own file: git checkout --ours conflicted_file.Rmd
+
+
Once you have run that command, then run add (staging), commit, pull, and push the changes as normal.
+
3. Pull and edit the file
+
But that requires the command line. If you want to resolve from RStudio, or if you want to pick and choose some of your changes and some of your Collaborator’s, then instead you can manually edit and fix the file. When you pull the file with a conflict, Git notices that there is a conflict and modifies the file to show both your own changes and your Collaborator’s changes in the file. It also shows the file in the Git tab with an orange U icon, which indicates that the file is Unmerged, and therefore awaiting your help to resolve the conflict. It delimits these blocks with a series of less than and greater than signs, so they are easy to find:
+
+
+
+
+
+
To resolve the conflicts, simply find all of these blocks, and edit them so that the file looks how you want (either pick your lines, your Collaborator’s lines, some combination, or something altogether new), and save. Be sure you removed the delimiter lines that started with
+
+
<<<<<<<,
+
=======,
+
and >>>>>>>.
+
+
Once you have made those changes, you simply add (staging), commit, and push the files to resolve the conflict.
+
+
+
+
1.6 Producing and resolving merge conflicts
+
To illustrate this process, the instructors are going to carefully create a merge conflict step by step, show how to resolve it, and show how to see the results of the successful merge after it is complete. First, the instructors will walk through the exercise to demonstrate the issues. Then, participants will pair up and try the exercise.
+
+
Step 1: Owner and Collaborator ensure all changes are updated
+
First, start the exercise by ensuring that both the Owner and Collaborator have all of the changes synced to their local copies of the Owner’s repository in RStudio. This includes doing a git pull to ensure that you have all changes local, and make sure that the Git tab in RStudio doesn’t show any changes needing to be committed.
+
+
+
Step 2: Owner makes a change and commits
+
From that clean slate, the Owner first modifies and commits a small change including their name on a specific line of the README.md file (we will change the first line, the title). Work to only change that one line, and add your username to the line in some form and commit the changes (but DO NOT push). We are now in a situation where the Owner has unpushed changes that the Collaborator can not yet see.
+
+
+
Step 3: Collaborator makes a change and commits on the same line
+
Now the Collaborator also makes changes to the same line (the first line, the title) on the README.md file in their RStudio copy of the project, adding their name to the line. They then commit. At this point, both the Owner and Collaborator have committed changes based on their shared version of the README.md file, but neither has tried to share their changes via GitHub.
+
+
+
Step 4: Collaborator pushes the file to GitHub
+
Sharing starts when the Collaborator pushes their changes to the GitHub repo, which updates GitHub to their version of the file. The Owner is now one revision behind, but doesn’t know it yet.
+
+
+
Step 5: Owner pushes their changes and gets an error
+
At this point, the Owner tries to push their change to the repository, which triggers an error from GitHub. While the error message is long, it basically tells you everything needed (that the Owner’s repository doesn’t reflect the changes on GitHub, and that they need to pull before they can push).
+
+
+
+
Step 6: Owner pulls from GitHub to get Collaborator changes
+
Doing what the message says, the Owner pulls the changes from GitHub, and gets another, different error message. In this case, it indicates that there is a merge conflict because of the conflicting lines.
+
+
In the Git pane of RStudio, the file is also flagged with an orange U, which stands for an unresolved merge conflict.
+
+
+
+
Step 7: Owner edits the file to resolve the conflict
+
To resolve the conflict, the Owner now needs to edit the file. Again, as indicated above, Git has flagged the locations in the file where a conflict occurred with <<<<<<<, =======, and >>>>>>>. The Owner should edit the file, merging whatever changes are appropriate until the conflicting lines read how they should, and eliminate all of the marker lines with <<<<<<<, =======, and >>>>>>>.
+
+
Of course, for scripts and programs, resolving the changes means more than just merging the text – whoever is doing the merging should make sure that the code runs properly and none of the logic of the program has been broken.
+
+
+
+
Step 8: Owner commits the resolved changes
+
From this point forward, things proceed as normal. The Owner first add the file changes to be made, which changes the orange U to a blue M for modified, and then commits the changes locally. The Owner now has a resolved version of the file on their system.
+
+
+
+
Step 9: Owner pushes the resolved changes to GitHub
+
Have the Owner push the changes, and it should replicate the changes to GitHub without error.
+
+
+
+
Step 10: Collaborator pulls the resolved changes from GitHub
+
Finally, the Collaborator can pull from GitHub to get the changes the Owner made.
+
+
+
Step 11: Both can view commit history
+
When either the Collaborator or the Owner view the history, the conflict, associated branch, and the merged changes are clearly visible in the history.
+
+
+
+
+
1.7 Exercise 2: With a partner collaborate in a repository and resolve a merge conflict
+
Note you will only need to complete the Setup and Git configuration steps again if you are working in a new repository. Return to Exercise 1 for Setup and Git configuration steps.
+
+
+
+
+
+
+Instructions
+
+
+
+
Now it’s your turn. In pairs, intentionally create a merge conflict, and then go through the steps needed to resolve the issues and continue developing with the merged files. See the sections above for help with each of the steps below. You will do the exercise twice, where each person will get to practice being both the Owner and the Collaborator roles.
+
+
Step 0: Designate one person as the Owner and one as the Collaborator.
+
+
Round One:
+
+
Step 1: Both Owner and Collaborator pull to ensure both have the most up-to-date changes
+
Step 2: Owner edits the README file and makes a change to the title and commits do not push
+
Step 3: On the same line, Collaborator edits the README file and makes a change to the title and commits
+
Step 4: Collaborator pushes the file to GitHub
+
Step 5: Owner pushes their changes and gets an error
+
Step 6: Owner pulls from GitHub to get Collaborator changes
+
Step 7: Owner edits the README file to resolve the conflict
+
Step 8: Owner commits the resolved changes
+
Step 9: Owner pushes the resolved changes to GitHub
+
Step 10: Collaborator pulls the resolved changes from GitHub
+
Step 11: Both view commit history
+
Step 12: Go back to Step 0, switch roles, and then follow the steps in Round Two.
+
+
Round Two:
+
+
Step 1: Both Owner and Collaborator pull to ensure both have the most up-to-date changes
+
Step 2: Owner edits the README file and makes a change to line 2 and commits do not push
+
Step 3: On the same line, Collaborator edits the README file and makes a change to line 2 and commits
+
Step 4: Collaborator pushes the file to GitHub
+
Step 5: Owner pushes their changes and gets an error
+
Step 6: Owner pulls from GitHub to get Collaborator changes
+
Step 7: Owner edits the README file to resolve the conflict
+
Step 8: Owner commits the resolved changes
+
Step 9: Owner pushes the resolved changes to GitHub
+
Step 10: Collaborator pulls the resolved changes from GitHub
+
Step 11: Both view commit history
+
+
+
+
+
+
1.8 Best practices to avoid merge conflicts
+
Some basic rules of thumb can avoid the vast majority of merge conflicts, saving a lot of time and frustration. These are words our teams live by:
+
+
+
+
+
+XKCD 1597
+
+
+
+
Communicate often and set up effective communication channels
+
Tell each other what you are working on
+
Start your working session with a pull
+
Pull immediately before you commit or push
+
Commit often in small chunks (this helps you organize your work!)
+
Make sure you and who you are collaborating with all fully understand the Git workflow you’re using aka make sure you’re on the same page before you start!
Always start your working sessions with a pull to get any outstanding changes, then start your work. Stage your changes, but before you commit, pull again to see if any new changes have arrived. If so, they should merge in easily if you are working in different parts of the program. You can then commit and immediately push your changes safely.
+
Good luck, and try to not get frustrated. Once you figure out how to handle merge conflicts, they can be avoided or dispatched when they occur, but it does take a bit of practice.
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_02.html b/public/session_02.html
new file mode 100644
index 00000000..da0aba6d
--- /dev/null
+++ b/public/session_02.html
@@ -0,0 +1,717 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 2 Social Aspects of Collaboration
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
2Social Aspects of Collaboration
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
2.1 Developing a Code of Conduct
+
Whether you are joining a lab group or establishing a new collaboration, articulating a set of shared agreements about how people in the group will treat each other will help create the conditions for successful collaboration. If agreements or a code of conduct do not yet exist, invite a conversation among all members to create them. Co-creation of a code of conduct will foster collaboration and engagement as a process in and of itself, and is important to ensure all voices heard such that your code of conduct represents the perspectives of your community. If a code of conduct already exists, and your community will be a long-acting collaboration, you might consider revising the code of conduct. Having your group ‘sign off’ on the code of conduct, whether revised or not, supports adoption of the principles.
+
When creating a code of conduct, consider both the behaviors you want to encourage and those that will not be tolerated. For example, the Openscapes code of conduct includes Be respectful, honest, inclusive, accommodating, appreciative, and open to learning from everyone else. Do not attack, demean, disrupt, harass, or threaten others or encourage such behavior.
Navigating issues of intellectual property and credit can be a challenge, particularly for early career researchers. Open communication is critical to avoiding misunderstandings and conflicts. Talk to your coauthors and collaborators about authorship, credit, and data sharing early and often. This is particularly important when working with new collaborators and across lab groups or disciplines which may have divergent views on authorship and data sharing. If you feel uncomfortable talking about issues surrounding credit or intellectual property, seek the advice or assistance of a mentor to support you in having these important conversations.
For collaborative research projects, develop an authorship agreement for your group early in the project and refer to it for each product. This example authorship agreement from the Arctic Data Center provides a useful template. It builds from information contained within Weltzin et al (2006) and provides a rubric for inclusion of individuals as authors. Your collaborative team may not choose to adopt the agreement in the current form, however it will prompt thought and discussion in advance of developing a consensus. Some key questions to consider as you are working with your team to develop the agreement:
What are our criteria for authorship? (See the ICMJE guidelines for potential criteria)
+
Will we extend the opportunity for authorship to all group members on every paper or product?
+
Do we want to have an opt in or opt out policy? (In an opt out policy, all group members are considered authors from the outset and must request removal from the paper if they don’t want think they meet the criteria for authorship)
+
Who has the authority to make decisions about authorship? Lead author? PI? Group?
+
How will we decide authorship order?
+
In what other ways will we acknowledge contributions and extend credit to collaborators?
+
How will we resolve conflicts if they arise?
+
+
+
+
2.3 Data Sharing and Reuse Policies
+
As with authorship agreements, it is valuable to establish a shared agreement around handling of data when embarking on collaborative projects. Data collected as part of a funded research activity will typically have been managed as part of the Data Management Plan (DMP) associated with that project. However, collaborative research brings together data from across research projects with different data management plans and can include publicly accessible data from repositories where no management plan is available. For these reasons, a discussion and agreement around the handling of data brought into and resulting from the collaboration is warranted and management of this new data may benefit from going through a data management planning process. Below we discuss example data agreements.
+
The example data policy template provided by the Arctic Data Center addresses three categories of data.
+
+
Individual data not in the public domain
+
Individual data with public access
+
Derived data resulting from the project
+
+
For the first category, the agreement considers conditions under which those data may be used and permissions associated with use. It also addresses access and sharing. In the case of individual, publicly accessible data, the agreement stipulates that the team will abide by the attribution and usage policies that the data were published under, noting how those requirements we met. In the case of derived data, the agreement reads similar to a DMP with consideration of making the data public; management, documentation and archiving; pre-publication sharing; and public sharing and attribution. As research data objects receive a persistent identifier (PID), often a DOI, there are citable objects and consideration should be given to authorship of data, as with articles.
+
The following example lab policy from the Wolkovich Lab combines data management practices with authorship guidelines and data sharing agreements. It provides a lot of detail about how this lab approaches data use, attribution and authorship. For example:
+
+
Section 6: Co-authorship & data
+
If you agree to take on existing data you cannot offer co-authorship for use of the data unless four criteria are met:
+
+
The co-author agrees to (and does) make substantial intellectual contribution to the work, which includes the reading and editing of all manuscripts on which you are a co-author through the submission-for-publication stage. This includes helping with interpretation of the data, system, study questions.
+
Agreement of co-authorship is made at the start of the project.
+
Agreement is approved of by Lizzie.
+
All data-sharers are given an equal opportunity at authorship. It is not allowed to offer or give authorship to one data-sharer unless all other data-sharers are offered an equal opportunity at authorship—this includes data that are publicly-available, meaning if you offer authorship to one data-sharer and were planning to use publicly-available data you must reach out to the owner of the publicly-available data and strongly offer equivalent authorship as offered to the other data-sharer. As an example, if five people share data freely with you for a meta-analysis and and a sixth wants authorship you either must strongly offer equivalent authorship to all five or deny authorship to the sixth person. Note that the above requirements must also be met in this situation. If one or more datasets are more central or critical to a paper to warrant selective authorship this must be discussed and approved by Lizzie (and has not, to date, occurred within the lab).
+
+
+
+
+
+
+
2.3.0.1 Policy Preview
+
+
This policy is communicated with all incoming lab members, from undergraduate to postdocs and visiting scholars, and is shared here with permission from Dr Elizabeth Wolkovich.
+
+
+
2.3.1 Community Principles: CARE and FAIR
+
The CARE and FAIR Principles were introduced previously in the context of introducing the Arctic Data Center and our data submission and documentation process. In this section we will dive a little deeper.
+
To recap, the Arctic Data Center is an openly-accessible data repository and the data published through the repository is open for anyone to reuse, subject to conditions of the license (at the Arctic Data Center, data is released under one of two licenses: CC-0 Public Domain and CC-By Attribution 4.0). In facilitating use of data resources, the data stewardship community have converged on principles surrounding best practices for open data management One set of these principles is the FAIR principles. FAIR stands for Findable, Accessible, Interoperable, and Reproducible.
+
+
The “Fostering FAIR Data Practices in Europe” project found that it is more monetarily and timely expensive when FAIR principles are not used, and it was estimated that 10.2 billion dollars per years are spent through “storage and license costs to more qualitative costs related to the time spent by researchers on creation, collection and management of data, and the risks of research duplication.” FAIR principles and open science are overlapping concepts, but are distinctive concepts. Open science supports a culture of sharing research outputs and data, and FAIR focuses on how to prepare the data.
+
+
Another set of community developed principles surrounding open data are the CARE Principles. The CARE principles for Indigenous Data Governance complement the more data-centric approach of the FAIR principles, introducing social responsibility to open data management practices. The CARE Principles stand for:
+
+
Collective Benefit - Data ecosystems shall be designed and function in ways that enable Indigenous Peoples to derive benefit from the data
+
Authority to Control - Indigenous Peoples’ rights and interests in Indigenous data must be recognised and their authority to control such data be empowered. Indigenous data governance enables Indigenous Peoples and governing bodies to determine how Indigenous Peoples, as well as Indigenous lands, territories, resources, knowledges and geographical indicators, are represented and identified within data.
+
Responsibility - Those working with Indigenous data have a responsibility to share how those data are used to support Indigenous Peoples’ self-determination and collective benefit. Accountability requires meaningful and openly available evidence of these efforts and the benefits accruing to Indigenous Peoples.
+
Ethics - Indigenous Peoples’ rights and wellbeing should be the primary concern at all stages of the data life cycle and across the data ecosystem.
+
+
The CARE principles align with the FAIR principles by outlining guidelines for publishing data that is findable, accessible, interoperable, and reproducible while at the same time, accounts for Indigenous’ Peoples rights and interests. Initially designed to support Indigenous data sovereignty, CARE principles are now being adopted across domains, and many researchers argue they are relevant for both Indigenous Knowledge and data, as well as data from all disciplines (Carroll et al., 2021). These principles introduce a “game changing perspective” that encourages transparency in data ethics, and encourages data reuse that is purposeful and intentional that aligns with human well-being aligns with human well-being (Carroll et al., 2021).
+
+
+
+
2.4 Research Data Publishing Ethics
+
For over 20 years, the Committee on Publication Ethics (COPE) has provided trusted guidance on ethical practices for scholarly publishing. The COPE guidelines have been broadly adopted by academic publishers across disciplines, and represent a common approach to identify, classify, and adjudicate potential breaches of ethics in publication such as authorship conflicts, peer review manipulation, and falsified findings, among many other areas. Despite these guidelines, there has been a lack of ethics standards, guidelines, or recommendations for data publications, even while some groups have begun to evaluate and act upon reported issues in data publication ethics.
+
+
+
+Data retractions
+
+
+
To address this gap, the Force 11 Working Group on Research Data Publishing Ethics was formed as a collaboration among research data professionals and the Committee on Publication Ethics (COPE) “to develop industry-leading guidance and recommended best practices to support repositories, journal publishers, and institutions in handling the ethical responsibilities associated with publishing research data.” The group released the “Joint FORCE11 & COPE Research Data Publishing Ethics Working Group Recommendations” (Puebla, Lowenberg, and WG 2021), which outlines recommendations for four categories of potential data ethics issues:
Unintentional errors in collection, calculation, display
+
Un-interpretable data due to lack of adequate documentation
+
Errors of of study design and inference
+
Data manipulation or fabrication
+
+
+
Guidelines cover what actions need to be taken, depending on whether the data are already published or not, as well as who should be involved in decisions, who should be notified of actions, and when the public should be notified. The group has also published templates for use by publishers and repositories to announce the extent to which they plan to conform to the data ethics guidelines.
+
+
Discussion: Data publishing policies
+
At the Arctic Data Center, we need to develop policies and procedures governing how we react to potential breaches of data publication ethics. In this exercise, break into groups to provide advice on how the Arctic Data Center should respond to reports of data ethics issues, and whether we should adopt the Joint FORCE11 & COPE Research Data Publishing Ethics Working Group Policy Templates for repositories. In your discussion, consider:
Who should be involved in evaluation of the merits of ethical cases reported to ADC?
+
Who should be involved in deciding the actions to take?
+
What are the range of responses that the repository should consider for ethical breaches?
+
Who should be notified when a determination has been made that a breach has occurred?
+
+
You might consider a hypothetical scenario such as the following in considering your response.
+
+
The data coordinator at the Arctic Data Center receives an email in 2022 from a prior postdoctoral fellow who was employed as part of an NSF-funded project on microbial diversity in Alaskan tundra ecosystems. The email states that a dataset from 2014 in the Arctic Data Center was published with the project PI as author, but omits two people, the postdoc and an undergraduate student, as co-authors on the dataset. The PI retired in 2019, and the postdoc asks that they be added to the author list of the dataset to correct the historical record and provide credit.
+Puebla, Iratxe, Daniella Lowenberg, and FORCE11 Research Data Publishing Ethics WG. 2021. “Joint FORCE11 & COPE Research Data Publishing Ethics Working Group Recommendations.” Zenodo. https://doi.org/10.5281/zenodo.5391293.
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_03.html b/public/session_03.html
new file mode 100644
index 00000000..7bb11eb8
--- /dev/null
+++ b/public/session_03.html
@@ -0,0 +1,500 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 3 Thinking Preferences
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
3Thinking Preferences
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
INSERT ONE OF THE THIKING PREFERENCES VERSIONS
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_04.html b/public/session_04.html
new file mode 100644
index 00000000..eef2681f
--- /dev/null
+++ b/public/session_04.html
@@ -0,0 +1,500 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 4 Synthesis Time
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
4Synthesis Time
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_05.html b/public/session_05.html
new file mode 100644
index 00000000..0b3f8adf
--- /dev/null
+++ b/public/session_05.html
@@ -0,0 +1,638 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 5 Publishing your Analysis to the Web
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
5Publishing your Analysis to the Web
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Learning Objectives
+
+
How to use Git, GitHub (+Pages), and R Markdown to publish an analysis to the web
+
+
+
+
5.1 Introduction
+
Sharing your work with others in engaging ways is an important part of the scientific process.
+
So far in this course, we’ve introduced a small set of powerful tools for doing open science:
+
+
R and its many packages
+
RStudio
+
Git
+
GitHub
+
R Markdown
+
+
R Markdown, in particular, is amazingly powerful for creating scientific reports but, so far, we haven’t tapped its full potential for sharing our work with others.
+
In this lesson, we’re going to take our training_{USERNAME} GitHub repository and turn it into a beautiful and easy to read web page using the tools listed above.
+
+
+
+
+
+
+Set up
+
+
+
+
+
Make sure you are in training_{USERNAME} project
+
Add a new R Markdown file at the top level called index.Rmd
+
+
Go to the RStudio menu File > New File > R Markdown
+
This will bring up a dialog box. Add the title “GitHub Pages Example”, keep the Default Output Format as “HTML”, and then click “OK”
+
+
Save the R Markdown file you just created. Use index.Rmd as the file name
+
+
Be sure to use the exact case (lower case ‘index’) as different operating systems handle case differently and it can interfere with loading your web page later
+
+
Press “Knit” and observe the rendered output
+
+
Notice the new file in the same directory index.html
+
This is our R Markdown file rendered as HTML (a web page)
+
+
Commit your changes (for both index.Rmd and index.html) with a commit message, and push to GitHub
+
Open your web browser to the GitHub.com and navigate to the page for your training_{USERNAME} repository
+
Activate GitHub Pages for the main branch
+
+
Go to Settings > Pages (underneath the Code and Automation section)
+
Keep the “Source” as “Deploy from a branch”
+
Under “Branch” you’ll see a message that says “GitHub Pages is currently disabled”. To change this, change the branch from “None” to main. Keep the folder as the root and then click “Save”
+
You should see the message change to “Your GitHub Pages site is currently being built from the main branch”
+
+
+
Note:index.Rmd represents the default file for a web site, and is returned whenever you visit the web site but doesn’t specify an explicit file to be returned.
+
+
+
Now, the rendered website version of your repo will show up at a special URL.
+
GitHub Pages follows a convention like this:
+
+
Note that it changes from github.com to github.io
+
+
Go to https://{username}.github.io/{repo_name}/ (Note the trailing /)
+
Observe the awesome rendered output
+
+
Now that we’ve successfully published a web page from an R Markdown document, let’s make a change to our R Markdown document and follow the steps to publish the change on the web:
+
+
+
+
+
+
+Update content in your published page
+
+
+
+
+
Go back to your index.Rmd
+
Delete all the content, except the YAML frontmatter
+
Type “Hello world”
+
Use Git workflow: Stage > Commit > Pull > Push
+
Go back to https://{username}.github.io/{repo_name}/
+
+
+
+
Next, we will show how you can link different Rmds rendered into html so you can easily share different parts of your work.
+
+
+
+
+
+
+Exercise
+
+
+
+
In this exercise, you’ll create a table of contents with the lessons of this course on the main page, and link some of the files we have work on so far.
+
+
Go back to the RStudio server and to your index.Rmd file
+
Create a table of contents with the names of the main technical lessons of this course, like so:
+
+
## coreR workshop
+
+- Introduction to RMarkdown
+- Cleaning and Wrangling data
+- Data Visualization
+- Spatial Analysis
+
+
Make sure you have the html versions of your intro-to-rmd.Rmd and data-cleaning.Rmd files. If you only see the Rmd version, you need to “Knit” your files first
+
In your index.Rmd let’s add the links to the html files we want to show on our webpage. Do you remember the Markdown syntax to create a link?
+
+
+
+Markdown syntax to create a link:
+
+
+
[Text you want to hyperlink](link)
+
+
Example: [Data wrangling and cleaning](data-wrangling-cleaning.html)
+
+
+
+
+
Use Git workflow: Stage > Commit > Pull > Push
+
+
Now when you visit your web site, you’ll see the table of contents, and can navigate to the others file you linked.
+
+
+
R Markdown web pages are a great way to share work in progress with your colleagues. Here we showed an example with the materials we have created in this course. However, you can use these same steps to share the different files and progress of a project you’ve been working on. To do so simply requires thinking through your presentation so that it highlights the workflow to be reviewed. You can include multiple pages and build a simple web site and make your work accessible to people who aren’t set up to open your project in R. Your site could look something like this:
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_06.html b/public/session_06.html
new file mode 100644
index 00000000..4591770f
--- /dev/null
+++ b/public/session_06.html
@@ -0,0 +1,1221 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 6 Data Visualization in R
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
6Data Visualization in R
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Learning Objectives
+
+
The basics of the ggplot2 package to create static plots
+
How to use ggplot2’s theme abilities to create publication-grade graphics
+
The basics of the leaflet package to create interactive maps
+
+
+
+
6.1 Overview
+
ggplot2 is a popular package for visualizing data in R. From the home page:
+
+
ggplot2 is a system for declaratively creating graphics, based on The Grammar of Graphics. You provide the data, tell ggplot2 how to map variables to aesthetics, what graphical primitives to use, and it takes care of the details.
+
+
It’s been around for years and has pretty good documentation and tons of example code around the web (like on StackOverflow). The goal of this lesson is to introduce you to the basic components of working with ggplot2 and inspire you to go and explore this awesome resource for visualizing your data.
+
+
+
+
+
+
+ggplot2 vs base graphics in R vs others
+
+
+
+
There are many different ways to plot your data in R. All of them work! However, ggplot2 excels at making complicated plots easy and easy plots simple enough
+
Base R graphics (plot(), hist(), etc) can be helpful for simple, quick and dirty plots. ggplot2 can be used for almost everything else.
+
+
+
Let’s dive into creating and customizing plots with ggplot2.
+
+
+
+
+
+
+Setup
+
+
+
+
+
Make sure you’re in the right project (training_{USERNAME}) and use the Git workflow by Pulling to check for any changes. Then, create a new R Markdown document and remove the default text.
Learn about the data. For this session we are going to be working with data on daily salmon escapement counts in Alaska. Check out the documentation.
+
Finally, let’s explore the data we just read into our working environment.
+
+
+
## Check out column names
+colnames(escape)
+
+## Peak at each column and class
+glimpse(escape)
+
+## From when to when
+range(escape$sampleDate)
+
+## How frequent?
+head(escape$sampleDate)
+tail(escape$sampleDate)
+
+## Which species?
+unique(escape$Species)
+
+
+
+
+
+
6.2 Getting the data ready
+
It is more frequent than not, that we need to do some wrangling before we can plot our data the way we want to. Now that we have read out data and have done some exploration, we’ll put our data wrangling skills to practice to get our data in the desired format.
+
+
+
+
+
+
+Exercise
+
+
+
+
+
Calculate the annual escapement by Species and SASAP.Region,
+
Filter the main 5 salmon species (Chinook, Sockeye, Chum, Coho and Pink)
# A tibble: 6 × 4
+# Groups: Species, SASAP.Region [1]
+ Species SASAP.Region Year escapement
+ <chr> <chr> <dbl> <dbl>
+1 Chinook Alaska Peninsula and Aleutian Islands 1974 1092
+2 Chinook Alaska Peninsula and Aleutian Islands 1975 1917
+3 Chinook Alaska Peninsula and Aleutian Islands 1976 3045
+4 Chinook Alaska Peninsula and Aleutian Islands 1977 4844
+5 Chinook Alaska Peninsula and Aleutian Islands 1978 3901
+6 Chinook Alaska Peninsula and Aleutian Islands 1979 10463
+
+
+
The chunk above used a lot of the dplyr commands that we’ve used, and some that are new. The separate() function is used to divide the sampleDate column up into Year, Month, and Day columns, and then we use group_by() to indicate that we want to calculate our results for the unique combinations of species, region, and year. We next use summarize() to calculate an escapement value for each of these groups. Finally, we use a filter and the %in% operator to select only the salmon species.
+
+
+
6.3 Plotting with ggplot2
+
+
6.3.1 Essentials components
+
First, we’ll cover some ggplot2 basics to create the foundation of our plot. Then, we’ll add on to make our great customized data visualization.
+
+
+
+
+
+
+The basics
+
+
+
+
+
Indicate we are using ggplot() (call the ggplot2::ggplot() function)
+
What data do we want to plot? (data = my_data)
+
What is my mapping aesthetics? What variables do we want to plot? (define usingaes() function)
+
Define the geometry of our plot. This specifies the type of plot we’re making (use geom_*() to indicate the type of plot e.g: point, bar, etc.)
+
+
Note To add layers to our plot, for example, additional geometries/aesthetics and theme elements or any ggplot object we use +.
+
+
+
For example, let’s plot total escapement by species. We will show this by creating the same plot in 3 slightly different ways. Each of the options below have the essential pieces of a ggplot.
+
+
## Option 1 - data and mapping called in the ggplot() function
+ggplot(data = annual_esc,
+aes(x = Species, y = escapement)) +
+geom_col()
+
+## Option 2 - data called in ggplot function; mapping called in geom
+ggplot(data = annual_esc) +
+geom_col(aes(x = Species, y = escapement))
+
+
+## Option 3 - data and mapping called in geom
+ggplot() +
+geom_col(data = annual_esc,
+aes(x = Species, y = escapement))
+
+
They all will create the same plot:
+
+
+
+
+
+
+
+
6.3.2 Looking at different geoms
+
Having the basic structure with the essential components in mind, we can easily change the type of graph by updating the geom_*().
+
+
+
+
+
+
+ggplot2 and the pipe operator
+
+
+
+
Just like in dplyr and tidyr, we can also pipe a data.frame directly into the first argument of the ggplot function using the %>% operator.
+
This can certainly be convenient, but use it carefully! Combining too many data-tidying or subsetting operations with your ggplot call can make your code more difficult to debug and understand.
+
+
+
Next, we will use the pipe operator to pass into ggplot() a filtered version of annual_esc, and make a plot with different geometries.
+
Boxplot
+
+
annual_esc %>%
+filter(Year ==1974,
+ Species %in%c("Chum", "Pink")) %>%
+ggplot(aes(x = Species, y = escapement)) +
+geom_boxplot()
+
+
+
+
+
Violin plot
+
+
annual_esc %>%
+filter(Year ==1974,
+ Species %in%c("Chum", "Pink")) %>%
+ggplot(aes(x = Species, y = escapement)) +
+geom_violin()
Notice that we tried to set the fill color of the plot inside the mapping aesthetic call. What we have done, behind the scenes, is create a column filled with the word “blue” in our data frame, and then mapped it to the fill aesthetic, which then chose the default fill color of red.
+
What we really wanted to do was just change the color of the bars. If we want do do that, we can call the color option in the geom_col() function, outside of the mapping aesthetics function call.
+
+
ggplot(annual_esc,
+aes(x = Species, y = escapement)) +
+geom_col(fill ="blue")
+
+
+
+
+
What if we did want to map the color of the bars to a variable, such as region. ggplot() is really powerful because we can easily get this plot to visualize more aspects of our data.
If you want to map a variable onto a graph aesthetic (e.g., point color should be based on a specific region), put it within aes().
+
If you want to update your plot base on a constant (e.g. “Make ALL the points BLUE”), you can add the information directly to the relevant geom_ layer.
+
+
+
+
+
6.3.3.1 Creating multiple plots
+
We know that in the graph we just plotted, each bar includes escapements for multiple years. Let’s leverage the power of ggplot to plot more aspects of our data in one plot.
+
We are going to plot escapement by species over time, from 2000 to 2016, for each region.
+
An easy way to plot another aspect of your data is using the function facet_wrap(). This function takes a mapping to a variable using the syntax ~{variable_name}. The ~ (tilde) is a model operator which tells facet_wrap() to model each unique value within variable_name to a facet in the plot.
+
The default behavior of facet wrap is to put all facets on the same x and y scale. You can use the scales argument to specify whether to allow different scales between facet plots (e.g scales = "free_y" to free the y axis scale). You can also specify the number of columns using the ncol = argument or number of rows using nrow =.
+
+
## Subset with data from years 2000 to 2016
+
+annual_esc_2000s <- annual_esc %>%
+filter(Year %in%c(2000:2016))
+
+## Quick check
+unique(annual_esc_2000s$Year)
Now let’s work on making this plot look a bit nicer. We are going to”
+
+
Add a title using ggtitle()
+
Adjust labels using ylab()
+
Include a built in theme using theme_bw()
+
+
There are a wide variety of built in themes in ggplot that help quickly set the look of the plot. Use the RStudio autocomplete theme_<TAB> to view a list of theme functions.
You can see that the theme_bw() function changed a lot of the aspects of our plot! The background is white, the grid is a different color, etc. There are lots of other built in themes like this that come with the ggplot2 package.
+
+
+
+
+
+
+Exercise
+
+
+
+
Use the RStudio auto complete, the ggplot2 documentation, a cheat sheet, or good old Google to find other built in themes. Pick out your favorite one and add it to your plot.
+
+
+
+
+Themes
+
## Useful baseline themes are
+theme_minimal()
+theme_light()
+theme_classic()
+
+
+
The built in theme functions (theme_*()) change the default settings for many elements that can also be changed individually using thetheme() function. The theme() function is a way to further fine-tune the look of your plot. This function takes MANY arguments (just have a look at ?theme). Luckily there are many great ggplot resources online so we don’t have to remember all of these, just Google “ggplot cheat sheet” and find one you like.
+
Let’s look at an example of a theme() call, where we change the position of the legend from the right side to the bottom, and remove its title.
Note that the theme() call needs to come after any built-in themes like theme_bw() are used. Otherwise, theme_bw() will likely override any theme elements that you changed using theme().
+
You can also save the result of a series of theme() function calls to an object to use on multiple plots. This prevents needing to copy paste the same lines over and over again!
Using whatever method you like, figure out how to rotate the x-axis tick labels to a 45 degree angle.
+
+
Hint: You can start by looking at the documentation of the function by typing ?theme() in the console. And googling is a great way to figure out how to do the modifications you want to your plot.
+
+
What changes do you expect to see in your plot by adding the following line of code? Discuss with your neighbor and then try it out!
Fixing tick labels in ggplot can be super annoying. The y-axis labels in the plot above don’t look great. We could manually fix them, but it would likely be tedious and error prone.
+
The scales package provides some nice helper functions to easily rescale and relabel your plots. Here, we use scale_y_continuous() from ggplot2, with the argument labels, which is assigned to the function name comma, from the scales package. This will format all of the labels on the y-axis of our plot with comma-formatted numbers.
ggplot() loves putting things in alphabetical order. But more frequent than not, that’s not the order you actually want things to be plotted if you have categorical groups. Let’s find some total years of data by species for Kuskokwim.
+
+
## Number Years of data for each salmon species at Kuskokwim
+n_years <- annual_esc %>%
+group_by(SASAP.Region, Species) %>%
+summarize(n =n()) %>%
+filter(SASAP.Region =="Kuskokwim")
Now, let’s apply some of the customizations we have seen so far and learn some new ones.
+
+
## Reordering, flipping coords and other customization
+ggplot(n_years,
+aes(
+x =fct_reorder(Species, n),
+y = n,
+fill = Species
+ )) +
+geom_bar(stat ="identity") +
+coord_flip() +
+theme_minimal() +
+## another way to customize labels
+labs(x ="Species",
+y ="Number of years of data",
+title ="Number of years of escapement data for salmon species in Kuskokwim") +
+theme(legend.position ="none")
+
+
+
+
+
+
+
6.3.3.5 Saving plots
+
Saving plots using ggplot is easy! The ggsave() function will save either the last plot you created, or any plot that you have saved to a variable. You can specify what output format you want, size, resolution, etc. See ?ggsave() for documentation.
+
+
ggsave("figures/nyears_data_kus.jpg", width =8, height =6, units ="in")
+
+
We can also save our facet plot showing annual escapements by region calling the plot’s object.
+
+
ggsave(annual_region_plot, "figures/annual_esc_region.png", width =12, height =8, units ="in")
+
+
+
+
+
+
6.4 Interactive visualization
+
+
6.4.1 Tables with DT
+
Now that we know how to make great static visualizations, let’s introduce two other packages that allow us to display our data in interactive ways. These packages really shine when used with GitHub Pages, so at the end of this lesson we will publish our figures to the website we created earlier.
+
First let’s show an interactive table of unique sampling locations using DT. Write a data.frame containing unique sampling locations with no missing values using two new functions from dplyr and tidyr: distinct() and drop_na().
And display it as an interactive table using datatable() from the DT package.
+
+
datatable(locations)
+
+
+
+
+
+
+
+
+
6.4.2 Maps with leaflet
+
Similar to ggplot2, you can make a basic leaflet map using just a couple lines of code. Note that unlike ggplot2, the leaflet package uses pipe operators (%>%) and not the additive operator (+).
+
The addTiles() function without arguments will add base tiles to your map from OpenStreetMap. addMarkers() will add a marker at each location specified by the latitude and longitude arguments. Note that the ~ symbol is used here to model the coordinates to the map (similar to facet_wrap() in ggplot).
You can also use leaflet to import Web Map Service (WMS) tiles. Here is an example that utilizes the General Bathymetric Map of the Oceans (GEBCO) WMS tiles. In this example, we also demonstrate how to create a more simple circle marker, the look of which is explicitly set using a series of style-related arguments.
Leaflet has a ton of functionality that can enable you to create some beautiful, functional maps with relative ease. Here is an example of some we created as part of the State of Alaskan Salmon and People (SASAP) project, created using the same tools we showed you here. This map hopefully gives you an idea of how powerful the combination of R Markdown and GitHub Pages can be.
+
+
+
+
6.5 Publish the Data Visualization lesson to your webpage
+
+
+
+
+
+
+Steps
+
+
+
+
+
Save the Rmd you have been working on for this lesson.
+
“Knit” the Rmd. This is a good way to test if everything in your code is working.
+
Go to your index.Rmd and the link to the html file with this lesson’s content.
+
Save and render index.Rmd to an html.
+
Use the Git workflow: Stage > Commit > Pull > Push
Simple features or simple feature access refers to a formal standard (ISO 19125-1:2004) that describes how objects in the real world can be represented in computers, with emphasis on the spatial geometry of these objects. It also describes how such objects can be stored in and retrieved from databases, and which geometrical operations should be defined for them.
+
+
The sf package is an R implementation of Simple Features. This package incorporates:
+
+
a new spatial data class system in R
+
+
functions for reading and writing spatial data
+
+
tools for spatial operations on vectors
+
+
Most of the functions in this package starts with prefix st_ which stands for spatial and temporal.
+
In this lesson, our goal is to use a shapefile of Alaska regions and rivers, and data on population in Alaska by community to create a map that looks like this:
+
+
+
+
9.2 About the data
+
All of the data used in this tutorial are simplified versions of real datasets available on the KNB Data Repository. We are using simplified datasets to ease the processing burden on all our computers since the original geospatial datasets are high-resolution. These simplified versions of the datasets may contain topological errors.
+
The spatial data we will be using to create the map are:
+
+
+
+
Data
+
Original datasets
+
+
+
+
+
Alaska regional boundaries
+
Jared Kibele and Jeanette Clark. 2018. State of Alaska’s Salmon and People Regional Boundaries. Knowledge Network for Biocomplexity. doi:10.5063/F1125QWP.
+
+
+
Community locations and population
+
Jeanette Clark, Sharis Ochs, Derek Strong, and National Historic Geographic Information System. 2018. Languages used in Alaskan households, 1990-2015. Knowledge Network for Biocomplexity. doi:10.5063/F11G0JHX.
+
+
+
Alaska rivers
+
The rivers shapefile is a simplified version of Jared Kibele and Jeanette Clark. Rivers of Alaska grouped by SASAP region, 2018. Knowledge Network for Biocomplexity. doi:10.5063/F1SJ1HVW.
+
+
+
+
+
+
+
+
+
+Setup
+
+
+
+
+
Navigate to this dataset on KNB’s test site and download the zip folder.
+
Upload the zip folder to the data folder in the training_{USERNAME} project. You don’t need to unzip the folder ahead of time, uploading will automatically unzip the folder.
+
Create a new R Markdown file.
+
+
Title it “Intro to sf package for Spatial Data and Making Maps”
+
Save the file and name it “intro-sf-spatial-data-maps”.
+
+
Load the following libraries at the top of your R Markdown file.
First let’s read in the shapefile of regional boundaries in Alaska using read_sf() and then create a basic plot of the data plot().
+
+
# read in shapefile using read_sf()
+ak_regions <-read_sf("data/ak_regions_simp.shp")
+
+
+
# quick plot
+plot(ak_regions)
+
+
+
+
+
We can also examine it’s class using class().
+
+
class(ak_regions)
+
+
[1] "sf" "tbl_df" "tbl" "data.frame"
+
+
+
sf objects usually have two types of classes: sf and data.frame.
+
Unlike a typical data.frame, an sf object has spatial metadata (geometry type, dimension, bbox, epsg (SRID), proj4string) and an additional column typically named geometry that contains the spatial data.
+
Since our shapefile object has the data.frame class, viewing the contents of the object using the head() function or other exploratory functions shows similar results as if we read in data using read.csv() or read_csv().
Every sf object needs a coordinate reference system (or crs) defined in order to work with it correctly. A coordinate reference system contains both a datum and a projection. The datum is how you georeference your points (in 3 dimensions!) onto a spheroid. The projection is how these points are mathematically transformed to represent the georeferenced point on a flat piece of paper. All coordinate reference systems require a datum. However, some coordinate reference systems are “unprojected” (also called geographic coordinate systems). Coordinates in latitude/longitude use a geographic (unprojected) coordinate system. One of the most commonly used geographic coordinate systems is WGS 1984.
+
ESRI has a blog post that explains these concepts in more detail with very helpful diagrams and examples.
+
You can view what crs is set by using the function st_crs().
This is pretty confusing looking. Without getting into the details, that long string says that this data has a geographic coordinate system (WGS84) with no projection. A convenient way to reference crs quickly is by using the EPSG code, a number that represents a standard projection and datum. You can check out a list of (lots!) of EPSG codes here.
+
We will use multiple EPSG codes in this lesson. Here they are, along with their more readable names:
+
+
3338: Alaska Albers (projected CRS)
+
4326: WGS84 (World Geodetic System 1984), used in GPS (unprojected CRS)
+
3857: Pseudo-Mercator, used in Google Maps, OpenStreetMap, Bing, ArcGIS, ESRI (projected CRS)
+
+
You will often need to transform your geospatial data from one coordinate system to another. The st_transform() function does this quickly for us. You may have noticed the maps above looked wonky because of the dateline. We might want to set a different projection for this data so it plots nicer. A good one for Alaska is called the Alaska Albers projection, with an EPSG code of 3338.
You can also use the sf package to create spatial joins, useful for when you want to utilize two datasets together.
+
+
+
+
+
+
+Exercise: How many people live in each of these Alaska regions?
+
+
+
+
We have some population data, but it gives the population by city, not by region. To determine the population per region we will need to:
+
+
Read in the population data from a csv and turn it into an sf object
+
Use a spatial join (st_join()) to assign each city to a region
+
Use group_by() and summarize() to calculate the total population by region
+
Save the spatial object you created using write_sf()
+
+
+
+
1. Read in alaska_population.csv using read.csv()
+
+
# read in population data
+pop <-read_csv("data/alaska_population.csv")
+
+
Turn pop into a spatial object
+
The st_join() function is a spatial left join. The arguments for both the left and right tables are objects of class sf which means we will first need to turn our population data.frame with latitude and longitude coordinates into an sf object.
+
We can do this easily using the st_as_sf() function, which takes as arguments the coordinates and the crs. The remove = F specification here ensures that when we create our geometry column, we retain our original latlng columns, which we will need later for plotting. Although it isn’t said anywhere explicitly in the file, let’s assume that the coordinate system used to reference the latitude longitude coordinates is WGS84, which has a crs number of 4326.
2. Join population data with Alaska regions data using st_join()
+
Now we can do our spatial join! You can specify what geometry function the join uses (st_intersects, st_within, st_crosses, st_is_within_distance…) in the join argument. The geometry function you use will depend on what kind of operation you want to do, and the geometries of your shapefiles.
+
In this case, we want to find what region each city falls within, so we will use st_within.
Turns out, this won’t work right now because our coordinate reference systems are not the same. Luckily, this is easily resolved using st_transform(), and projecting our population object into Alaska Albers.
There are many different types of joins you can do with geospatial data. Examine the help page for these joins (?st_within() will get you there). What other joins types might be appropriate for examining the relationship between points and polygyons? What about two sets of polygons?
+
+
+
3. Calculate the total population by region using group_by() and summarize()
+
Next we compute the total population for each region. In this case, we want to do a group_by() and summarise() as this were a regular data.frame. Otherwise all of our point geometries would be included in the aggregation, which is not what we want. Our goal is just to get the total population by region. We remove the sticky geometry using as.data.frame(), on the advice of the sf::tidyverse help page.
# A tibble: 6 × 2
+ region total_pop
+ <chr> <dbl>
+1 Aleutian Islands 8840
+2 Arctic 8419
+3 Bristol Bay 6947
+4 Chignik 311
+5 Cook Inlet 408254
+6 Copper River 2294
+
+
+
And use a regular left_join() to get the information back to the Alaska region shapefile. Note that we need this step in order to regain our region geometries so that we can make some maps.
+
+
pop_region_3338 <-left_join(ak_regions_3338, pop_region, by ="region")
+
+# plot to check
+plot(pop_region_3338["total_pop"])
+
+
+
+
+
So far, we have learned how to use sf and dplyr to use a spatial join on two datasets and calculate a summary metric from the result of that join.
+
+
+
+
+
+
+sf and tidyverse best practices
+
+
+
+
The group_by() and summarize() functions can also be used on sf objects to summarize within a dataset and combine geometries. Many of the tidyverse functions have methods specific for sf objects, some of which have additional arguments that wouldn’t be relevant to the data.frame methods. You can run ?sf::tidyverse to get documentation on the tidyversesf methods.
+
+
+
Say we want to calculate the population by Alaska management area, as opposed to region.
4. Save the spatial object to a new file using write_sf()
+
Save the spatial object to disk using write_sf() and specifying the filename. Writing your file with the extension .shp will assume an ESRI driver driver, but there are many other format options available.
We can also plot multiple shapefiles in the same plot. Say if we want to visualize rivers in Alaska, in addition to the location of communities, since many communities in Alaska are on rivers. We can read in a rivers shapefile, doublecheck the crs to make sure it is what we need, and then plot all three shapefiles - the regional population (polygons), the locations of cities (points), and the rivers (linestrings).
Note that although no EPSG code is set explicitly, with some sluething we can determine that this is EPSG:3338. This site is helpful for looking up EPSG codes.
9.6 Incorporate base maps into static maps using ggmap
+
The ggmap package has some functions that can render base maps (as raster objects) from open tile servers like Google Maps, Stamen, OpenStreetMap, and others.
+
We’ll need to transform our shapefile with population data by community to EPSG:3857 which is the crs used for rendering maps in Google Maps, Stamen, and OpenStreetMap, among others.
+
+
pop_3857 <- pop_3338 %>%
+st_transform(crs =3857)
+
+
Next, let’s grab a base map from the Stamen map tile server covering the region of interest. First we include a function that transforms the bounding box (which starts in EPSG:4326) to also be in the EPSG:3857 CRS, which is the projection that the map raster is returned in from Stamen. This is an issue with ggmap described in more detail here
+
+
# Define a function to fix the bbox to be in EPSG:3857
+# See https://github.com/dkahle/ggmap/issues/160#issuecomment-397055208
+ggmap_bbox_to_3857 <-function(map) {
+if (!inherits(map, "ggmap"))
+stop("map must be a ggmap object")
+# Extract the bounding box (in lat/lon) from the ggmap to a numeric vector,
+# and set the names to what sf::st_bbox expects:
+ map_bbox <-setNames(unlist(attr(map, "bb")),
+c("ymin", "xmin", "ymax", "xmax"))
+
+# Coonvert the bbox to an sf polygon, transform it to 3857,
+# and convert back to a bbox (convoluted, but it works)
+ bbox_3857 <-
+st_bbox(st_transform(st_as_sfc(st_bbox(map_bbox, crs =4326)), 3857))
+
+# Overwrite the bbox of the ggmap object with the transformed coordinates
+attr(map, "bb")$ll.lat <- bbox_3857["ymin"]
+attr(map, "bb")$ll.lon <- bbox_3857["xmin"]
+attr(map, "bb")$ur.lat <- bbox_3857["ymax"]
+attr(map, "bb")$ur.lon <- bbox_3857["xmax"]
+ map
+}
+
+
Next, we define the bounding box of interest, and use get_stamenmap() to get the basemap. Then we run our function defined above on the result of the get_stamenmap() call.
+
+
bbox <-c(-170, 52,-130, 64) # this is roughly southern Alaska
+ak_map <-get_stamenmap(bbox, zoom =4) # get base map
+ak_map_3857 <-ggmap_bbox_to_3857(ak_map) # fix the bbox to be in EPSG:3857
+
+
Finally, plot both the base raster map with the population data overlayed, which is easy now that everything is in the same projection (3857):
We can also make an interactive map from our data above using leaflet.
+
leaflet (unlike ggplot) will project data for you. The catch is that you have to give it both a projection (like Alaska Albers), and that your shapefile must use a geographic coordinate system. This means that we need to use our shapefile with the 4326 EPSG code. Remember you can always check what crs you have set using st_crs.
+
Here we define a leaflet projection for Alaska Albers, and save it as a variable to use later.
You might notice that this looks familiar! The syntax is a bit different, but most of this information is also contained within the crs of our shapefile:
There is a lot more functionality to sf including the ability to intersect polygons, calculate distance, create a buffer, and more. Here are some more great resources and tutorials for a deeper dive into this great package:
+
+
+
+
\ No newline at end of file
diff --git a/public/session_09_files/figure-html/unnamed-chunk-18-1.png b/public/session_09_files/figure-html/unnamed-chunk-18-1.png
new file mode 100644
index 00000000..3872dc37
Binary files /dev/null and b/public/session_09_files/figure-html/unnamed-chunk-18-1.png differ
diff --git a/public/session_09_files/figure-html/unnamed-chunk-19-1.png b/public/session_09_files/figure-html/unnamed-chunk-19-1.png
new file mode 100644
index 00000000..b499a675
Binary files /dev/null and b/public/session_09_files/figure-html/unnamed-chunk-19-1.png differ
diff --git a/public/session_09_files/figure-html/unnamed-chunk-20-1.png b/public/session_09_files/figure-html/unnamed-chunk-20-1.png
new file mode 100644
index 00000000..bcda06bb
Binary files /dev/null and b/public/session_09_files/figure-html/unnamed-chunk-20-1.png differ
diff --git a/public/session_09_files/figure-html/unnamed-chunk-21-1.png b/public/session_09_files/figure-html/unnamed-chunk-21-1.png
new file mode 100644
index 00000000..4d0d3eae
Binary files /dev/null and b/public/session_09_files/figure-html/unnamed-chunk-21-1.png differ
diff --git a/public/session_09_files/figure-html/unnamed-chunk-24-1.png b/public/session_09_files/figure-html/unnamed-chunk-24-1.png
new file mode 100644
index 00000000..0113aed3
Binary files /dev/null and b/public/session_09_files/figure-html/unnamed-chunk-24-1.png differ
diff --git a/public/session_09_files/figure-html/unnamed-chunk-28-1.png b/public/session_09_files/figure-html/unnamed-chunk-28-1.png
new file mode 100644
index 00000000..28a68d21
Binary files /dev/null and b/public/session_09_files/figure-html/unnamed-chunk-28-1.png differ
diff --git a/public/session_09_files/figure-html/unnamed-chunk-3-1.png b/public/session_09_files/figure-html/unnamed-chunk-3-1.png
new file mode 100644
index 00000000..02fff39a
Binary files /dev/null and b/public/session_09_files/figure-html/unnamed-chunk-3-1.png differ
diff --git a/public/session_09_files/figure-html/unnamed-chunk-8-1.png b/public/session_09_files/figure-html/unnamed-chunk-8-1.png
new file mode 100644
index 00000000..bab99cbc
Binary files /dev/null and b/public/session_09_files/figure-html/unnamed-chunk-8-1.png differ
diff --git a/public/session_10.html b/public/session_10.html
new file mode 100644
index 00000000..c9b41705
--- /dev/null
+++ b/public/session_10.html
@@ -0,0 +1,500 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 10 Introduction to Meta-Analysis
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
10Introduction to Meta-Analysis
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
ADD LINK TO MATERIALS
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_11.html b/public/session_11.html
new file mode 100644
index 00000000..9b520f3d
--- /dev/null
+++ b/public/session_11.html
@@ -0,0 +1,952 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 11 Working with Text Data in R
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
11Working with Text Data in R
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
11.0.1 Learning Objectives
+
+
What a token is and how they are used
+
How to use stop words
+
How to customize stop words
+
How to give structure to unstructured text
+
+
+
+
11.0.2 Introduction
+
Much of the information covered in this chapter is based on Text Mining with R: A Tidy Approach by Julia Silge and David Robinson. This is a great book if you want to go deeper into text analysis.
+
Text mining is the process by which unstructured text is transformed into a structured format to prepare it for analysis. This can range from the simple example we show in this lesson, to much more complicated processes such as using OCR (optical character recognition) to scan and extract text from pdfs, or web scraping.
+
Once text is in a structured format, analysis can be performed on it. The inherent benefit of quantitative text analysis is that it is highly scalable. With the right computational techniques, massive quantities of text can be mined and analyzed many, many orders of magnitude faster than it would take a human to do the same task. The downside, is that human language is inherently nuanced, and computers (as you may have noticed) think very differently than we do. In order for an analysis to capture this nuance, the tools and techniques for text analysis need to be set up with care, especially when the analysis becomes more complex.
+
There are a number of different types of text analysis. In this lesson we will show some simple examples of two: word frequency, and sentiment analysis.
+
+
Setup
+
First we’ll load the libraries we need for this lesson:
We are going to be working in the “tidy text format.” This format stipulates that the text column of our data frame contains rows with only one token per row. A token, in this case, is a meaningful unit of text. Depending on the analysis, that could be a word, two words, or phrase.
+
First, let’s create a data frame with responses to question 3, with the one token per row. We use the unnest_tokens function from tidytext, after selecting columns of interest.
You’ll see that we now have a very long data frame with only one word in each row of the text column. Some of the words aren’t so interesting though. The words that are likely not useful for analysis are called “stop words”. There is a list of stop words contained within the tidytext package and we can access it using the data function. We can then use the anti_join function to return only the words that are not in the stop word list.
Now, we can do normal dplyr analysis to examine the most commonly used words in question 3. The count function is helpful here. We could also do a group_by and summarize and get the same result. We can also arrange the results, and get the top 10 using slice_head.
Right now, our counts of the most commonly used non-stop words are only moderately informative because they don’t take into context how many other words, responses, and courses there are. A widely used metric to analyze and draw conclusions from word frequency, including frequency within documents (or courses, in our case) is called tf-idf. This is the term frequency (number of appearances of a term divided by total number of terms), multiplied by the inverse document frequency (the natural log of the number of documents divided by the number of documents containing the term). The tidytext book has great examples on how to calculate this metric easily using some built in functions to the package.
Perhaps not surprisingly, the word data is mentioned a lot! In this case, it might be useful to add it to our stop words list. You can create a data.frame in place with your word, and an indication of the lexicon (in this case, your own, which we can call custom). Then we use rbind to bind that data frame with our previous stop words data frame.
The above example showed how to analyze text that was contained within a tabular format (a csv file). There are many other text formats that you might want to analyze, however. This might include pdf documents, websites, word documents, etc. Here, we’ll look at how to read in the text from a PDF document into an analysis pipeline like above.
+
Before we begin, it is important to understand that not all PDF documents can be processed this way. PDF files can store information in many ways, including both images and text. Some PDF documents, particularly older ones, or scanned documents, are images of text and the bytes making up the document do not contain a ‘readable’ version of the text in the image, it is an image not unlike one you would take with a camera. Other PDF documents will contain the text as character strings, along with the information on how to render it on the page (such as position and font). The analysis that follows will only work on PDF files that fit the second description of the format. If the PDF document you are trying to analyze is more like the first, you would need to first use a technique called Optical Character Recognition (OCR) to interpret the text in the image and store it in a parsable way. Since this document can be parsed, we’ll proceed without doing OCR.
+
First we’ll load another library, pdftools, which will read in our PDF, and the stringr library, which helps manipulate character strings.
The pdf_text function extracts the text from the PDF file, returning a vector of character strings with a length equal to the number of pages in the file. So, our return value is loaded into R, but maybe not that useful yet because it is just a bunch of really long strings.
+
+
txt <-pdf_text(path)
+
+class(txt)
+
+
[1] "character"
+
+
+
Luckily, there is a function that will turn the pdf text data we just read in to a form that is compatible with the rest of the tidytext tools. The tibble::enframe function, converts the list into a data.frame. We then change one column name to describe what the column actually is (page number).
If we look at the result, and then back at the original document, it is clear that there is more work needed to get the data to an analyzable state. The header and footer of each page of the PDF were included in the text we analyzed, and since they are repeated every page (and aren’t really the subject of our inquiry anyway), should be removed from the text after we read it into R but before we try to calculate the most used words. It might also be beneficial to try and separate out the questions from responses, if we wanted to analyze just the responses or just the questions.
+
To help us clean things up, first let’s split our value column currently containing full pages of text by where there are double newlines (\n\n). You can see in the original PDF how this demarcates the responses, which contain single newlines within each paragraph, and two new lines (an empty line) between paragraphs. You can see an example of this within the text we have read in by examining just the first 500 characters of the first page of data.
+
+
substr(txt_clean$value[1], 1,500)
+
+
[1] " Population Dynamics in Greenland\n Focus Group Meetings\n\nDate of the focus group meeting: Ilulissat April 10th, 2017\nName and title of the Researchers: Q3: Dr. Elizabeth Rink & Q1: Dr. Gitte Adler\nReimer\nName of the facilitator: Q2: Majbritt Didriksen Raal\nRecord No.: 170410_0077\n\nFG # 8\n\nQ2: Ilulissat the April 10th, 2017, we are going to talk to the Professional Group.\n\nQ1: Welcome, we are working on the final part of t"
+
+
+
To split our character vectors, we will use the str_split function. It splits a character vector according to a separator, and stores the values in a list. To show more clearly, let’s look at a dummy example. We can split a string of comma separated numbers into a list with each individual number.
+
+
x <-"1,2,3,4,5"
+str_split(x, ",")
+
+
[[1]]
+[1] "1" "2" "3" "4" "5"
+
+
+
In the real dataset, we’ll use str_split and mutate, which will create a list of values within each row of the value column. So each cell in the value column contains a list of values like the result of the example above. We can “flatten” this data so that each cell only has one value by using the unnest function, which takes as arguments the columns to flatten. Let’s take the example above, and make it a little more like our real data.
+
First turn the original dummy vector into a data frame, and do our split as before, this time using mutate.
You can see that our questions and answers are now easily visible because they all start with wither Q or A. The other lines are blank lines or header/footer lines from the document. So, let’s extract the first few characters of each line into a new column using substr, with the goal that we’ll run a filter for rows that start with Q or A, thus discarding all the other rows.
+
First, we extract the first 4 characters of each row and using mutate create a new column with those values called id.
So unfortunately some of the text is a tiny bit garbled, there are newlines before at least some Q and A ids. We can use mutate again with str_replace to replace those \n with a blank value, which will remove them.
Finally, we can run the filter. Here, we filter for id values that start with either a Q or an A using the grepl function and a regular expression. We won’t go much into regular expression details, but there is a chapter in the appendix for more about how they work.
+
Here is an example of grepl in action. It returns a true or false for whether the value of x starts with (signified by ^) a Q or A (signified by QA in square brackets).
+
+
x <-c("Q3", "F1", "AAA", "FA")
+grepl("^[QA]", x)
+
+
[1] TRUE FALSE TRUE FALSE
+
+
+
So let’s run that within a filter which will return only rows where the grepl would return TRUE.
Finally, as our last cleaning step we replace all instances of the start of a string that contains a Q or A, followed by a digit and a colon, with an empty string (removing them from the beginning of the line.
In sentiment analysis, tokens (in this case our single words) are evaluated against a dictionary of words where a sentiment is assigned to the word. There are many different sentiment lexicons, some with single words, some with more than one word, and some that are aimed at particular disciplines. When embarking on a sentiment analysis project, choosing your lexicon is one that should be done with care. Sentiment analysis can also be done using machine learning algorithms.
+
With that in mind, we will next do a very simple sentiment analysis on our Q3 and Q4 answers using the bing lexicon from Bing Liu and collaborators, which ships with the tidytext package.
+
First we will use the get_sentiments function to load the lexicon.
+
+
bing <-get_sentiments("bing")
+
+
Next we do an inner join to return the words from question 3 that are contained within the lexicon.
+
+
q3_sent <-inner_join(q3, bing, by ="word")
+
+
+
+
+
+
+
+
+
There are a variety of directions you could go from here, analysis wise, such as calculating an overall sentiment index for that question, plotting sentiment against some other variable, or, making a fun word cloud like below! Here we bring in reshape2::acast to create a sentiment matrix for each word, and pass that into wordcloud::comparison.cloud to look at a wordcloud that indicates the frequency and sentiment of the words in our responses.
how to analyze structured text data from a survey using stop words and sentiment analysis
+
how to give structure to unstructured text data from a PDF to do some analysis using stop words and times words are used
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_11_files/figure-html/unnamed-chunk-45-1.png b/public/session_11_files/figure-html/unnamed-chunk-45-1.png
new file mode 100644
index 00000000..74bdef9d
Binary files /dev/null and b/public/session_11_files/figure-html/unnamed-chunk-45-1.png differ
diff --git a/public/session_11_files/figure-html/unnamed-chunk-46-1.png b/public/session_11_files/figure-html/unnamed-chunk-46-1.png
new file mode 100644
index 00000000..0cca7e20
Binary files /dev/null and b/public/session_11_files/figure-html/unnamed-chunk-46-1.png differ
diff --git a/public/session_12.html b/public/session_12.html
new file mode 100644
index 00000000..985cefa5
--- /dev/null
+++ b/public/session_12.html
@@ -0,0 +1,541 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 12 Working with US Census Data
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
12Working with US Census Data
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Learning Objectives
+
+
+
12.1 Overview
+
(Chapter 1 - 5 min) - General view of US Census Data
+
+
+
12.2 Introduction to tidycensus
+
(Chapter 2 - 25-30 min)
+
+
Basic data requests
+
Fundamentals of data package and the options it offers
+
+
+
+
12.3 Getting Census Data ready for analysis
+
(Chapter 3 - 20-25 min)
+
+
Data wranglw again? Yes!
+
Handling errors in data
+
+
+
+
12.4 Visualizing Censis Data with ggplot2
+
(Chapter 4 - 20 min)
+
+
+
12.5 Maps and Census Data
+
( Chapter 5 and 6 - 10 min?)
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_13.html b/public/session_13.html
new file mode 100644
index 00000000..1bd1a783
--- /dev/null
+++ b/public/session_13.html
@@ -0,0 +1,795 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 13 Reproducible Surveys
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
13Reproducible Surveys
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
13.0.1 Learning Objectives
+
+
Overview of survey tools
+
Generating a reproducible survey report with Qualtrics
+
+
+
+
13.0.2 Introduction
+
Surveys and questionnaires are commonly used research methods within social science and other fields. For example, understanding regional and national population demographics, income, and education as part of the National Census activity, assessing audience perspectives on specific topics of research interest (e.g. the work by Tenopir and colleagues on Data Sharing by Scientists), evaluation of learning deliverables and outcomes, and consumer feedback on new and upcoming products. These are distinct from the use of the term survey within natural sciences, which might include geographical surveys (“the making of measurement in the field from which maps are drawn”), ecological surveys (“the process whereby a proposed development site is assess to establish any environmental impact the development may have”) or biodiversity surveys (“provide detailed information about biodiversity and community structure”) among others.
+
Although surveys can be conducted on paper or verbally, here we focus on surveys done via software tools. Needs will vary according to the nature of the research being undertaken. However, there is fundamental functionality that survey software should provide including:
+
+
The ability to create and customize questions
+
The ability to include different types of questions
+
The ability to distribute the survey and manage response collection
+
The ability to collect, summarize, and (securely) store response data
+
+
More advanced features can include:
+
+
Visual design and templates - custom design might include institutional branding or aesthetic elements. Templates allow you to save these designs and apply to other surveys
+
Question piping - piping inserts answers from previous questions into upcoming questions and can personalize the survey experience for users
+
Survey logic - with question logic and skip logic you can control the inclusion / exclusion of questions based on previous responses
+
Randomization - the ability to randomize the presentation of questions within (blocks of) the survey
+
Branching - this allows for different users to take different paths through the survey. Similar to question logic but at a bigger scale
+
Language support - automated translation or multi-language presentation support
+
Shared administration - enables collaboration on the survey and response analysis
+
Survey export - ability to download (export) the survey instrument
+
Reports - survey response visualization and reporting tools
+
Institutional IRB approved - institutional IRB policy may require certain software be used for research purposes
+
+
Commonly used survey software within academic (vs market) research include Qualtrics, Survey Monkey and Google Forms. Both qualtrics and survey monkey are licensed (with limited functionality available at no cost) and google forms is free.
+
+
+
+
13.0.3 Building workflows using Qualtrics
+
In this lesson we will use the qualtRics package to reproducible access some survey results set up for this course.
+
+
13.0.3.1 Survey Instrument
+
The survey is very short, only four questions. The first question is on it’s own page and is a consent question, after a couple of short paragraphs describing what the survey is, it’s purpose, how long it will take to complete, and who is conducting it. This type of information is required if the survey is governed by an IRB, and the content will depend on the type of research being conducted. In this case, this survey is not for research purposes, and thus is not governed by IRB, but we still include this information as it conforms to the Belmont Principles. The Belmont Principles identify the basic ethical principles that should underlie research involving human subjects.
+
+
The three main questions of the survey have three types of responses: a multiple choice answer, a multiple choice answer which also includes an “other” write in option, and a free text answer. We’ll use the results of this survey, which was sent out to NCEAS staff to fill out, to learn about how to create a reproducible survey report.
+
+
First, open a new RMarkdown document and add a chunk to load the libraries we’ll need for this lesson:
Next, we need to set the API credentials. This function modifies the .Renviron file to set your API key and base URL so that you can access Qualtrics programmatically.
+
The API key is as good as a password, so care should be taken to not share it publicly. For example, you would never want to save it in a script. The function below is the rare exception of code that should be run in the console and not saved. It works in a way that you only need to run it once, unless you are working on a new computer or your credentials changed. Note that in this book, we have not shared the actual API key, for the reasons outlined above. You should have an e-mail with the API key in it. Copy and paste it as a string to the api_key argument in the function below:
The .Renviron file is a special user controlled file that can create environment variables. Every time you open Rstudio, the variables in your environment file are loaded as…environment variables! Environment variables are named values that are accessible by your R process. They will not show up in your environment pane, but you can get a list of all of them using Sys.getenv(). Many are system defaults.
+
+
+
+
To view or edit your .Renviron file, you can use usethis::edit_r_environ().
+
To get a list of all the surveys in your Qualtrics instance, use the all_surveys function.
This function returns a list of surveys, in this case only one, and information about each, including an identifier and it’s name. We’ll need that identifier later, so let’s go ahead and extract it using base R from the data frame.
+
+
i <-which(surveys$name =="Survey for Data Science Training")
+id <- surveys$id[i]
+
+
You can retrieve a list of the questions the survey asked using the survey_questions function and the survey id.
This returns a data.frame with one row per question with columns for question id, question name, question text, and whether the question was required. This is helpful to have as a reference for when you are looking at the full survey results.
+
To get the full survey results, run fetch_survey with the survey id.
+
+
survey_results <-fetch_survey(id)
+
+
The survey results table has tons of information in it, not all of which will be relevant depending on your survey. The table has identifying information for the respondents (eg: ResponseID, IPaddress, RecipientEmail, RecipientFirstName, etc), much of which will be empty for this survey since it is anonymous. It also has information about the process of taking the survey, such as the StartDate, EndDate, Progress, and Duration. Finally, there are the answers to the questions asked, with columns labeled according to the qname column in the questions table (eg: Q1, Q2, Q3). Depending on the type of question, some questions might have multiple columns associated with them. We’ll have a look at this more closely in a later example.
+
+
+
Question 2
+
Let’s look at the responses to the second question in the survey, “How long have you been programming?” Remember, the first question was the consent question.
+
We’ll use the dplyr and tidyr tools we learned earlier to extract the information. Here are the steps:
We can show these results in a table using the kable function from the knitr package:
+
+
kable(q2, col.names =c("How long have you been programming?",
+"Number of responses")) %>%
+kable_styling()
+
+
+
+
13.0.3.2 Question 3
+
For question 3, we’ll use a similar workflow. For this question, however there are two columns containing survey answers. One contains the answers from the controlled vocabulary, the other contains any free text answers users entered.
+
To present this information, we’ll first show the results of the controlled answers as a plot. Below the plot, we’ll include a table showing all of the free text answers for the “other” option.
ggplot(data = q3, mapping =aes(x = Q3, y = n)) +
+geom_col() +
+labs(x ="What language do you currently use most frequently?", y ="Number of reponses") +
+theme_minimal()
+
+
Now we’ll extract the free text responses:
+
+
q3_text <- survey_results %>%
+select(Q3_7_TEXT) %>%
+drop_na()
+
+kable(q3_text, col.names =c("Other responses to 'What language do you currently use mose frequently?'")) %>%
+kable_styling()
+
+
+
+
13.0.3.3 Question 4
+
The last question is just a free text question, so we can just display the results as is.
+
+
q4 <- survey_results %>%
+select(Q4) %>%
+rename(`What data science tool or language are you most excited to learn next?`= Q4) %>%
+drop_na()
+
+kable(q4, col.names ="What data science tool or language are you most excited to learn next?") %>%
+kable_styling()
+
+
+
+
+
13.0.4 Other survey tools
+
+
Google forms
+
Google forms can be a great way to set up surveys, and it is very easy to interact with the results using R. The benefits of using google forms are a simple interface and easy sharing between collaborators, especially when writing the survey instrument.
+
The downside is that google forms has far fewer features than Qualtrics in terms of survey flow and appearance.
+
To show how we can link R into our survey workflows, I’ve set up a simple example survey here.
+
I’ve set up the results so that they are in a new spreadsheet here:. To access them, we will use the googlesheets4 package.
+
First, open up a new R script and load the googlesheets4 library:
+
+
library(googlesheets4)
+
+
Next, we can read the sheet in using the same URL that you would use to share the sheet with someone else. Right now, this sheet is public
The first time you run this, you should get a popup window in your web browser asking you to confirm that you want to provide access to your google sheets via the tidyverse (googlesheets) package.
+
My dialog box looked like this:
+
+
Make sure you click the third check box enabling the Tidyverse API to see, edit, create, and delete your sheets. Note that you will have to tell it to do any of these actions via the R code you write.
+
When you come back to your R environment, you should have a data frame containing the data in your sheet! Let’s take a quick look at the structure of that sheet.
+
+
dplyr::glimpse(responses)
+
+
Rows: 10
+Columns: 5
+$ Timestamp <dttm> 2022-04-15 13:…
+$ `To what degree did the event meet your expectations?` <chr> "Met expectatio…
+$ `To what degree did your knowledge improve?` <chr> "Increase", "Si…
+$ `What did you like most about the event?` <chr> "the cool instr…
+$ `What might you change about the event?` <chr> "more snacks", …
+
+
+
So, now that we have the data in a standard R data.frame, we can easily summarize it and plot results. By default, the column names in the sheet are the long fully descriptive questions that were asked, which can be hard to type. We can save those questions into a vector for later reference, like when we want to use the question text for plot titles.
chr [1:4] "To what degree did the event meet your expectations?" ...
+
+
+
We can make the responses data frame more compact by renaming the columns of the vector with short numbered names of the form Q1. Note that, by using a sequence, this should work for sheets from just a few columns to many hundreds of columns, and provides a consistent question naming convention.
Now that we’ve renamed our columns, let’s summarize the responses for the first question. We can use the same pattern that we usually do to split the data from Q1 into groups, then summarize it by counting the number of records in each group, and then merge the count of each group back together into a summarized data frame. We can then plot the Q1 results using ggplot:
+
+
q1 <- responses %>%
+ dplyr::select(Q1) %>%
+ dplyr::group_by(Q1) %>%
+ dplyr::summarise(n = dplyr::n())
+
+ggplot2::ggplot(data = q1, mapping =aes(x = Q1, y = n)) +
+geom_col() +
+labs(x = questions[1],
+y ="Number of reponses",
+title ="To what degree did the course meet expectations?") +
+theme_minimal()
+
+
+
Bypassing authentication for public sheets
+
If you don’t want to go through a little interactive dialog every time you read in a sheet, and your sheet is public, you can run the function gs4_deauth() to access the sheet as a public user. This is helpful for cases when you want to run your code non-interactively. This is actually how I set it up for this book to build!
+
+
+
Challenge
+
Now that you have some background in accessing survey data from common tools, let’s do a quick exercise with Google Sheets. First, create a google sheet with the following columns that reflect a hypothetical survey result:
+
+
Timestamp
+
Q1: How much did your proficiency with survey tools in R change? 1 = None, 2 = A little, 3 = A lot
+
Q2: How many years or partial years had you used R prior to this course?
+
Q3: How many years or partial years had you used statistics before this course?
+
+
Next populate the spreadhsheet with 5 to 10 rows of sample data that you make up. Now that you have the Google sheet in place, copy its URL and use it to do the following in R:
+
+
Load the google sheet into an R data.frame using the googlesheets package
+
Save the column headers as a vector of questions
+
Rename the question columns with short, consistent names
+
Summarize and plot the results for Q1 as a bar chart.
+
+
+
+
+
Survey Monkey
+
Similar to Qualtrics and qualtRics, there is an open source R package for working with data in Survey Monkey: Rmonkey. However, the last updates were made 5 years ago, an eternity in the software world, so it may or may not still function as intended.
+
There are also commercial options available. For example, cdata have a driver and R package that enable access to an analysis of Survey Monkey data through R.
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_14.html b/public/session_14.html
new file mode 100644
index 00000000..d9173a2d
--- /dev/null
+++ b/public/session_14.html
@@ -0,0 +1,501 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 14 Guest Speaker
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
14Guest Speaker
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Add material
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_15.html b/public/session_15.html
new file mode 100644
index 00000000..c07b13ea
--- /dev/null
+++ b/public/session_15.html
@@ -0,0 +1,500 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 15 Synthesis Time
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
15Synthesis Time
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/public/session_16.html b/public/session_16.html
new file mode 100644
index 00000000..69dd5ea7
--- /dev/null
+++ b/public/session_16.html
@@ -0,0 +1,1052 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 16 Shiny
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
16Shiny
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
16.0.1 Learning Objectives
+
In this lesson we will:
+
+
review the capabilities in Shiny applications
+
learn about the basic layout for Shiny interfaces
+
learn about the server component for Shiny applications
+
build a simple shiny application for interactive plotting
+
+
+
+
16.0.2 Overview
+
Shiny is an R package for creating interactive data visualizations embedded in a web application that you and your colleagues can view with just a web browser. Shiny apps are relatively easy to construct, and provide interactive features for letting others share and explore data and analyses.
Most any kind of analysis and visualization that you can do in R can be turned into a useful interactive visualization for the web that lets people explore your data more intuitively But, a Shiny application is not the best way to preserve or archive your data. Instead, for preservation use a repository that is archival in its mission like the KNB Data Repository, Zenodo, or Dryad. This will assign a citable identifier to the specific version of your data, which you can then read in an interactive visualiztion with Shiny.
+
For example, the data for the Alaska Board of Fisheries application is published on the KNB and is citable as:
+
Meagan Krupa, Molly Cunfer, and Jeanette Clark. 2017. Alaska Board of Fisheries Proposals 1959-2016. Knowledge Network for Biocomplexity. doi:10.5063/F1QN652R.
+
While that is the best citation and archival location of the dataset, using Shiny, one can also provide an easy-to-use exploratory web application that you use to make your point that directly loads the data from the archival site. For example, the Board of Fisheries application above lets people who are not inherently familiar with the data to generate graphs showing the relationships between the variables in the dataset.
+
We’re going to create a simple shiny app with two sliders so we can interactively control inputs to an R function. These sliders will allow us to interactively control a plot.
+
+
+
16.0.3 Create a sample shiny application
+
+
File > New > Shiny Web App…
+
Set some fields:
+
+
Name it “myapp” or something else
+
Select “Single File”
+
Choose to create it in a new folder called ‘shiny-demo’
+
Click Create
+
+
+
RStudio will create a new file called app.R that contains the Shiny application.
+Run it by choosing Run App from the RStudio editor header bar. This will bring up the default demo Shiny application, which plots a histogram and lets you control the number of bins in the plot.
+
+
Note that you can drag the slider to change the number of bins in the histogram.
+
+
+
16.0.4 Shiny architecture
+
A Shiny application consists of two functions, the ui and the server. The ui function is responsible for drawing the web page, while the server is responsible for any calculations and for creating any dynamic components to be rendered.
+
Each time that a user makes a change to one of the interactive widgets, the ui grabs the new value (say, the new slider min and max) and sends a request to the server to re-render the output, passing it the new input values that the user had set. These interactions can sometimes happen on one computer (e.g., if the application is running in your local RStudio instance). Other times, the ui runs on the web browser on one computer, while the server runs on a remote computer somewhere else on the Internet (e.g., if the application is deployed to a web server).
+
+
+
+
16.0.5 Interactive scatterplots
+
Let’s modify this application to plot Yolo bypass secchi disk data in a time-series, and allow aspects of the plot to be interactively changed.
+
+
16.0.5.1 Load data for the example
+
Use this code to load the data at the top of your app.R script. Note we are using contentId again, and we have filtered for some species of interest.
+
+
library(shiny)
+library(contentid)
+library(dplyr)
+library(ggplot2)
+library(lubridate)
+
+sha1 <-'hash://sha1/317d7f840e598f5f3be732ab0e04f00a8051c6d0'
+delta.file <- contentid::resolve(sha1, registries=c("dataone"), store =TRUE)
+
+# fix the sample date format, and filter for species of interest
+delta_data <-read.csv(delta.file) %>%
+mutate(SampleDate =mdy(SampleDate)) %>%
+filter(grepl("Salmon|Striped Bass|Smelt|Sturgeon", CommonName))
+
+names(delta_data)
+
+
+
+
16.0.5.2 Add a simple timeseries using ggplot
+
We know there has been a lot of variation through time in the delta, so let’s plot a time-series of Secchi depth. We do so by switching out the histogram code for a simple ggplot, like so:
If you now reload the app, it will display the simple time-series instead of the histogram. At this point, we haven’t added any interactivity.
+
In a Shiny application, the server function provides the part of the application that creates our interactive components, and returns them to the user interface (ui) to be displayed on the page.
+
+
+
16.0.5.3 Add sliders to set the start and end date for the X axis
+
To make the plot interactive, first we need to modify our user interface to include widgits that we’ll use to control the plot. Specifically, we will add a new slider for setting the minDate parameter, and modify the existing slider to be used for the maxDate parameter. To do so, modify the sidebarPanel() call to include two sliderInput() function calls:
If you reload the app, you’ll see two new sliders, but if you change them, they don’t make any changes to the plot. Let’s fix that.
+
+
+
16.0.5.4 Connect the slider values to the plot
+
Finally, to make the plot interactive, we can use the input and output variables that are passed into the server function to access the current values of the sliders. In Shiny, each UI component is given an input identifier when it is created, which is used as the name of the value in the input list. So, we can access the minimum depth as input$minDate and the max as input$maxDate. Let’s use these values now by adding limits to our X axis in the ggplot:
At this point, we have a fully interactive plot, and the sliders can be used to change the min and max of the Depth axis.
+
+
Looks so shiny!
+
+
+
16.0.5.5 Reversed Axes?
+
What happens if a clever user sets the minimum for the X axis at a greater value than the maximum? You’ll see that the direction of the X axis becomes reversed, and the plotted points display right to left. This is really an error condition. Rather than use two independent sliders, we can modify the first slider to output a range of values, which will prevent the min from being greater than the max. You do so by setting the value of the slider to a vector of length 2, representing the default min and max date for the slider, such as c(as.Date("1998-01-01"), as.Date("2020-01-01")). So, delete the second slider, rename the first, and provide a vector for the value, like this:
Now, modify the ggplot to use this new date slider value, which now will be returned as a vector of length 2. The first element of the depth vector is the min, and the second is the max value on the slider.
16.0.6 Extending the user interface with dynamic plots
+
If you want to display more than one plot in your application, and provide a different set of controls for each plot, the current layout would be too simple. Next we will extend the application to break the page up into vertical sections, and add a new plot in which the user can choose which variables are plotted. The current layout is set up such that the FluidPage contains the title element, and then a sidebarLayout, which is divided horizontally into a sidebarPanel and a mainPanel.
+
+
+
16.0.6.1 Vertical layout
+
To extend the layout, we will first nest the existing sidebarLayout in a new verticalLayout, which simply flows components down the page vertically. Then we will add a new sidebarLayout to contain the bottom controls and graph.
+
+
This mechanism of alternately nesting vertical and horizontal panels can be used to segment the screen into boxes with rules about how each of the panels is resized, and how the content flows when the browser window is resized. The sidebarLayout works to keep the sidebar about 1/3 of the box, and the main panel about 2/3, which is a good proportion for our controls and plots. Add the verticalLayout, and the second sidebarLayout for the second plot as follows:
+
+
verticalLayout(
+# Sidebar with a slider input for depth axis
+sidebarLayout(
+sidebarPanel(
+sliderInput("date",
+"Date:",
+min =as.Date("1998-01-01"),
+max =as.Date("2020-01-01"),
+value =c(as.Date("1998-01-01"), as.Date("2020-01-01")))
+ ),
+# Show a plot of the generated distribution
+mainPanel(
+plotOutput("distPlot")
+ )
+ ),
+
+ tags$hr(),
+
+sidebarLayout(
+sidebarPanel(
+selectInput("x_variable", "X Variable", cols, selected ="SampleDate"),
+selectInput("y_variable", "Y Variable", cols, selected ="Count"),
+selectInput("color_variable", "Color", cols, selected ="CommonName")
+ ),
+
+# Show a plot with configurable axes
+mainPanel(
+plotOutput("varPlot")
+ )
+ ),
+ tags$hr()
+
+
Note that the second sidebarPanel uses three selectInput elements to provide dropdown menus with the variable columns (cols) from our data frame. To manage that, we need to first set up the cols variable, which we do by saving the variables names from the delta_data data frame to a variable:
+
+
sha1 <-'hash://sha1/317d7f840e598f5f3be732ab0e04f00a8051c6d0'
+delta.file <- contentid::resolve(sha1, registries=c("dataone"), store =TRUE)
+
+# fix the sample date format, and filter for species of interest
+delta_data <-read.csv(delta.file) %>%
+mutate(SampleDate =mdy(SampleDate)) %>%
+filter(grepl("Salmon|Striped Bass|Smelt|Sturgeon", CommonName))
+
+cols <-names(delta_data)
+
+
+
+
16.0.6.2 Add the dynamic plot
+
Because we named the second plot varPlot in our UI section, we now need to modify the server to produce this plot. Its very similar to the first plot, but this time we want to use the selected variables from the user controls to choose which variables are plotted. These variable names from the $input are character strings, and so would not be recognized as symbols in the aes mapping in ggplot. As recommended by the tidyverse authors, we use the non-standard evaluation syntax of .data[["colname"]] to access the variables.
Citing the data that we used for this application is the right thing to do, and easy. You can add arbitrary HTML to the layout using utility functions in the tags list.
+
+
# Application title
+titlePanel("Yolo Bypass Fish and Water Quality Data"),
+p("Data for this application are from: "),
+ tags$ul(
+ tags$li("Interagency Ecological Program: Fish catch and water quality data from the Sacramento River floodplain and tidal slough, collected by the Yolo Bypass Fish Monitoring Program, 1998-2018.",
+ tags$a("doi:10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f", href="http://doi.org/10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f")
+ )
+ ),
+ tags$br(),
+ tags$hr(),
+
+
The final application shows the data citation, the depth plot, and the configurable scatterplot in three distinct panels.
+
+
+
+
16.0.8 Publishing Shiny applications
+
Once you’ve finished your app, you’ll want to share it with others. To do so, you need to publish it to a server that is set up to handle Shiny apps.
+Your main choices are:
This is a service offered by RStudio, which is initially free for 5 or fewer apps and for limited run time, but has paid tiers to support more demanding apps. You can deploy your app using a single button push from within RStudio.
This is an open source server which you can deploy for free on your own hardware. It requires more setup and configuration, but it can be used without a fee.
This is a paid product you install on your local hardware, and that contains the most advanced suite of services for hosting apps and RMarkdown reports. You can publish using a single button click from RStudio.
The easiest path is to create an account on shinyapps.io, and then configure RStudio to use that account for publishing. Instructions for enabling your local RStudio to publish to your account are displayed when you first log into shinyapps.io:
+
+
Once your account is configured locally, you can simply use the Publish button from the application window in RStudio, and your app will be live before you know it!
+
+
+
+
+
16.0.9 Summary
+
Shiny is a fantastic way to quickly and efficiently provide data exploration for your data and code. We highly recommend it for its interactivity, but an archival-quality repository is the best long-term home for your data and products. In this example, we used data drawn directly from the EDI repository in our Shiny app, which offers both the preservation guarantees of an archive, plus the interactive data exploration from Shiny. You can utilize the full power of R and the tidyverse for writing your interactive applications.
+
+
+
16.0.10 Full source code for the final application
+
+
library(shiny)
+library(contentid)
+library(dplyr)
+library(ggplot2)
+library(lubridate)
+
+# read in the data from EDI
+sha1 <-'hash://sha1/317d7f840e598f5f3be732ab0e04f00a8051c6d0'
+delta.file <- contentid::resolve(sha1, registries=c("dataone"), store =TRUE)
+
+# fix the sample date format, and filter for species of interest
+delta_data <-read.csv(delta.file) %>%
+mutate(SampleDate =mdy(SampleDate)) %>%
+filter(grepl("Salmon|Striped Bass|Smelt|Sturgeon", CommonName))
+
+cols <-names(delta_data)
+
+
+
+# Define UI for application that draws a two plots
+ui <-fluidPage(
+
+# Application title and data source
+titlePanel("Sacramento River floodplain fish and water quality dataa"),
+p("Data for this application are from: "),
+ tags$ul(
+ tags$li("Interagency Ecological Program: Fish catch and water quality data from the Sacramento River floodplain and tidal slough, collected by the Yolo Bypass Fish Monitoring Program, 1998-2018.",
+ tags$a("doi:10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f", href="http://doi.org/10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f")
+ )
+ ),
+ tags$br(),
+ tags$hr(),
+
+verticalLayout(
+# Sidebar with a slider input for time axis
+sidebarLayout(
+sidebarPanel(
+sliderInput("date",
+"Date:",
+min =as.Date("1998-01-01"),
+max =as.Date("2020-01-01"),
+value =c(as.Date("1998-01-01"), as.Date("2020-01-01")))
+ ),
+# Show a plot of the generated timeseries
+mainPanel(
+plotOutput("distPlot")
+ )
+ ),
+
+ tags$hr(),
+
+sidebarLayout(
+sidebarPanel(
+selectInput("x_variable", "X Variable", cols, selected ="SampleDate"),
+selectInput("y_variable", "Y Variable", cols, selected ="Count"),
+selectInput("color_variable", "Color", cols, selected ="CommonName")
+ ),
+
+# Show a plot with configurable axes
+mainPanel(
+plotOutput("varPlot")
+ )
+ ),
+ tags$hr()
+ )
+)
+
+# Define server logic required to draw the two plots
+server <-function(input, output) {
+
+# turbidity plot
+ output$distPlot <-renderPlot({
+
+ggplot(delta_data, mapping =aes(SampleDate, Secchi)) +
+geom_point(colour="red", size=4) +
+xlim(c(input$date[1],input$date[2])) +
+theme_light()
+ })
+
+# mix and match plot
+ output$varPlot <-renderPlot({
+ggplot(delta_data, aes(x = .data[[input$x_variable]],
+y = .data[[input$y_variable]],
+color = .data[[input$color_variable]])) +
+geom_point(size =4) +
+theme_light()
+ })
+}
+
+
+# Run the application
+shinyApp(ui = ui, server = server)
+
+
+
+
16.0.11 A shinier app with tabs and a map!
+
+
library(shiny)
+library(contentid)
+library(dplyr)
+library(tidyr)
+library(ggplot2)
+library(lubridate)
+library(shinythemes)
+library(sf)
+library(leaflet)
+library(snakecase)
+
+# read in the data from EDI
+sha1 <-'hash://sha1/317d7f840e598f5f3be732ab0e04f00a8051c6d0'
+delta.file <- contentid::resolve(sha1, registries=c("dataone"), store =TRUE)
+
+# fix the sample date format, and filter for species of interest
+delta_data <-read.csv(delta.file) %>%
+mutate(SampleDate =mdy(SampleDate)) %>%
+filter(grepl("Salmon|Striped Bass|Smelt|Sturgeon", CommonName)) %>%
+rename(DissolvedOxygen = DO,
+Ph = pH,
+SpecificConductivity = SpCnd)
+
+cols <-names(delta_data)
+
+sites <- delta_data %>%
+distinct(StationCode, Latitude, Longitude) %>%
+drop_na() %>%
+st_as_sf(coords =c('Longitude','Latitude'), crs =4269, remove =FALSE)
+
+
+
+# Define UI for application
+ui <-fluidPage(
+navbarPage(theme =shinytheme("flatly"), collapsible =TRUE,
+HTML('<a style="text-decoration:none;cursor:default;color:#FFFFFF;" class="active" href="#">Sacramento River Floodplain Data</a>'), id="nav",
+windowTitle ="Sacramento River floodplain fish and water quality data",
+
+tabPanel("Data Sources",
+verticalLayout(
+# Application title and data source
+titlePanel("Sacramento River floodplain fish and water quality data"),
+p("Data for this application are from: "),
+ tags$ul(
+ tags$li("Interagency Ecological Program: Fish catch and water quality data from the Sacramento River floodplain and tidal slough, collected by the Yolo Bypass Fish Monitoring Program, 1998-2018.",
+ tags$a("doi:10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f", href="http://doi.org/10.6073/pasta/b0b15aef7f3b52d2c5adc10004c05a6f")
+ )
+ ),
+ tags$br(),
+ tags$hr(),
+p("Map of sampling locations"),
+mainPanel(leafletOutput("map"))
+ )
+ ),
+
+tabPanel(
+"Explore",
+verticalLayout(
+mainPanel(
+plotOutput("distPlot"),
+width =12,
+absolutePanel(id ="controls",
+class ="panel panel-default",
+top =175, left =75, width =300, fixed=TRUE,
+draggable =TRUE, height ="auto",
+sliderInput("date",
+"Date:",
+min =as.Date("1998-01-01"),
+max =as.Date("2020-01-01"),
+value =c(as.Date("1998-01-01"), as.Date("2020-01-01")))
+
+ )
+ ),
+
+ tags$hr(),
+
+sidebarLayout(
+sidebarPanel(
+selectInput("x_variable", "X Variable", cols, selected ="SampleDate"),
+selectInput("y_variable", "Y Variable", cols, selected ="Count"),
+selectInput("color_variable", "Color", cols, selected ="CommonName")
+ ),
+
+# Show a plot with configurable axes
+mainPanel(
+plotOutput("varPlot")
+ )
+ ),
+ tags$hr()
+ )
+ )
+ )
+)
+
+# Define server logic required to draw the two plots
+server <-function(input, output) {
+
+
+ output$map <-renderLeaflet({leaflet(sites) %>%
+addTiles() %>%
+addCircleMarkers(data = sites,
+lat =~Latitude,
+lng =~Longitude,
+radius =10, # arbitrary scaling
+fillColor ="gray",
+fillOpacity =1,
+weight =0.25,
+color ="black",
+label =~StationCode)
+ })
+
+# turbidity plot
+ output$distPlot <-renderPlot({
+
+ggplot(delta_data, mapping =aes(SampleDate, Secchi)) +
+geom_point(colour="red", size=4) +
+xlim(c(input$date[1],input$date[2])) +
+labs(x ="Sample Date", y ="Secchi Depth (m)") +
+theme_light()
+ })
+
+# mix and match plot
+ output$varPlot <-renderPlot({
+ggplot(delta_data, mapping =aes(x = .data[[input$x_variable]],
+y = .data[[input$y_variable]],
+color = .data[[input$color_variable]])) +
+labs(x =to_any_case(input$x_variable, case ="title"),
+y =to_any_case(input$y_variable, case ="title"),
+color =to_any_case(input$color_variable, case ="title")) +
+geom_point(size=4) +
+theme_light()
+ })
+}
+
+
+# Run the application
+shinyApp(ui = ui, server = server)
+
+
+
+
\ No newline at end of file
diff --git a/public/session_17.html b/public/session_17.html
new file mode 100644
index 00000000..614054e9
--- /dev/null
+++ b/public/session_17.html
@@ -0,0 +1,622 @@
+
+
+
+
+
+
+
+
+
+NCEAS Open Science Synthesis for the Delta Science Program - 17 Appendix
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
17Appendix
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Configuring Two-factor Authentication on GitHub
+
+
Learning Objectives
+
+
Successfully setup two-factor authentication on GitHub
+
Recognize two-factor authentication jargon
+
+
+
+
17.1 Why Set up Two-factor Authentication (2FA)
+
+
Prevents unauthorized access
+
Strengthens your web security, especially if you have a compromised password
+
It is an increasing requirement for most websites and online applications or services
+
+
In March 2023, GitHub announced that it will require 2FA for “all developers who contribute code on GitHub.com” (GitHub Blog). This rollout will be completed by the end of 2023.
+
All users have the flexibility to use their preferred 2FA method, including: TOTP, SMS, security keys, or GitHub Mobile app. GitHub strongly recommends using security keys and TOTPs. While SMS-based 2FA is available to use, it does not provide the same level of protection, and is no longer recommended under NIST (National Institute of Standards and Technology) 800-63B.
+
+
17.1.1 Additional information about 2FA on GitHub:
Navigate to your account Settings (click your profile photo in the top right-hand corner)
+
In the “Access” section, click “Password and Authenticate”
+
In the “Two-factor authentication” section, click Enable two-factor authentication
+
Under “Setup authenticator app”, either:
+
+
Scan the QR code with your TOTP app. After scanning, the app displays a six-digit code that you can enter on GitHub
+
If you can’t scan the QR code, click “enter this text code” to see a code that you can manually enter in your TOTP app instead
+
+
On GitHub, type the code into the field under “Verify the code from the app”
+
Under “Save your recovery codes”, click “Download” to download your recovery codes. Save them to a secure location because your recovery codes can help you get back into your account if you lose access.
+
+
After saving your two-factor recovery codes, click “I have saved my recovery codes” to enable two-factor authentication for your account
+
+
Configure additional 2FA methods, if desired
+
+
+
+
17.3 Glossary
+
+
+
+
+
+
+
+
Term
+
Definition
+
+
+
+
+
Quick Response (QR) Code
+
A type of two-dimensional matrix barcode that contains specific information
+
+
+
Recovery Code
+
A unique code(s) used to reset passwords or regain access to accounts
+
+
+
Short Message Service (SMS)
+
A text messaging service that allows mobile devices to exchange short text messages
+
+
+
Time-based one-time password (TOTP)
+
A string of unique codes that changes based on time. Often, these appear as six-digit numbers that regenerate every 30 seconds
+
+
+
Two-factor Authentication (2FA)
+
An identity and access management security method that requires two forms of identification to access accounts, resources, or data
").addClass(e),P("td",n).addClass(e).html(t)[0].colSpan=T(o),l.push(n[0]))}var l=[];i(e,n),t._details&&t._details.detach(),t._details=P(l),t._detailsShow&&t._details.insertAfter(t.nTr)}function xe(t,e){var n=t.context;if(n.length&&t.length){var a=n[0].aoData[t[0]];if(a._details){(a._detailsShow=e)?(a._details.insertAfter(a.nTr),P(a.nTr).addClass("dt-hasChild")):(a._details.detach(),P(a.nTr).removeClass("dt-hasChild")),R(n[0],null,"childRow",[e,t.row(t[0])]);var s=n[0],r=new B(s),a=".dt.DT_details",e="draw"+a,t="column-sizing"+a,a="destroy"+a,u=s.aoData;if(r.off(e+" "+t+" "+a),H(u,"_details").length>0){r.on(e,function(t,e){if(s!==e)return;r.rows({page:"current"}).eq(0).each(function(t){var e=u[t];if(e._detailsShow)e._details.insertAfter(e.nTr)})});r.on(t,function(t,e,n,a){if(s!==e)return;var r,o=T(e);for(var i=0,l=u.length;it?new B(e[t],this[t]):null},filter:function(t){var e=[];if(o.filter)e=o.filter.call(this,t,this);else for(var n=0,a=this.length;n").appendTo(t);p(u,n)}else{switch(g=null,b=n,a=c.iTabIndex,n){case"ellipsis":t.append('…');break;case"first":g=S.sFirst,0===d&&(a=-1,b+=" "+o);break;case"previous":g=S.sPrevious,0===d&&(a=-1,b+=" "+o);break;case"next":g=S.sNext,0!==h&&d!==h-1||(a=-1,b+=" "+o);break;case"last":g=S.sLast,0!==h&&d!==h-1||(a=-1,b+=" "+o);break;default:g=c.fnFormatNumber(n+1),b=d===n?m.sPageButtonActive:""}null!==g&&(u=c.oInit.pagingTag||"a",r=-1!==b.indexOf(o),me(P("<"+u+">",{class:m.sPageButton+" "+b,"aria-controls":c.sTableId,"aria-disabled":r?"true":null,"aria-label":v[n],"aria-role":"link","aria-current":b===m.sPageButtonActive?"page":null,"data-dt-idx":n,tabindex:a,id:0===f&&"string"==typeof n?c.sTableId+"_"+n:null}).html(g).appendTo(t),{action:n},i))}}var g,b,n,m=c.oClasses,S=c.oLanguage.oPaginate,v=c.oLanguage.oAria.paginate||{};try{n=P(t).find(y.activeElement).data("dt-idx")}catch(t){}p(P(t).empty(),e),n!==N&&P(t).find("[data-dt-idx="+n+"]").trigger("focus")}}}),P.extend(w.ext.type.detect,[function(t,e){e=e.oLanguage.sDecimal;return l(t,e)?"num"+e:null},function(t,e){var n;return(!t||t instanceof Date||X.test(t))&&(null!==(n=Date.parse(t))&&!isNaN(n)||h(t))?"date":null},function(t,e){e=e.oLanguage.sDecimal;return l(t,e,!0)?"num-fmt"+e:null},function(t,e){e=e.oLanguage.sDecimal;return a(t,e)?"html-num"+e:null},function(t,e){e=e.oLanguage.sDecimal;return a(t,e,!0)?"html-num-fmt"+e:null},function(t,e){return h(t)||"string"==typeof t&&-1!==t.indexOf("<")?"html":null}]),P.extend(w.ext.type.search,{html:function(t){return h(t)?t:"string"==typeof t?t.replace(U," ").replace(V,""):""},string:function(t){return!h(t)&&"string"==typeof t?t.replace(U," "):t}});function ke(t,e,n,a){var r;return 0===t||t&&"-"!==t?"number"==(r=typeof t)||"bigint"==r?t:+(t=(t=e?G(t,e):t).replace&&(n&&(t=t.replace(n,"")),a)?t.replace(a,""):t):-1/0}function Me(n){P.each({num:function(t){return ke(t,n)},"num-fmt":function(t){return ke(t,n,q)},"html-num":function(t){return ke(t,n,V)},"html-num-fmt":function(t){return ke(t,n,V,q)}},function(t,e){p.type.order[t+n+"-pre"]=e,t.match(/^html\-/)&&(p.type.search[t+n]=p.type.search.html)})}P.extend(p.type.order,{"date-pre":function(t){t=Date.parse(t);return isNaN(t)?-1/0:t},"html-pre":function(t){return h(t)?"":t.replace?t.replace(/<.*?>/g,"").toLowerCase():t+""},"string-pre":function(t){return h(t)?"":"string"==typeof t?t.toLowerCase():t.toString?t.toString():""},"string-asc":function(t,e){return t").addClass(l.sSortJUIWrapper).append(o.contents()).append(P("").addClass(l.sSortIcon+" "+i.sSortingClassJUI)).appendTo(o),P(r.nTable).on("order.dt.DT",function(t,e,n,a){r===e&&(e=i.idx,o.removeClass(l.sSortAsc+" "+l.sSortDesc).addClass("asc"==a[e]?l.sSortAsc:"desc"==a[e]?l.sSortDesc:i.sSortingClass),o.find("span."+l.sSortIcon).removeClass(l.sSortJUIAsc+" "+l.sSortJUIDesc+" "+l.sSortJUI+" "+l.sSortJUIAscAllowed+" "+l.sSortJUIDescAllowed).addClass("asc"==a[e]?l.sSortJUIAsc:"desc"==a[e]?l.sSortJUIDesc:i.sSortingClassJUI))})}}});function We(t){return"string"==typeof(t=Array.isArray(t)?t.join(","):t)?t.replace(/&/g,"&").replace(//g,">").replace(/"/g,"""):t}function Ee(t,e,n,a,r){return j.moment?t[e](r):j.luxon?t[n](r):a?t[a](r):t}var Be=!1;function Ue(t,e,n){var a;if(j.moment){if(!(a=j.moment.utc(t,e,n,!0)).isValid())return null}else if(j.luxon){if(!(a=e&&"string"==typeof t?j.luxon.DateTime.fromFormat(t,e):j.luxon.DateTime.fromISO(t)).isValid)return null;a.setLocale(n)}else e?(Be||alert("DataTables warning: Formatted date without Moment.js or Luxon - https://datatables.net/tn/17"),Be=!0):a=new Date(t);return a}function Ve(s){return function(a,r,o,i){0===arguments.length?(o="en",a=r=null):1===arguments.length?(o="en",r=a,a=null):2===arguments.length&&(o=r,r=a,a=null);var l="datetime-"+r;return w.ext.type.order[l]||(w.ext.type.detect.unshift(function(t){return t===l&&l}),w.ext.type.order[l+"-asc"]=function(t,e){t=t.valueOf(),e=e.valueOf();return t===e?0:t").addClass(errClass);
+ errorSpan.text(err.message);
+ $el.after(errorSpan);
+ }
+ } else if (display === "block") {
+ // If block, add an error just after the el, set visibility:none on the
+ // el, and position the error to be on top of the el.
+ // Mark it with a unique ID and CSS class so we can remove it later.
+ $el.css("visibility", "hidden");
+ if (err.message !== "") {
+ var errorDiv = $("
").addClass(errClass).css("position", "absolute")
+ .css("top", el.offsetTop)
+ .css("left", el.offsetLeft)
+ // setting width can push out the page size, forcing otherwise
+ // unnecessary scrollbars to appear and making it impossible for
+ // the element to shrink; so use max-width instead
+ .css("maxWidth", el.offsetWidth)
+ .css("height", el.offsetHeight);
+ errorDiv.text(err.message);
+ $el.after(errorDiv);
+
+ // Really dumb way to keep the size/position of the error in sync with
+ // the parent element as the window is resized or whatever.
+ var intId = setInterval(function() {
+ if (!errorDiv[0].parentElement) {
+ clearInterval(intId);
+ return;
+ }
+ errorDiv
+ .css("top", el.offsetTop)
+ .css("left", el.offsetLeft)
+ .css("maxWidth", el.offsetWidth)
+ .css("height", el.offsetHeight);
+ }, 500);
+ }
+ }
+ },
+ clearError: function(el) {
+ var $el = $(el);
+ var display = $el.data("restore-display-mode");
+ $el.data("restore-display-mode", null);
+
+ if (display === "inline" || display === "inline-block") {
+ if (display)
+ $el.css("display", display);
+ $(el.nextSibling).filter(".htmlwidgets-error").remove();
+ } else if (display === "block"){
+ $el.css("visibility", "inherit");
+ $(el.nextSibling).filter(".htmlwidgets-error").remove();
+ }
+ },
+ sizing: {}
+ };
+
+ // Called by widget bindings to register a new type of widget. The definition
+ // object can contain the following properties:
+ // - name (required) - A string indicating the binding name, which will be
+ // used by default as the CSS classname to look for.
+ // - initialize (optional) - A function(el) that will be called once per
+ // widget element; if a value is returned, it will be passed as the third
+ // value to renderValue.
+ // - renderValue (required) - A function(el, data, initValue) that will be
+ // called with data. Static contexts will cause this to be called once per
+ // element; Shiny apps will cause this to be called multiple times per
+ // element, as the data changes.
+ window.HTMLWidgets.widget = function(definition) {
+ if (!definition.name) {
+ throw new Error("Widget must have a name");
+ }
+ if (!definition.type) {
+ throw new Error("Widget must have a type");
+ }
+ // Currently we only support output widgets
+ if (definition.type !== "output") {
+ throw new Error("Unrecognized widget type '" + definition.type + "'");
+ }
+ // TODO: Verify that .name is a valid CSS classname
+
+ // Support new-style instance-bound definitions. Old-style class-bound
+ // definitions have one widget "object" per widget per type/class of
+ // widget; the renderValue and resize methods on such widget objects
+ // take el and instance arguments, because the widget object can't
+ // store them. New-style instance-bound definitions have one widget
+ // object per widget instance; the definition that's passed in doesn't
+ // provide renderValue or resize methods at all, just the single method
+ // factory(el, width, height)
+ // which returns an object that has renderValue(x) and resize(w, h).
+ // This enables a far more natural programming style for the widget
+ // author, who can store per-instance state using either OO-style
+ // instance fields or functional-style closure variables (I guess this
+ // is in contrast to what can only be called C-style pseudo-OO which is
+ // what we required before).
+ if (definition.factory) {
+ definition = createLegacyDefinitionAdapter(definition);
+ }
+
+ if (!definition.renderValue) {
+ throw new Error("Widget must have a renderValue function");
+ }
+
+ // For static rendering (non-Shiny), use a simple widget registration
+ // scheme. We also use this scheme for Shiny apps/documents that also
+ // contain static widgets.
+ window.HTMLWidgets.widgets = window.HTMLWidgets.widgets || [];
+ // Merge defaults into the definition; don't mutate the original definition.
+ var staticBinding = extend({}, defaults, definition);
+ overrideMethod(staticBinding, "find", function(superfunc) {
+ return function(scope) {
+ var results = superfunc(scope);
+ // Filter out Shiny outputs, we only want the static kind
+ return filterByClass(results, "html-widget-output", false);
+ };
+ });
+ window.HTMLWidgets.widgets.push(staticBinding);
+
+ if (shinyMode) {
+ // Shiny is running. Register the definition with an output binding.
+ // The definition itself will not be the output binding, instead
+ // we will make an output binding object that delegates to the
+ // definition. This is because we foolishly used the same method
+ // name (renderValue) for htmlwidgets definition and Shiny bindings
+ // but they actually have quite different semantics (the Shiny
+ // bindings receive data that includes lots of metadata that it
+ // strips off before calling htmlwidgets renderValue). We can't
+ // just ignore the difference because in some widgets it's helpful
+ // to call this.renderValue() from inside of resize(), and if
+ // we're not delegating, then that call will go to the Shiny
+ // version instead of the htmlwidgets version.
+
+ // Merge defaults with definition, without mutating either.
+ var bindingDef = extend({}, defaults, definition);
+
+ // This object will be our actual Shiny binding.
+ var shinyBinding = new Shiny.OutputBinding();
+
+ // With a few exceptions, we'll want to simply use the bindingDef's
+ // version of methods if they are available, otherwise fall back to
+ // Shiny's defaults. NOTE: If Shiny's output bindings gain additional
+ // methods in the future, and we want them to be overrideable by
+ // HTMLWidget binding definitions, then we'll need to add them to this
+ // list.
+ delegateMethod(shinyBinding, bindingDef, "getId");
+ delegateMethod(shinyBinding, bindingDef, "onValueChange");
+ delegateMethod(shinyBinding, bindingDef, "onValueError");
+ delegateMethod(shinyBinding, bindingDef, "renderError");
+ delegateMethod(shinyBinding, bindingDef, "clearError");
+ delegateMethod(shinyBinding, bindingDef, "showProgress");
+
+ // The find, renderValue, and resize are handled differently, because we
+ // want to actually decorate the behavior of the bindingDef methods.
+
+ shinyBinding.find = function(scope) {
+ var results = bindingDef.find(scope);
+
+ // Only return elements that are Shiny outputs, not static ones
+ var dynamicResults = results.filter(".html-widget-output");
+
+ // It's possible that whatever caused Shiny to think there might be
+ // new dynamic outputs, also caused there to be new static outputs.
+ // Since there might be lots of different htmlwidgets bindings, we
+ // schedule execution for later--no need to staticRender multiple
+ // times.
+ if (results.length !== dynamicResults.length)
+ scheduleStaticRender();
+
+ return dynamicResults;
+ };
+
+ // Wrap renderValue to handle initialization, which unfortunately isn't
+ // supported natively by Shiny at the time of this writing.
+
+ shinyBinding.renderValue = function(el, data) {
+ Shiny.renderDependencies(data.deps);
+ // Resolve strings marked as javascript literals to objects
+ if (!(data.evals instanceof Array)) data.evals = [data.evals];
+ for (var i = 0; data.evals && i < data.evals.length; i++) {
+ window.HTMLWidgets.evaluateStringMember(data.x, data.evals[i]);
+ }
+ if (!bindingDef.renderOnNullValue) {
+ if (data.x === null) {
+ el.style.visibility = "hidden";
+ return;
+ } else {
+ el.style.visibility = "inherit";
+ }
+ }
+ if (!elementData(el, "initialized")) {
+ initSizing(el);
+
+ elementData(el, "initialized", true);
+ if (bindingDef.initialize) {
+ var rect = el.getBoundingClientRect();
+ var result = bindingDef.initialize(el, rect.width, rect.height);
+ elementData(el, "init_result", result);
+ }
+ }
+ bindingDef.renderValue(el, data.x, elementData(el, "init_result"));
+ evalAndRun(data.jsHooks.render, elementData(el, "init_result"), [el, data.x]);
+ };
+
+ // Only override resize if bindingDef implements it
+ if (bindingDef.resize) {
+ shinyBinding.resize = function(el, width, height) {
+ // Shiny can call resize before initialize/renderValue have been
+ // called, which doesn't make sense for widgets.
+ if (elementData(el, "initialized")) {
+ bindingDef.resize(el, width, height, elementData(el, "init_result"));
+ }
+ };
+ }
+
+ Shiny.outputBindings.register(shinyBinding, bindingDef.name);
+ }
+ };
+
+ var scheduleStaticRenderTimerId = null;
+ function scheduleStaticRender() {
+ if (!scheduleStaticRenderTimerId) {
+ scheduleStaticRenderTimerId = setTimeout(function() {
+ scheduleStaticRenderTimerId = null;
+ window.HTMLWidgets.staticRender();
+ }, 1);
+ }
+ }
+
+ // Render static widgets after the document finishes loading
+ // Statically render all elements that are of this widget's class
+ window.HTMLWidgets.staticRender = function() {
+ var bindings = window.HTMLWidgets.widgets || [];
+ forEach(bindings, function(binding) {
+ var matches = binding.find(document.documentElement);
+ forEach(matches, function(el) {
+ var sizeObj = initSizing(el, binding);
+
+ var getSize = function(el) {
+ if (sizeObj) {
+ return {w: sizeObj.getWidth(), h: sizeObj.getHeight()}
+ } else {
+ var rect = el.getBoundingClientRect();
+ return {w: rect.width, h: rect.height}
+ }
+ };
+
+ if (hasClass(el, "html-widget-static-bound"))
+ return;
+ el.className = el.className + " html-widget-static-bound";
+
+ var initResult;
+ if (binding.initialize) {
+ var size = getSize(el);
+ initResult = binding.initialize(el, size.w, size.h);
+ elementData(el, "init_result", initResult);
+ }
+
+ if (binding.resize) {
+ var lastSize = getSize(el);
+ var resizeHandler = function(e) {
+ var size = getSize(el);
+ if (size.w === 0 && size.h === 0)
+ return;
+ if (size.w === lastSize.w && size.h === lastSize.h)
+ return;
+ lastSize = size;
+ binding.resize(el, size.w, size.h, initResult);
+ };
+
+ on(window, "resize", resizeHandler);
+
+ // This is needed for cases where we're running in a Shiny
+ // app, but the widget itself is not a Shiny output, but
+ // rather a simple static widget. One example of this is
+ // an rmarkdown document that has runtime:shiny and widget
+ // that isn't in a render function. Shiny only knows to
+ // call resize handlers for Shiny outputs, not for static
+ // widgets, so we do it ourselves.
+ if (window.jQuery) {
+ window.jQuery(document).on(
+ "shown.htmlwidgets shown.bs.tab.htmlwidgets shown.bs.collapse.htmlwidgets",
+ resizeHandler
+ );
+ window.jQuery(document).on(
+ "hidden.htmlwidgets hidden.bs.tab.htmlwidgets hidden.bs.collapse.htmlwidgets",
+ resizeHandler
+ );
+ }
+
+ // This is needed for the specific case of ioslides, which
+ // flips slides between display:none and display:block.
+ // Ideally we would not have to have ioslide-specific code
+ // here, but rather have ioslides raise a generic event,
+ // but the rmarkdown package just went to CRAN so the
+ // window to getting that fixed may be long.
+ if (window.addEventListener) {
+ // It's OK to limit this to window.addEventListener
+ // browsers because ioslides itself only supports
+ // such browsers.
+ on(document, "slideenter", resizeHandler);
+ on(document, "slideleave", resizeHandler);
+ }
+ }
+
+ var scriptData = document.querySelector("script[data-for='" + el.id + "'][type='application/json']");
+ if (scriptData) {
+ var data = JSON.parse(scriptData.textContent || scriptData.text);
+ // Resolve strings marked as javascript literals to objects
+ if (!(data.evals instanceof Array)) data.evals = [data.evals];
+ for (var k = 0; data.evals && k < data.evals.length; k++) {
+ window.HTMLWidgets.evaluateStringMember(data.x, data.evals[k]);
+ }
+ binding.renderValue(el, data.x, initResult);
+ evalAndRun(data.jsHooks.render, initResult, [el, data.x]);
+ }
+ });
+ });
+
+ invokePostRenderHandlers();
+ }
+
+
+ function has_jQuery3() {
+ if (!window.jQuery) {
+ return false;
+ }
+ var $version = window.jQuery.fn.jquery;
+ var $major_version = parseInt($version.split(".")[0]);
+ return $major_version >= 3;
+ }
+
+ /*
+ / Shiny 1.4 bumped jQuery from 1.x to 3.x which means jQuery's
+ / on-ready handler (i.e., $(fn)) is now asyncronous (i.e., it now
+ / really means $(setTimeout(fn)).
+ / https://jquery.com/upgrade-guide/3.0/#breaking-change-document-ready-handlers-are-now-asynchronous
+ /
+ / Since Shiny uses $() to schedule initShiny, shiny>=1.4 calls initShiny
+ / one tick later than it did before, which means staticRender() is
+ / called renderValue() earlier than (advanced) widget authors might be expecting.
+ / https://github.com/rstudio/shiny/issues/2630
+ /
+ / For a concrete example, leaflet has some methods (e.g., updateBounds)
+ / which reference Shiny methods registered in initShiny (e.g., setInputValue).
+ / Since leaflet is privy to this life-cycle, it knows to use setTimeout() to
+ / delay execution of those methods (until Shiny methods are ready)
+ / https://github.com/rstudio/leaflet/blob/18ec981/javascript/src/index.js#L266-L268
+ /
+ / Ideally widget authors wouldn't need to use this setTimeout() hack that
+ / leaflet uses to call Shiny methods on a staticRender(). In the long run,
+ / the logic initShiny should be broken up so that method registration happens
+ / right away, but binding happens later.
+ */
+ function maybeStaticRenderLater() {
+ if (shinyMode && has_jQuery3()) {
+ window.jQuery(window.HTMLWidgets.staticRender);
+ } else {
+ window.HTMLWidgets.staticRender();
+ }
+ }
+
+ if (document.addEventListener) {
+ document.addEventListener("DOMContentLoaded", function() {
+ document.removeEventListener("DOMContentLoaded", arguments.callee, false);
+ maybeStaticRenderLater();
+ }, false);
+ } else if (document.attachEvent) {
+ document.attachEvent("onreadystatechange", function() {
+ if (document.readyState === "complete") {
+ document.detachEvent("onreadystatechange", arguments.callee);
+ maybeStaticRenderLater();
+ }
+ });
+ }
+
+
+ window.HTMLWidgets.getAttachmentUrl = function(depname, key) {
+ // If no key, default to the first item
+ if (typeof(key) === "undefined")
+ key = 1;
+
+ var link = document.getElementById(depname + "-" + key + "-attachment");
+ if (!link) {
+ throw new Error("Attachment " + depname + "/" + key + " not found in document");
+ }
+ return link.getAttribute("href");
+ };
+
+ window.HTMLWidgets.dataframeToD3 = function(df) {
+ var names = [];
+ var length;
+ for (var name in df) {
+ if (df.hasOwnProperty(name))
+ names.push(name);
+ if (typeof(df[name]) !== "object" || typeof(df[name].length) === "undefined") {
+ throw new Error("All fields must be arrays");
+ } else if (typeof(length) !== "undefined" && length !== df[name].length) {
+ throw new Error("All fields must be arrays of the same length");
+ }
+ length = df[name].length;
+ }
+ var results = [];
+ var item;
+ for (var row = 0; row < length; row++) {
+ item = {};
+ for (var col = 0; col < names.length; col++) {
+ item[names[col]] = df[names[col]][row];
+ }
+ results.push(item);
+ }
+ return results;
+ };
+
+ window.HTMLWidgets.transposeArray2D = function(array) {
+ if (array.length === 0) return array;
+ var newArray = array[0].map(function(col, i) {
+ return array.map(function(row) {
+ return row[i]
+ })
+ });
+ return newArray;
+ };
+ // Split value at splitChar, but allow splitChar to be escaped
+ // using escapeChar. Any other characters escaped by escapeChar
+ // will be included as usual (including escapeChar itself).
+ function splitWithEscape(value, splitChar, escapeChar) {
+ var results = [];
+ var escapeMode = false;
+ var currentResult = "";
+ for (var pos = 0; pos < value.length; pos++) {
+ if (!escapeMode) {
+ if (value[pos] === splitChar) {
+ results.push(currentResult);
+ currentResult = "";
+ } else if (value[pos] === escapeChar) {
+ escapeMode = true;
+ } else {
+ currentResult += value[pos];
+ }
+ } else {
+ currentResult += value[pos];
+ escapeMode = false;
+ }
+ }
+ if (currentResult !== "") {
+ results.push(currentResult);
+ }
+ return results;
+ }
+ // Function authored by Yihui/JJ Allaire
+ window.HTMLWidgets.evaluateStringMember = function(o, member) {
+ var parts = splitWithEscape(member, '.', '\\');
+ for (var i = 0, l = parts.length; i < l; i++) {
+ var part = parts[i];
+ // part may be a character or 'numeric' member name
+ if (o !== null && typeof o === "object" && part in o) {
+ if (i == (l - 1)) { // if we are at the end of the line then evalulate
+ if (typeof o[part] === "string")
+ o[part] = tryEval(o[part]);
+ } else { // otherwise continue to next embedded object
+ o = o[part];
+ }
+ }
+ }
+ };
+
+ // Retrieve the HTMLWidget instance (i.e. the return value of an
+ // HTMLWidget binding's initialize() or factory() function)
+ // associated with an element, or null if none.
+ window.HTMLWidgets.getInstance = function(el) {
+ return elementData(el, "init_result");
+ };
+
+ // Finds the first element in the scope that matches the selector,
+ // and returns the HTMLWidget instance (i.e. the return value of
+ // an HTMLWidget binding's initialize() or factory() function)
+ // associated with that element, if any. If no element matches the
+ // selector, or the first matching element has no HTMLWidget
+ // instance associated with it, then null is returned.
+ //
+ // The scope argument is optional, and defaults to window.document.
+ window.HTMLWidgets.find = function(scope, selector) {
+ if (arguments.length == 1) {
+ selector = scope;
+ scope = document;
+ }
+
+ var el = scope.querySelector(selector);
+ if (el === null) {
+ return null;
+ } else {
+ return window.HTMLWidgets.getInstance(el);
+ }
+ };
+
+ // Finds all elements in the scope that match the selector, and
+ // returns the HTMLWidget instances (i.e. the return values of
+ // an HTMLWidget binding's initialize() or factory() function)
+ // associated with the elements, in an array. If elements that
+ // match the selector don't have an associated HTMLWidget
+ // instance, the returned array will contain nulls.
+ //
+ // The scope argument is optional, and defaults to window.document.
+ window.HTMLWidgets.findAll = function(scope, selector) {
+ if (arguments.length == 1) {
+ selector = scope;
+ scope = document;
+ }
+
+ var nodes = scope.querySelectorAll(selector);
+ var results = [];
+ for (var i = 0; i < nodes.length; i++) {
+ results.push(window.HTMLWidgets.getInstance(nodes[i]));
+ }
+ return results;
+ };
+
+ var postRenderHandlers = [];
+ function invokePostRenderHandlers() {
+ while (postRenderHandlers.length) {
+ var handler = postRenderHandlers.shift();
+ if (handler) {
+ handler();
+ }
+ }
+ }
+
+ // Register the given callback function to be invoked after the
+ // next time static widgets are rendered.
+ window.HTMLWidgets.addPostRenderHandler = function(callback) {
+ postRenderHandlers.push(callback);
+ };
+
+ // Takes a new-style instance-bound definition, and returns an
+ // old-style class-bound definition. This saves us from having
+ // to rewrite all the logic in this file to accomodate both
+ // types of definitions.
+ function createLegacyDefinitionAdapter(defn) {
+ var result = {
+ name: defn.name,
+ type: defn.type,
+ initialize: function(el, width, height) {
+ return defn.factory(el, width, height);
+ },
+ renderValue: function(el, x, instance) {
+ return instance.renderValue(x);
+ },
+ resize: function(el, width, height, instance) {
+ return instance.resize(width, height);
+ }
+ };
+
+ if (defn.find)
+ result.find = defn.find;
+ if (defn.renderError)
+ result.renderError = defn.renderError;
+ if (defn.clearError)
+ result.clearError = defn.clearError;
+
+ return result;
+ }
+})();
diff --git a/public/site_libs/jquery-3.6.0/jquery-3.6.0.js b/public/site_libs/jquery-3.6.0/jquery-3.6.0.js
new file mode 100644
index 00000000..fc6c299b
--- /dev/null
+++ b/public/site_libs/jquery-3.6.0/jquery-3.6.0.js
@@ -0,0 +1,10881 @@
+/*!
+ * jQuery JavaScript Library v3.6.0
+ * https://jquery.com/
+ *
+ * Includes Sizzle.js
+ * https://sizzlejs.com/
+ *
+ * Copyright OpenJS Foundation and other contributors
+ * Released under the MIT license
+ * https://jquery.org/license
+ *
+ * Date: 2021-03-02T17:08Z
+ */
+( function( global, factory ) {
+
+ "use strict";
+
+ if ( typeof module === "object" && typeof module.exports === "object" ) {
+
+ // For CommonJS and CommonJS-like environments where a proper `window`
+ // is present, execute the factory and get jQuery.
+ // For environments that do not have a `window` with a `document`
+ // (such as Node.js), expose a factory as module.exports.
+ // This accentuates the need for the creation of a real `window`.
+ // e.g. var jQuery = require("jquery")(window);
+ // See ticket #14549 for more info.
+ module.exports = global.document ?
+ factory( global, true ) :
+ function( w ) {
+ if ( !w.document ) {
+ throw new Error( "jQuery requires a window with a document" );
+ }
+ return factory( w );
+ };
+ } else {
+ factory( global );
+ }
+
+// Pass this if window is not defined yet
+} )( typeof window !== "undefined" ? window : this, function( window, noGlobal ) {
+
+// Edge <= 12 - 13+, Firefox <=18 - 45+, IE 10 - 11, Safari 5.1 - 9+, iOS 6 - 9.1
+// throw exceptions when non-strict code (e.g., ASP.NET 4.5) accesses strict mode
+// arguments.callee.caller (trac-13335). But as of jQuery 3.0 (2016), strict mode should be common
+// enough that all such attempts are guarded in a try block.
+"use strict";
+
+var arr = [];
+
+var getProto = Object.getPrototypeOf;
+
+var slice = arr.slice;
+
+var flat = arr.flat ? function( array ) {
+ return arr.flat.call( array );
+} : function( array ) {
+ return arr.concat.apply( [], array );
+};
+
+
+var push = arr.push;
+
+var indexOf = arr.indexOf;
+
+var class2type = {};
+
+var toString = class2type.toString;
+
+var hasOwn = class2type.hasOwnProperty;
+
+var fnToString = hasOwn.toString;
+
+var ObjectFunctionString = fnToString.call( Object );
+
+var support = {};
+
+var isFunction = function isFunction( obj ) {
+
+ // Support: Chrome <=57, Firefox <=52
+ // In some browsers, typeof returns "function" for HTML
+
