Steve, It's good to hear you agree with this representation, and it's a great idea about submitting this as an example in the next CF version. There can't be too many examples!
-Rich On Sun, Mar 5, 2017 at 3:04 PM, Steve Hankin <[email protected]> wrote: > 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 > 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/rutg > ers/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 > > 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]> > 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 >> >> 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 > [email protected]http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -- 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
