Hi Rich,
This sounds like just the right solution. It's onsistent with the use
of precise_lon and precise_lat in Example H.5. (A single timeseries with
time-varying deviations from a nominal point spatial location)
It's a pretty complicated encoding, though. To make sure that you get
interoperability out of using it, it's important that other folks
generating/analyzing similar data do things the same way. (NOAA/PMEL
scientists are generating quite a lot of wire-crawler data, for
example.) So it seems like a good idea to write this up as a special
encoding example that, like H.5., gets explicitly documented in the next
CF version.
- Steve
==================================================
On 2/28/2017 11:18 AM, Signell, Richard wrote:
CF Folks,
Okay, with help from the ERDDAP community
https://groups.google.com/forum/#!topic/erddap/xfAufA8Qyhg
<https://groups.google.com/forum/#%21topic/erddap/xfAufA8Qyhg>
I think I figured this out:
The solution would be to use nominal "time(profiles)" and
"precise_time(obs)". So we would write something like
https://data.ioos.us/gliders//thredds/dodsC/deployments/rutgers/unit_191-20150105T1443/unit_191-20150105T1443.nc3.nc.html
<https://data.ioos.us/gliders//thredds/dodsC/deployments/rutgers/unit_191-20150105T1443/unit_191-20150105T1443.nc3.nc.html>
with both "time" and "precise_time", but instead of using the
multidimensional representation, use the ragged representation, like this
http://cfconventions.org/cf-conventions/cf-conventions.html#_ragged_array_representation_of_time_series_profiles
<http://cfconventions.org/cf-conventions/cf-conventions.html#_ragged_array_representation_of_time_series_profiles>
So in addition to "precise_time(obs)" we would also have data
variables like "temperature(obs)".
Thanks,
Rich
On Tue, Feb 28, 2017 at 7:27 AM, Signell, Richard <[email protected]
<mailto:[email protected]>> wrote:
CF Folks,
What would be the best DSG featureType to represent a wire-crawling
sensor that has a fixed lon,lat location, but non-uniform depth
interval as it goes up and down, and takes enough time that the
profile might not be accurately represented with a single time value?
On this ERDDAP site the featureType is "trajectory":
http://ooi-data.marine.rutgers.edu/erddap/info/CP04OSPM-WFP01-04-FLORTK000-flort_kn_stc_imodem_instrument-telemetered-d0005/index.html
<http://ooi-data.marine.rutgers.edu/erddap/info/CP04OSPM-WFP01-04-FLORTK000-flort_kn_stc_imodem_instrument-telemetered-d0005/index.html>
and I'm wondering if that's the best, or whether "timeSeriesProfile"
would be better, written as as ragged array with profile_index?
Certainly if we assigned a "nominal time" for each cast, then it would
clearly be representable as timeSeriesProfile, but it's not clear to
me that it meets the CF conventions if time varies within the cast.
There would be value in allowing the time-varying values within the
profile, but also labeling/indexing the profiles, so that people
could easily extract, say, all the "down" profiles, excluding the "up"
(or vice versa).
Thanks,
Rich
--
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
--
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
