- Tim
> From ethan@niwot.scd.ucar.EDU Fri Sep 25 12:39:50 1992
> Subject: Re: netCDF use at WHOI (comments)
> To: holtt@oce.orst.edu (Tim Holt)
>
>Tim,
>
>I think there may a slight misunderstanding here. IMHO , when the OarS
people
>state that data should be configured in four dimensions they are stating
>that the data is GRIDDED DATA...
I didn't get that impression from the conventions.ps and flow.ps files.
At some point, the raw data from the sensors aboard the bouy, boat, or
whatever the platform is, needs to go into a data file. I'd assume by
looking at the flow diagram that this is in netCDF.
> ...and the CDL header would look like the
>following, with the attributes omitted:
>
>This is how gridded data appears in netCDF files
>
> dimensions:
> time = unlimited; // 10 currently
> x = 73;
> y = 73;
> z = 10;
> variables:
> long time(time); // total size = 10
> float x(x); // total size = 73
> float y(y); // total size = 73
> float z(z); // total size = 10
> float temp(time,x,y,z); // total size = 10 * 73 * 73 * 10
>
>What you have described with the followin CDL header is how a
>random data set is stored in a netCDF files. And I claim that your
>definition of the data is in fact only 3 dimensional not four dimensional
>as the above example because the air_temp variable is not a spacial
>coordinate variable like gps_lat and gps_lon are or x,y and z are above.
I'm not sure of the "definition" of dimensions, but I'd assume that any
given air/sea temperature measurement has 4 dimensions associated with
it: X, Y, X, and Time.
>
>>
>>
>> dimensions:
>> time = unlimited;
>> variables:
>> long time(time); // seconds since my cat's birthday
>> float gps_lat (time); // Y
>> float gps_lon (time); // X
>> float air_temp (time);
>> air_temp:z = "0.0"
>> float sea_temp (time);
>> sea_temp:z = "5.0"
>>
>
>
>--
>Another thing to note is that your representation of the data only allows
>one data point per time index, where the OarS representation has multiple
>data points per time index.
Not really a problem for underway, at-sea sampling of raw data (for me
anyway).
>
>These are two completely differnt classes of data and as such should
be
>treated differently. They require different types of processing and
>visualization.
>
>Most likely the OarS software will be constrained to only handle
>gridded data...
That's too bad.
> ...and you will have to find some way of interpolating your
>data onto a grid. ...
That's kind of impossible, given the nature of the data and the platform.
I guess I could store a profile of meteorological data
from the ship in a 1x10000 grid that represents 10,000 measurements as we do
a transit from San Francisco, CA to Newport, OR. You really can't grid
data when you only have one track. I spent several years going to sea
collecting gravity and magnetic data for potential fields studies, and
that you can grid, but only because you are making many long, parallel
tracklines that are only 5-10 km apart. That kind of a cruise is not
necessarily the norm for all research vessels.
Also, different Marine Tech groups at universities work under different
mandates. Unlike the OarS/BoaT group, we are mandated to provide raw
data along with a certain amount of real time visualization of the data.
We also provide tools for cruise track and ship navigation planning.
>... Or the OarS software will have to support different
>classes of data differently.
I hope so.
>
>
>-ethan
>--
>Ethan Alpert internet: ethan@ncar.ucar.edu | Standard Disclaimer:
>Scientific Visualization Group, | I represent myself only.
>Scientific Computing Division |-------------------------------
>National Center for Atmospheric Research, PO BOX 3000, Boulder Co, 80307-3000