Gold Standard for Parameters at depth/profiling

[joe-smithe-glos]

GLOS is trying to figure out the right approach to adding profiling datasets to ERDDAP to be in line with IOOS Metadata Profile 1.2 and gts_ingest.

Noting that the gold standard repository hasn't been updated in a while, and there's one example of an ADCP set only, we're wondering if there's been any further development on this end, and if we could collaborate on solidifying how such ERDDAP datasets should be composed.

We are aware of the TimeSeriesProfile representation, but we would like to also represent other multiple sensors at multiple depths. We previously believed (due to other conversation) that fell under TimeSeries multiple station, and would like to see examples of that if that's correct, otherwise we'd like to see examples under TimeSeriesProfile, in particular the datasets.xml chunks that'd be necessary to represent such data.

We are also aware of the information on the following links:

• https://ioos.github.io/ioos-metadata/ioos-metadata-profile-v1-2.html
• https://ioos.github.io/ioos-metadata/gold-standard-examples.html
• https://github.com/ioos/erddap-gold-standard

Please advise. Thanks, and take care

[srstsavage]

Hi @joe-smithe-glos,

We are aware of the TimeSeriesProfile representation, but we would like to also represent other multiple sensors at multiple depths. We previously believed (due to other conversation) that fell under TimeSeries multiple station, and would like to see examples of that if that's correct, otherwise we'd like to see examples under TimeSeriesProfile

Can you clarify a bit here, or post some example data/metadata? It sounds to me like TimeSeriesProfile is what you want, but some details would help. Note that the IOOS metadata profile restricts each dataset to a single platform, not sure if you meant multiple platforms or just multiple sensor devices by "represent other multiple sensors at multiple depths."

[joe-smithe-glos]

Clarifying the point you mentioned: we meant multiple sensor devices, which are placed at multiple depths. Totally understand the single platform rule for the Metadata Profile.

[kwilcox]

Hey @joe-smithe-glos,

Do you have a diagram of how the station is setup? Some questions below but really just tryinig to figure out what type of data you are describing!

• Are all sensor devices reporting on the same time frequency (or is the data eventually put into the same time frequency)?
• Do they depths change over time or between deployments of the stations/sensors?
• Is the data typically processed or analyzed together or as separate streams of data?
• Are the sensor devices measuring different variables at their positions?
• Are any of the sensors "profiling" or are they all fixed-depths sensors at the top, bottom, and/or along a mooring line?
  • If mooring line, is it important to capture the vertical drift of the mooring line or can it be assumed the sensor devices are at a fixed depth?
  • If profiling, are there other sensors measured outside of the vertical bins of the profiles (i.e. temperature at a bottom-mounted ADCP).
  • If profiling, do the vertical bins change between deployments? Can the data be averaged into common bins before it appears in ERDDAP?

[joe-smithe-glos]

I'll answer your questions in order here. We're not looking for a solution to a specific station, but a general solution that may cover most cases and all cases with a little modification:

• We have a station that reports surface parameters one minute and then benthic/sub-surface ones at multiple depths another minute. Data are not put in the same time frequency. Platform is built to handle parameters individually. See this as an example (buggy in Beta, caveat: https://seagull-beta.glos.org/data-console/93?date=2021-11-03)
• We can monitor depths over time if we wish for quality purposes. Otherwise assuming fixed depths.
• Can be analyzed as separate streams as in the example linked in the first bullet
• Sensor devices may measure different variables at different depths
• We have platforms with ADCPs, and as in the example in the first bullet, 'fixed' depth sensors
• • We let importance of drift be weighed by the data provider
• • There can be other sensors outside of the vertical bins of profilers
• • We haven't encountered a case like this yet, or at least I cannot recall. We're assuming whatever processing the data provider wants/needs done is complete prior to arrival here