-
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
Dataset Submission: HakaiPruthMooringProvisional #17
Comments
The real-time data from this node is available through a database view. Here you can view the daily data.
|
@JessyBarrette now that the automated QC configuration has been improved a bit, I'm looking at how to create an ERDDAP dataset for this. I'm currently thinking that we should share the five minute data, as we did for many of the other datasets mapped from the sensor network database. However, I not sure how to handle the measurements at different depths properly. That is, can/should we continue to define a set of dataset fields for each measurements (ie. five minute average or median value, UQL level, secondary QC flag) and assign a depth value to each measurement ..... or will we need to handle the measurement at each depth as a separate ERDDAP record? Not sure if I'm explaining this right or not. Maybe we should discuss. |
dataset or datasetS Sample Rate Sort variables |
Thanks @JessyBarrette I was thinking of one ERDDAP dataset. Re: I think it would be best to stack each temperature and associated stats and flags to single variables and create a depth variable that describes each record's specific depth. It will definitely make the data easier to handle through erddap like any other datasets.... That is the key thing I was wondering about. @n-a-t-e do you know if/how we can transform the results returned from the database to do this? Specifically, the database will return separate columns with measurements at different depths, and we would like the ERDDAP dataset to break it out to provide (time, depth, measurement QC) columns instead -- assuming I understand @JessyBarrette correctly. A representative database view is PruthMooring:5minuteSamples. |
We would have to sort this out at the database level, creating views with one depth column instead of a column for each depth, and then connect that to ERDDAP. Should be easy enough to do |
Cool. I'm a database view novice, and have not done that type of thing before. Can you take a crack at defining such a database view? I'm thinking it would be helpful to have a workflow available to define custom views that are automatically (re)created when the underlying tables are (re)created and are used by ERDDAP. |
Ideally, you would also need to generate a site, lat, long and source file
name variable. QU5 has been at the same site the whole time while Pruth
moved to another location after one year. I can get the official locations
for you.
…On Wed, Mar 3, 2021 at 9:09 AM Ray Brunsting ***@***.***> wrote:
We would have to sort this out at the database level, creating views with
one depth column instead of a column for each depth, and then connect that
to ERDDAP. Should be easy enough to do
Cool. I'm a database view novice, and have not done that type of thing
before. Can you take a crack at defining such a database view? I'm thinking
it would be helpful to have a workflow available to define custom views
that are automatically (re)created when the underlying tables are
(re)created and are used by ERDDAP.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHICYONCV2JDUHTZKBP53CLTBZUNPANCNFSM4YPWPDHQ>
.
--
*Jessy Barrette M.Sc.*
*Marine Instrumentation Specialist*
Hakai Institute <https://www.hakai.org/> | jessy.barrette@hakai.org | (C)
(250) 208-7806
|
Having the database view populate and return the latitude and longitude may be a good approach, assuming it could populate those fields with different values based on date/time. In a few cases (e.g. KC Buoy) the lat/long are stored in the SN database and can be passed through to ERDDAP. In many other cases, the lat/long are fixed and could be added into the view as such (ie. most terrestrial sensor nodes that don't move). |
ERDDAP recommends to associated latitude and longitude variables to fix
values that relate to the site location. For cases where a precise time
variable location exist, ERDDAP suggest using the field preciseLat and
preciseLon
https://coastwatch.pfeg.noaa.gov/erddap/download/setupDatasetsXml.html#cdmTimeSeries
This doesn't apply to the tidbit moorings but certainly to the KC Buoy.
This is what I'm hoping to do with the CTD profile datasets too and should
ideally be a standard within Hakai/CIOOS. This can also be very useful for
running QARTOD tests on the data in the future.
On Wed, Mar 3, 2021 at 10:12 AM Ray Brunsting <notifications@github.com>
wrote:
… Ideally, you would also need to generate a site, lat, long and source file
name variable. QU5 has been at the same site the whole time while Pruth
moved to another location after one year. I can get the official locations
for you.
… <#m_7596592719505883172_>
On Wed, Mar 3, 2021 at 9:09 AM Ray Brunsting *@*.***> wrote: We would
have to sort this out at the database level, creating views with one depth
column instead of a column for each depth, and then connect that to ERDDAP.
Should be easy enough to do Cool. I'm a database view novice, and have not
done that type of thing before. Can you take a crack at defining such a
database view? I'm thinking it would be helpful to have a workflow
available to define custom views that are automatically (re)created when
the underlying tables are (re)created and are used by ERDDAP. — You are
receiving this because you were mentioned. Reply to this email directly,
view it on GitHub <#17 (comment)
<#17 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHICYONCV2JDUHTZKBP53CLTBZUNPANCNFSM4YPWPDHQ
.
-- *Jessy Barrette M.Sc.* *Marine Instrumentation Specialist* Hakai
Institute https://www.hakai.org/ | ***@***.*** | (C) (250)
208-7806
Having the database view populate and return the latitude and longitude
may be a good approach, assuming it could populate those fields with
different values based on date/time. In a few cases (e.g. KC Buoy) the
lat/long are stored in the SN database and can be passed through to ERDDAP.
In many other cases, the lat/long are fixed and could be added into the
view as such (ie. most terrestrial sensor nodes that don't move).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHICYOOHA5YWSNP65KTTGMDTBZ32TANCNFSM4YPWPDHQ>
.
--
*Jessy Barrette M.Sc.*
*Marine Instrumentation Specialist*
Hakai Institute <https://www.hakai.org/> | jessy.barrette@hakai.org | (C)
(250) 208-7806
|
As @JessyBarrette is saying, we can set the lat/long to fixed values right in datasets.xml when appropriate. So it could be in the view but wouldn't have to be |
Can that be done based on time? (ie. like with the Pruth Mooring where the mooring was relocated after the first year). If so, cool. |
Only if the lat long are the same for all the data of that dataset though I
would think. It wouldn't work if we combine multiple sites.
…On Wed, Mar 3, 2021 at 10:29 AM Nate ***@***.***> wrote:
As @JessyBarrette <https://github.com/JessyBarrette> is saying, we can
set the lat/long to fixed values right in datasets.xml when appropriate. So
it could be in the view but wouldn't have to be
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHICYOOBUVJ3KUQ2BHQQ3YLTBZ5WXANCNFSM4YPWPDHQ>
.
--
*Jessy Barrette M.Sc.*
*Marine Instrumentation Specialist*
Hakai Institute <https://www.hakai.org/> | jessy.barrette@hakai.org | (C)
(250) 208-7806
|
@JessyBarrette oh right, forgot that you are combining sites. I created a view |
Nice. I tried our the following queries and it worked well.
As a general approach, perhaps we should maybe put the database view definitions in this repo and automatically run them when the sensor network database changes....like you are doing now. I can imagine a bunch of situations where explicitly defined database views will work better than auto-generated. I'm not sure about performance/turning, but I imagine you can do things to address any performance issues. |
Here's the moorings location over time
|
@raytula Just to make things clear regarding those two Tidbits Mooring datasets. Should regroup them together as one dataset, or keep the two sites separate? |
Hmm. Not sure. I would be inclined to keep them separate, so let's start with that. Nate will be putting the related database views in this repo and working with you to define the datasets.xml fragments to get those views integrated into ERDDAP. If we were to combine them, would it make sense to bundle it with the Provisional River's Inlet mooring data? |
I would keep it separate from rivers inlet since the sensors havea
different accuracy. Ok let's make two separate for now
Le lun. 8 mars 2021 2:45 p.m., Ray Brunsting <notifications@github.com> a
écrit :
… @raytula <https://github.com/raytula> Just to make things clear regarding
those two Tidbits Mooring datasets. Should regroup them together as one
dataset, or keep the two sites separate?
Hmm. Not sure. I would be inclined to keep them separate, so let's start
with that. Nate will be putting the related database views in this repo and
working with you to define the datasets.xml fragments to get those views
integrated into ERDDAP.
If we were to combine them, would it make sense to bundle it with the
Provisional River's Inlet mooring data?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHICYOLZCATICIBQCO6O37LTCVHRXANCNFSM4YPWPDHQ>
.
|
I created a metadata record for this dataset: |
Looks good to me. |
The metadata form was updated to reflect the provisional aspect |
Mostly need now to add more documentation to the dataset.xml |
This dataset is now available online. We can close that issue! |
Hakai Dataset Submission
Below are listed all the different steps related to the initial submission of a dataset.
A more detailed written and visual description of every step is available respectively
here and here.
Submission steps
Initial Submission (Data Administrator)
ERDDAP Dataset Creation (Data Integrator)
Dataset Review (Data Administrator)
Dataset Completion (Data Integrator)
The text was updated successfully, but these errors were encountered: