Questions

[mcgregorian1]

Questions

Here is the protocol for reference

• [x] 1. dendroID is something we have instructions for in the protocol but something we have not assigned numbers for at all. Are we wanting to add this?

• [x] 2. dbh in metadata is listed as the dbh when the dendroband is first measured/replaced, then calculated based on the growing trend of the intraannual surveys. Recent years' files only have the dbh listed as dbh 2013. Do we want this fixed?

• [x] 3. explain Dendrometer type in metadata. Is it a numeric measurement? This is found nowhere in the protocol.

• [x] 4. right now we're saying that when surveyors find a measurement that varies by more than 3mm from the last survey, they should double check the measurement and indicate "double-checked" in the notes. We chose 3mm because it seemed like a good threshold. Do we want to re-calculate this number based on standard deviations of growth data over the past several years?

• [ ] 5. do we want the dendrometer replacement/installation form merged with the master for each year or kept separate?

• depending on this solution and # 2 above, do we want the new dbh from band replacements to replace the normal dbh column? (however, we also haven't been taking a new dbh with every dendroband replacement as per the protocol. I'm assuming we want to start doing this).

• [x] 6. If replacements are done outside of a normal survey, should that measurement be given a separate survey number? For example, if 6 trees needed dendroband replacing, and they were replaced between surveys 2019.07 and 2019.08, should they get separate entries in the master with a survey.ID of 2019.071? This might make it easier to later analyze data in the master if we merge everything (see number 5 above).

• [x] 7. Do we have any protocol for excluding dead trees from survey? As in, after they have already been marked as DS or DC. We stop taking measurements anyways once they've died correct? There is no mention of this in the protocol.

[gonzalezeb]

1. dendroID. There are dendroIDs in the master table for each survey but they were not carried out in 2018, why not? Be careful as the dendroID could change from one survey to other if the band is replaced.
2. explain Dendrometer type in metadata: Dendrometer type: 1= plastic band, 2 =metal metal band

[mcgregorian1]

1. dendroID. There are dendroIDs in the master table for each survey but they were not carried out in 2018, why not? Be careful as the dendroID could change from one survey to other if the band is replaced.

I checked and we do have dendroIDs but not in the way the protocol specifies. Currently, the protocol says the first dendroband installed is given a dendroID of "1", then when it's replaced or moved, it gets the next higher number, so 2, 3, 4, etc.

The majority of numbers we have are 658 or 730, not something like 8 or 14 as we'd expect from the methodology. Should we use these numbers and then apply the new methodology to them?

Issue with dendroID fixed

[teixeirak]

Regarding 2. - Good question. This is a derived value, as opposed to a direct measurement, and I'd therefore be inclined to drop it. That said, it could facilitate future analyses, so it doesn't hurt to keep it in. Most importantly, data and metadata need to be consistent. (see issue #10)

[teixeirak]

Other questions:

4. Maybe... Reassessing that number wouldn't hurt. On the other hand we want to keep it simple and (probably) consistent with what other sites are doing. Outlying values will vary by time of year and tree size, so it would be complex if we really want a rigorous criteria for identifying potential errors. @gonzalezeb, is this a criteria from Helene protocols, or one that we made up? If its ForestGEO wide, I'd say just stick with it.

[teixeirak]

6. Makes sense.

[teixeirak]

5. Depends on how closely we want to stick to the existing data structure (see issue #10). If we're not trying to stick with that, I think it makes more sense to include a separate file called "dendro_bands" that contains all the data on date installed, height, band type, etc. I think that would be a cleaner way to handle the data, but there's greater value in matching our data to a ForestGEO standard (if we converge on that one).

[mcgregorian1]

Regarding 2. - Good question. This is a derived value, as opposed to a direct measurement, and I'd therefore be inclined to drop it. That said, it could facilitate future analyses, so it doesn't hurt to keep it in. Most importantly, data and metadata need to be consistent. (see issue #10)

Since our files from recent years only have the dbh2013 listed, I'm going to take out the part in the metadata about having it be derived based on dendroband growth until we use it in that capacity

[teixeirak]

It's critical that we be consistent between earlier and later censuses (in data and metadata).

[teixeirak]

I think this is all resolved for now.