-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Leaf spectra/trait variable names #665
Comments
What fraction of these are the names currently used in the BETY variables table? To the extent possible we should try and keep the 'standards' in the different parts of the project consistent. |
Uh, to my knowledge, none of them, because I didn't check the BETY variables table before making this. I'm going to go ahead and do that... |
Following from @mdietze's comment
|
OK, @mdietze @dlebauer @serbinsh , I put together the following table comparing what I came up with and BETY's variables. What are your thoughts? Should I align everything that I can with BETY and then try to match the rest using similar names? Or are some of these deprecated, etc. and could use an overwrite/update?
|
Hmm. Not to create meaningless work, but it would be interesting to see what the CF standard is for some of these (as well as the other standard David mentioned). In general I'm in favor of aligning with BETY and then generating similar names for missing variables, however this points out that the naming in BETY has not been consistent. Thus I think we should discuss updating BETY names as well. Unless it conflicts with CF I kinda like the variables that are leaf_[thing]. I definitely don't like the proposed C_[thing] because for a number of these variables we have the same [thing] in stem wood, roots, etc. We should definitely be consistent on separators -- the spaces will cause lots of problems in R and I like _ over -. 'DM_green leaf' seems like a particularly bad name |
I don't think it's meaningless work. I'd rather get it right the first time than have to go back later and change half the names or create unnecessary confusion. Given that all of these are going into a larger database of stuff, I totally agree that my I'll check out the links Dave posted, but where can I find the CF standard? |
So unless I'm missing something, neither the CF page nor the ICASA standards have anything useful at all about leaves: A search of the CF variables table for "leaf" returns only "Leaf area index" and "leaf carbon content", and relevant searches for key terms in the other parameters similarly turn up little if anything at all. Same is true for ICASA, which has nothing on leaves and seems to have mostly soil, atmosphere, and aggregate vegetation stuff (e.g. biomass, harvest). Unless the idea is that we try to use a similar format to theirs in creating our new variables? |
How easy is it and/or recommended to just change records and delete variables in BETY? I poked around a bit more and came up with this table (Google Doc). I've highlighted my proposed changes in yellow, and proposed additions in green. It turns out that for most of these things, there are actually relatively few records in BETY, so I could easily change them all by hand in less than an hour of work. The ones with a lot of records (e.g. LMA, leafN), I can just leave as-is. @mdietze @dlebauer @robkooper @serbinsh Thoughts? |
Easy but not always advisable. I know some of these changes will break the growth respiration code, but it's nothing a bit of grep can't fix. You'll also need to check the meta-analysis code. In addition, there's definitely a leaf C:N in there already that you missed, so don't add a new one. Finally, are the _area and _masspct endings the CF standard naming approach? If not, you'll want to use the CF standard for name generation. Assuming these small issues are sorted out I give a thumbs up. You'll want that seconded by David before you make any changes |
"I kinda like the variables that are leaf_[thing]. I definitely don't like the proposed C_[thing] because for a number of these variables we have the same [thing] in stem wood, roots, etc. " I fully agree |
@mdietze which of these will "break" the growth resp code? Doesn't seem like a lot of these are in BETY....is it the leaf chem vars, like starch, lig, cell? A minor concern of mine is fiber, lignin, and cellulose as there isn't a standard def, plus there is hemi and non hemi cellulose, etc. Plus the values will vary depending on the use of acid digestion or HPLC. Maybe we can still pool them but how to discriminate? Also depending on what your standard is for the acid digestion approach (e.g. an aspen leaf standard) you may not get the same result, and some approaches will extract more sol and insoluble fractions that others. Something to keep in mind.....so maybe the approach matters? As a separate variable? A covariate perhaps? |
also worth looking at this collection of CF and CF-style names that I On Wed, Oct 28, 2015 at 4:05 PM, Shawn P. Serbin notifications@github.com
|
Hmmm @dlebauer so in that case you were using names like CA_foliar mass_fraction_of_calcium_in_leaf |
for growth resp, yes it's those variables. you don't see them because that code hasn;t been incorporated into the mainline yet: For 'trait' data there's definitely the capacity to add methods. It's a bit more tricky for data in other files. I think we'll have to rely on meta-data unless we want an explosion of names |
So what's the balance (if any) of length to descriptiveness? Do we actually want fully CF-compliant names that are really long? E.g. |
David, there's no argument about the fact that you're names are technically more correct by CF standard, but variables like mass_fraction_of_carbon_in_leaves are a mouthful. I think things like leaf_C or leaf_carbon are more practical, especially since the units are explicitly defined. |
Note that the variables table has room for both CF style and short names
|
And also that I am planning to add a thesaurus table
|
This issue is stale because it has been open 365 days with no activity. |
In an attempt to standardize and merge multiple leaf spectra-trait databases, I've come up with the following list of variables to use. I can modify the variable names at any time, but earlier would be better since I'll have to do less finding and replacing.
The text was updated successfully, but these errors were encountered: