-
Notifications
You must be signed in to change notification settings - Fork 23
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
Add a table to store environmental data #107
Comments
Adding a fact table for environmental data as described in GMOD#107.
By the way, I don't need an "end time" on capture date but it may be useful for others. Should we add something like "timecapturedend TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,"? |
What is the status on this? I mentioned to @guignonv that it would be nice if the PR #108 could be reworked to be in migrations rather than changing the sql file directly, but I can do that since it's been awhile since this has been touched. Does anybody have an opinion about the need for a "timecapturedend" field? |
I think it's a good idea to add the PS. I approve this table addition 👍 and we would work it into our environmental data storage plans! |
I added a commit that adds the |
We're moving away from Chado for non-technical reasons, but we often thought we wanted to store "interventions" (e.g. insecticide spray campaigns, bednet distribution etc) in Chado and this would have been great. |
For people doing plant characterization or breeding, it may be useful to store environmental data (climatic data and other). Those data are related to a specific geo-location and are taken at a given time. Therefore I would tend to use the nd_geolcation table for geo-locations and add a nd_fact table:
The text was updated successfully, but these errors were encountered: