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 <rsignell at usgs.gov
> <mailto:rsignell at usgs.gov>> 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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170305/58d3fc42/attachment.html>
Received on Sun Mar 05 2017 - 13:04:23 GMT
