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 <steven.c.hankin at noaa.gov>
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 <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
>>
>> 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 listCF-metadata at cgd.ucar.eduhttp://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170305/242f9ec7/attachment.html>
Received on Sun Mar 05 2017 - 15:10:09 GMT
