-
Notifications
You must be signed in to change notification settings - Fork 0
/
lipd2neotomaDemo.Rmd
159 lines (103 loc) · 3.13 KB
/
lipd2neotomaDemo.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
---
title: "lipd2neotoma Demo"
author: "Dave Edge"
date: "2022-12-05"
output: html_document
---
```{r setup, include=FALSE}
library(lipdR)
knitr::opts_chunk$set(echo = TRUE)
```
## This is a demonstration of the new `lipd2neotoma()` function
### I will use a neotoma dataset, called Bambili 2, for this demonstration
First, we will load this record and convert into lipd format
```{r}
B <- neotoma2::get_sites(sitename = "Bambili 2")
D <- neotoma2::get_downloads(B)
L <- neotoma2lipd(D)
```
### LiPD
Let's see a summary of the record in LiPD
```{r warning=FALSE}
summary(L)
```
### Neotoma
Now we will convert back to neotoma and observe the changes
```{r}
N <- lipd2neotoma(L)
D@sites[[1]]
N
```
The site printout looks good
Site level metadata
```{r, error=TRUE}
D
D@sites
D@sites[[1]]
N
D@sites[[1]]@siteid
N@siteid
D@sites[[1]]@sitename
N@sitename
D@sites[[1]]$geography
N@geography
D@sites[[1]]$altitude
N@altitude
D@sites[[1]]$geopolitical
N@geopolitical
D@sites[[1]]$area
N@area
D@sites[[1]]$notes
N@notes
D@sites[[1]]$description
N@description
D@sites[[1]]$collunits
N@collunits
```
We do pretty good here with the exception of "geopolitical", which could be added to the lipd under "geo"
We also see an error in trying to print the "collunit", which is detailed later
### Sample datum
```{r}
D@sites[[1]]@collunits@collunits[[1]]@datasets@datasets[[1]]@samples@samples[[1]]@datum
N@collunits@collunits[[1]]@datasets@datasets[[1]]@samples@samples[[1]]@datum
```
note that `D` is the original neotoma dataset and `N` is the new one
`N` is a `site` rather than a `sites`
Aside from some loss in the `variablename`, these data frames look identical.
Improved `variablename` fidelity is possible with alteration to the `neotoma2lipd()` function
What's the difference between element and elementtype?
Let's jump to the last `datum` to see if this fidelity holds
```{r}
length(D@sites[[1]]@collunits@collunits[[1]]@datasets@datasets[[1]]@samples@samples)
D@sites[[1]]@collunits@collunits[[1]]@datasets@datasets[[1]]@samples@samples[[140]]@datum
N$collunits@collunits[[1]]@datasets@datasets[[1]]@samples@samples[[140]]@datum
```
again, we see some minor changes to `variablename`, but otherwise the data frame is identical
### Chronologies
Let's have a look at the chronology data
```{r}
D@sites[[1]]@collunits@collunits[[1]]@chronologies@chronologies[[1]]@chroncontrols
N$collunits@collunits[[1]]@chronologies@chronologies[[1]]@chroncontrols
```
I could not identify the sorting of the original chronology table to follow
The tables are otherwise identical
### Outstanding Issues
Collection unit print doesn't work
```{r error=TRUE}
D@sites[[1]]@collunits@collunits[[1]]
N$collunits@collunits[[1]]
new("site")
new("collunits")
new("collunit")
```
creating a new "collunit" is an issue?
Some of the chronology metadata isn't retained, lipd doesn't store metadata at this level
```{r error=TRUE}
D@sites[[1]]@collunits@collunits[[1]]@chronologies@chronologies[[1]]
N$collunits@collunits[[1]]@chronologies@chronologies[[1]]
```
Same for "collunit" metadata
```{r error=TRUE}
D@sites[[1]]@collunits@collunits[[1]]
N$collunits@collunits[[1]]
```