Dear All,
Forwarded from another list, but it answers a question I asked on the CF list, so I've forwarded it.
Cheers, Roy.
Please note that I now work part-time from Tuesday to Thursday. E-mail response on other days is possible but not guaranteed!
-----Original Message-----
From: Christian Ward-Garrison [mailto:cwardgar at unidata.ucar.edu]
Sent: 26 March 2014 23:33
To: sdn2-netcdf at listes.seadatanet.org
Subject: Re: [sdn2-netcdf] Extensions to cover ADCP data
Hi Roy,
In CF, it's necessary to define a set of variables that define your coordinate system. That much we all know. But once those have been defined, you're free to add any ancillary variables that you want, even spatiotemporal ones. As a result, there's no reason that you can't mix 2D per-profile data (trajectory, profile) with 3D per-observation data (trajectory, profile, z). Here is an example that illustrates this concept:
netcdf file:C:/Users/cwardgar/Desktop/adcp.ncml {
dimensions:
trajectory = 2;
profile = 3;
z = 4;
variables:
int trajectory(trajectory=2);
:cf_role = "trajectory_id";
float lon(trajectory=2, profile=3);
:standard_name = "longitude";
:units = "degrees_east";
float lat(trajectory=2, profile=3);
:standard_name = "latitude";
:units = "degrees_north";
float seabed_current_velocity(trajectory=2, profile=3);
:units = "m/s";
float seabed_alt(trajectory=2, profile=3);
:standard_name = "altitude";
:units = "meters";
:positive = "up";
float platform_alt(trajectory=2, profile=3);
:standard_name = "altitude";
:units = "meters";
:positive = "up";
double time(trajectory=2, profile=3);
:standard_name = "time";
:long_name = "time";
:units = "days since 1970-01-01 00:00:00";
float observation_alt(trajectory=2, profile=3, z=4);
:standard_name = "altitude";
:units = "meters";
:positive = "up";
float geophysical_variable(trajectory=2, profile=3, z=4);
:coordinates = "time lon lat observation_alt";
// global attributes:
:featureType = "trajectoryProfile";
:Conventions = "CF-1.6";
}
The coordinates attribute of geophysical_variable tells us that the Z coordinate variable for this example is the 3D observation_alt. However, that doesn't stop us from defining the 2D seabed_alt and platform_alt.
Similarly, we can define the 2D seabed_current_velocity as well.
Note that observation_alt is very close to the PROFZ that you described.
Indeed, although I have defined it as altitude relative to sea level, there's nothing stopping you from defining it relative to platform_depth. However, I suggest that you leave it as a spatial unit (height or pressure); the spirit of CF is to make those coordinates explicit. But once again, there's nothing stopping you from defining an ancillary variable that is non-spatial.
Attached is the NcML file I used to generate the example.
Cheers,
Christian
> -------- Original Message --------
> Subject: [sdn2-netcdf] Extensions to cover ADCP data
> Date: Mon, 24 Mar 2014 08:33:45 +0000
> From: Lowry, Roy K. <rkl at bodc.ac.uk>
> Reply-To: sdn2-netcdf at listes.seadatanet.org
> To: sdn2-netcdf at listes.seadatanet.org
> <sdn2-netcdf at listes.seadatanet.org>
> CC: gilbert.maudire at ifremer.fr <gilbert.maudire at ifremer.fr>
>
> Dear All,
>
> Gilbert Maudire and Michele Fichaut at IFREMER have been doing some
> work to extend the SeaDataNet NetCDF format to cover vessel-mounted
> ADCP data from both surface ships and submarines (AUVs). This has
> raised a number of issues, some of which I tried raising on the CF
> list, but the silence has been deafening!
>
> First, there is the issue of 'single-depth' geophysical variables. The
> example for VMADCP are the seabed current velocity parameters from
> bottom tracking in shallow water, that have a single value with a z
> co-ordinate of the bathymetric depth for each ADCP profile. One
> possibility would be to mix the 3-D profiles (instance, time, bin
> depth) and the bottom-tracking 2-D vectors (instance, time) in the
> same file. Having given this some thought and discussed it with
> Gilbert the conclusion is that this is not a good idea and that the
> data should be split between two files, one with trajectory feature
> type and the other with trajectoryProfile feature type. Any other views?
>
> Secondly, there's the issue of AUV ADCP. The initial solution was to
> give the geophysical variable z co-ordinate a time dimension. However,
> to me this blows the definition of the trajectoryProfile feature type
> out of the water. Another idea would be to keep the trajectoryProfile
> co-ordinates identical to those for trajectory, with latitude,
> longitude and optionally depth along the time dimension and then add
> another co-ordinate variable - say PROFZ - to be the z co-ordinate of
> the geophysical variable arrays. This could hold AUV data if the DEPTH
> dimension were set to the platform depth and PROFZ set to the vertical
> distance of the measurement from the platform. This is how all the
> AUV ADCP data I have experienced (Autosub I) was delivered - nobody
> ever worked up the data to tag each measurement with its absolute
> depth. Does anybody know of data like these and if so should we be
> pushing for an appropriate CF 1.6 feature type?
>
> Another advantage of the PROFZ idea is that the z co-ordinate could be
> non-spatial. This would allow the profileTrajectory feature to be
> modelled to data such as optical plankton counter fitted to towed net
> platforms such as ARIES. In this case the platform depth would be the
> DEPTH variable along the time dimension and PROFZ would be the size
> class mean.
>
> I did wonder whether the PROFZ concept could be extended to the
> seriesProfile feature type, but I think it's still a good idea. For
> example IMOS like to include a depth parameter along the time
> dimension for some moored instruments and this could get very messy if
> DEPTH were used as the profile z co-ordinate as well.
>
> Any other views on PROFZ?
>
> Cheers, Roy.
>
> This message (and any attachments) is for the recipient only. NERC is
> subject to the Freedom of Information Act 2000 and the contents of
> this email and any reply you make may be disclosed by NERC unless it
> is exempt from release under the Act. Any material supplied to NERC
> may be stored in an electronic records management system.
>
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adcp.ncml
Type: text/xml
Size: 2539 bytes
Desc: adcp.ncml
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140327/37ef9c23/attachment.xml>
Received on Thu Mar 27 2014 - 02:09:27 GMT
