> Bottom line: I need to tell the user what depth range I am covering (0-4500 > or 0-3000), and in my limited understanding of the situation this is done > via the cell_methods and cell_bounds attributes.
Right, got it (I think). In your particular use case it's important to describe the depth range covered, because you are deriving temperature from it. So in another use case for this standard_name, someone might know the temperature independently, and then use the return to calculate distance; or might know or assume the temperature and distance is a given, and their interest is strictly in consistency of the return time? In which case they might appropriate describe different things, or no things, in cell methods/bounds. I was worried you were proposing to define, for this general concept of round trip return time, a specific set of cell methods/bounds, suitable only for one of the possible use cases. But it sounds like you are just describing your own practice, not what goes in the definition. Thanks very much for the time to clarify. John On May 30, 2013, at 15:12, Matthias Lankhorst <mlankho...@ucsd.edu> wrote: > Hi, > > thanks already for these comments. Roy's suggested name sounds pretty to my > ears. > > Trying to explain my "cell_methods" thing: > > The instrument is sitting at a fixed spot on the seafloor, so unlike the echo > sounder on a ship, the distance does not change (well, there are tides, but > we > filter them out). The remaining signal variance is variability in > environmental sound speed, which is mostly a measure of sea water temperature. > > The data, although measured by an instrument at one spot, are dependent on > the > vertical distance that the acoustic signal travels, i.e. represent some space > other than a single point. Chapter 7 of the CF document that I found online > explains it this way: "When gridded data does not represent the point values > of a field but instead represents some characteristic of the field within > cells of finite "volume," a complete description of the variable should > include metadata that describes the domain or extent of each cell..." > > In my example, let us assume my IES sits at 4500m depth looking up. The > acoustic signal travel time (roundtrip) will be about 6 seconds (sound speed > is ca. 1500 m/s). My data will be numbers that are closer to 5.9 seconds if > it > is warm (faster sound speed), and more like 6.1 seconds if it is cold. > > If my instrument were instead sitting in the same body of water at 3000m > depth > (let's assume there is a mountain nearby), all of my numbers would be > something close to 4 seconds. Now... I don't want the user to think I am > still > in 4500m depth in outrageously hot water! > > Bottom line: I need to tell the user what depth range I am covering (0-4500 > or > 0-3000), and in my limited understanding of the situation this is done via > the > cell_methods and cell_bounds attributes. > > Best wishes, Matthias > > > On Thursday, May 30, 2013 09:49:29 am Lowry, Roy K. wrote: >> Hi John, >> >> Not exactly. The travel time in both water column echosounding and >> seismics is a proxy for distance and therefore provides information on the >> vertical distribution of returned signal intensity. >> >> Cheers, Roy. >> >> ________________________________________ >> From: John Graybeal [grayb...@marinemetadata.org] >> Sent: 30 May 2013 15:22 >> To: Lowry, Roy K. >> Cc: mlankho...@ucsd.edu; cf-metadata@cgd.ucar.edu >> Subject: Re: [CF-metadata] standard_name for acoustic travel time from echo >> sounder >> >> +1 for Roy's choice. >> >> Can you explain the following for the acoustically naive? "I assume the >> data would need some additional description to denote the vertical extent >> of the measurement, such as cell_bounds and cell_methods='Z:sum'." >> >> John >> >> On May 30, 2013, at 06:45, "Lowry, Roy K." <r...@bodc.ac.uk> wrote: >>> Dear All, >>> >>> Of Matthias's suggestions I have a strong preference for a slight >>> extension of roundtrip_acoustic_travel_time_in_sea_water, namely >>> acoustic_signal_roundtrip_travel_time_in_sea_water. 'two-way' is a >>> possible alternative to 'roundtrip' but I think the former carries >>> unfortunate seismic semantic implications, so 'roundtrip' is better for >>> IES. Including 'in_sea_water' is also essential to clearly distinguish >>> it from seismic data. >>> >>> Cheers, Roy. >>> ________________________________________ >>> From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of >>> Matthias Lankhorst [mlankho...@ucsd.edu] Sent: 30 May 2013 13:16 >>> To: cf-metadata@cgd.ucar.edu >>> Subject: [CF-metadata] standard_name for acoustic travel time from echo >>> sounder >>> >>> Dear CF, >>> >>> I have oceanographic data from IES instruments (inverted echo sounder) >>> that I would like to publish via OceanSITES in a CF-compliant form. The >>> data in question are acoustic travel times from the echo sounding >>> device. This means the time it took for the acoustic signal to run from >>> the instrument (which sits on the seafloor) to the sea surface and back >>> to the instrument. These data are commonly used as a proxy for ocean >>> heat content. >>> >>> I don't think there is a suitable CF standard_name out there, and ask for >>> your help in finding/creating one. Which of the following sound good? >>> >>> acoustic_travel_time >>> vertical_acoustic_travel_time >>> roundtrip_acoustic_travel_time_in_sea_water >>> echo_sounder_acoustic_travel_time >>> >>> ...I could think of a couple more combinations using the words above, but >>> would like to hear other people's opinions. >>> >>> The canonical units would obviously be seconds. >>> >>> I assume the data would need some additional description to denote the >>> vertical extent of the measurement, such as cell_bounds and >>> cell_methods='Z:sum'. >>> >>> Any comments? >>> >>> Kind regards, Matthias >>> >>> > > -- > _______________________________________ > > Dr. Matthias Lankhorst > Scripps Institution of Oceanography > 9500 Gilman Drive, Mail Code 0230 > La Jolla, CA 92093-0230 > USA > > Phone: +1 858 822 5013 > Fax: +1 858 534 9820 > E-Mail: mlankho...@ucsd.edu > http://www-pord.ucsd.edu/~mlankhorst/ > --------------- John Graybeal Marine Metadata Interoperability Project: http://marinemetadata.org grayb...@marinemetadata.org _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
