-
Notifications
You must be signed in to change notification settings - Fork 0
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 NT instrumentation view #134
Conversation
still to do would be to create the xml file's for the new datasets. also, an 'organization' field was added to the post_qc view so this should be added or dropped from the xml file for the hakai instrumentation dataset |
… processing stage and organization field
7293f21
to
836a43a
Compare
@@ -7,14 +7,13 @@ FROM | |||
ctd.ctd_post_qc_data d | |||
WHERE | |||
( | |||
d.cast_processing_stage >= '8_binAvg' :: ctd.processing_stage | |||
OR d.cast_processing_stage >= '8_rbr_processed' :: ctd.processing_stage | |||
d.cast_processing_stage >= '10_qc_pi' :: ctd.processing_stage |
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.
the processing_stage seemed wrong to me. but maybe it was ment to be the same for reasearch and provisional, not sure
Hum not sure if that's for the same purpose but I've made similar views and
datasets but in the cioos-pacific-erddap. The different components are
already within the dev branch
Le jeu. 2 févr. 2023 6:42 p.m., Matthew Foster ***@***.***> a
écrit :
… ***@***.**** commented on this pull request.
------------------------------
In views/HakaiWaterPropertiesInstrumentProfileResearch.sql
<#134 (comment)>
:
> @@ -7,14 +7,13 @@ FROM
ctd.ctd_post_qc_data d
WHERE
(
- d.cast_processing_stage >= '8_binAvg' :: ctd.processing_stage
- OR d.cast_processing_stage >= '8_rbr_processed' :: ctd.processing_stage
+ d.cast_processing_stage >= '10_qc_pi' :: ctd.processing_stage
the processing_stage seemed wrong to me. but maybe it was ment to be the
same for reasearch and provisional, not sure
—
Reply to this email directly, view it on GitHub
<#134 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHICYON7XRAEWZV364QRHIDWVRA7VANCNFSM6AAAAAAUPUHS7Q>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
@fostermh I assumed back then that we wanted those non hakai datasets within the CIOOS Pacific ERDDAP? Is that true or we would want them in Hakai's one |
given that we are hosting the original data source in the hakai database I assumed we would serve it from a hakai erddap along with a metadata record in the hakai catalogue. all of which would flow up into cioos pacific. Perhaps a discussion to have with the group. As you say, from a technical perspective either way would work. |
It makes sense to me that it would flow from Hakai to CIOOS. |
Ok I'll move all the datasets from cioos-pacific to hakai erddap. |
@fostermh I added little change to your table view of the NT tables to include both the static records (when cast_type is static) and downcasts. I generated a new table for provisional and research datasets for all the different organizations. There will likely be a separate discussion with each different dataset and the related people. |
sorry if this is a silly comment, I have not been involved in the development of the datasets to date, but shouldn't the parks canada, skeena, and UofW datasets be in their own branches? How do you prevent accidentally deploying datasets to erddap if you merge all this in before it is approved by the respective organizations? |
all those goes to the dev branch which is presented on the goose.hakai.org/erddap. going from dev to master has often been a bit tricky and I have been doing some git workaround to help merging one to the other without merging all. Nate and I talked before Christmas about a few ways to improve the workflow by adding a development folder where only the dev stuff will live. We haven't yet implemented that but maybe it will be time with all the different projects happening in parallel right now. |
one option would be to maintain a branch for each dataset you are working on. it would be a 'hot fix' in the world of git flow and would branch off of master. When ready to test you merge it into development. once approved and your happy, the same branch is then merged into master. I expect Nate has other suggestions as well. |
yeah I'm happy to fit which everway. The other issue I forgot to mention is that the database view and tables from this repo are drop nightly and regenerated from the master branch only and our development erddap is also pulling from the hakai database (not hakaidev) |
That's a good idea, I may close this present PR and reapply the proposed changes here following this suggested method |
Thinking about it better, I think it will be easier to add those present changes to the dev branch and proceed to modify the repository workflow as discussed with @n-a-t-e before the break. Until the new workflow is establish (which shouldn't take long), merging this PR and #138 should make the different datasets available on the development erddap. |
also fix hakai instrumentation view processing stage