-
Notifications
You must be signed in to change notification settings - Fork 4
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
First pass at adding thermal metrics metadata #18
First pass at adding thermal metrics metadata #18
Conversation
Merge branch 'master' of github.com:USGS-R/mntoha-data-release into add_thermal_metrics_metadata # Conflicts: # 7_habitat.yml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work!
You had a question/comment about the ranges. We're debating that a bit internally (I think there is a thread in the pipeline channel). We think that technically the field is used for the min max the value could possibly be, but not the min/max as it actually appears in the data release. So we don't really understand how to put a number in there for most things and putting a number doesn't seem to serve a purpose. Such as water temperature - what is the max value, 100°? but at the elevation of this study, it would be different. Same thing w/ min. Water can be below freezing if it is moving or is very still doesn't have any particles to form ice on...Gets worse with things related to depth, because how deep is "max"? Anyhow, that's why we have a lot of NAs. We really need to get that discussion/decision cleared up though.
rendered_metadata <- lapply(fill_data_list, whisker.render, template = temp_range_template) | ||
writeLines(unlist(rendered_metadata), out_file) | ||
|
||
message(sprintf("NOW MANUALLY COPY THE CONTENTS OF %s INTO `in_text/text_07_habitat.yml`", out_file)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting approach. meddle::render
can have any number of yaml files or R list objects, but currently I do think you need to use some approach like this (instead of passing both the yaml and an autogenerated list to render) because there is no way to replace sub elements of the metadata without replacing the whole thing, which in this case would be entities
. Issue covered in here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, since this was mostly to just save myself from copy/pasting a bunch of things (it was easier and faster to write this function than it would have been to do copy/paste over and over and over) that are not likely to update very frequently, I thought that doing half automated, half manual was acceptable.
I focused mostly on the
entities
section, though I did try to edit some of the others where I could. I left in some notes about adding references that we use in theentities
section.Two questions:
Anyways, this feels like a good start!