You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# The title of your DRR. Should all DRR start with "Data Release Report:"? Should we enforce titles specifically referencing the data package(s) the Report is about?
27
26
title <- "DRR Title"
@@ -308,7 +307,7 @@ The Data Records section should be used to explain each data record associated w
308
307
309
308
This DRR describes the data package *`r dataPackageTitle`* which contains a metadata file and `r length(dataPackage_fileNames)` data files. These data were compiled and processed for dissemination by the National Park Service Inventory and Monitoring Division (IMD) and are available at `r dataPackageDOI` (see Table 1).
# Generates a table of acceptance criteria for each of the data quality fields in your data package. Mitigations taken when data did not meet the acceptance criteria should be described textually in the Data Quality Evaluation section.
330
329
331
-
# Specify which columns in your data package are data quality fields in the dataQualityFields variable. In the example below, data quality fields/columns in the data package are listed in the format [FieldName]_flag. These data quality fields relate to the respective temporal, taxonomic, and geographic data.
330
+
# Specify which columns in your data package are data quality fields in the data_quality_fields variable. In the example below, data quality fields/columns in the data package are listed in the format [FieldName]_flag. These data quality fields relate to the respective temporal, taxonomic, and geographic data.
332
331
333
-
dataQualityFields <- c(
332
+
data_quality_fields <- c(
334
333
"eventDate_flag",
335
334
"scientificName_flag",
336
335
"coordinate_flag"
337
336
)
338
337
339
338
# Brief description of the acceptance criteria for each respective data quality field. The order of the acceptance criteria must match the order of the data quality fields.
340
339
341
-
dataQualityAcceptanceCriteria <- c(
340
+
data_quality_acceptance_criteria <- c(
342
341
"Sampling event date within the start and end dates of the project",
343
342
"Taxon exists within Integrated Taxonomic Information System and GBIF",
344
343
"Sampling location is within the park unit boundaries"
knitr::kable(caption = "**Table 2. Acceptance criteria for data evaluated.**", col.names=c("**Field**", "**Acceptance Criteria**"), format="pandoc", align = 'c')
352
+
knitr::kable(caption = "**Table 2. Acceptance criteria for data evaluated.**",
353
+
col.names=c("**Field**",
354
+
"**Acceptance Criteria**"),
355
+
format="pandoc",
356
+
align = 'c')
352
357
353
358
```
354
359
@@ -357,7 +362,9 @@ data_criteria %>%
357
362
# Generates a table summarizing QC at the column level within each file. All flagged columns are included. To add additional non-flagged columns, specify them with column names: cols=("my_unflagged_data1", "my_unflagged_data2)" or numbers: cols=c(1:4). All non-missing data in unflagged columns is assumed accepted. If a file has no flagged columns and no specified custom columns, all values for that data file will be listed as "NA".
358
363
359
364
#set directory to the location of your data package:
@@ -554,7 +561,7 @@ United States Geologic Survey (USGS). 2016. BioData - Aquatic Bioassessment Data
554
561
555
562
In most cases, Code listing is not required. If all QA/QC and data manipulations were performed elsewhere, you should cite that code in the methods (and leave the "Listing" code chunk as the default settings: eval=FALSE and echo=FALSE). If you have developed custom scripts, you can add those to DataStore with the reference type "Script" and cite them in the DRR. Some people have developed code to perform QA/QC or data manipulation within the DRR itself. In that case, you must set the "Listing" code chunk to eval=TRUE and echo=TRUE to fully document the QA/QC process.
@@ -564,7 +571,7 @@ In most cases, Code listing is not required. If all QA/QC and data manipulations
564
571
565
572
In most cases you do not need to report session info (leave the "session-info" code chunk parameters in their default state: eval=FALSE). Session and version information is only necessary if you have set the "Listing" code chunk to eval=TRUE in appendix A. In that case, change the "session-info" code chunk parameters to eval=TRUE.
0 commit comments