[galeon] Fwd: CF Extensions feedback

• To: "Unidata GALEON" <galeon@xxxxxxxxxxxxxxxx>
• Subject: [galeon] Fwd: CF Extensions feedback
• From: "Ben Domenico" <Ben@xxxxxxxxxxxxxxxx>
• Date: Tue, 25 Mar 2008 09:22:27 -0600

Hi,

I just noticed that this had not gone to the GALEON list, but Rob asked me
to consider sending it, so here it is.  It's part of the discussion of CF
conventions for observational data that could be a key element of the basis
for establishing CF-netCDF for delivering these datasets via standard
protocol interfaces.

-- Ben

---------- Forwarded message ----------
From: Rob Weingruber <weingrub@xxxxxxxxxxxx>
Date: Fri, Mar 21, 2008 at 12:29 PM
Subject: CF Extensions feedback
To: John Caron <caron@xxxxxxxxxxxxxxxx>
Cc: Ben Domenico <Ben@xxxxxxxxxxxxxxxx>, Ethan Davis <
edavis@xxxxxxxxxxxxxxxx>


Hi John (CCing Ben and Ethan in case interested) -

Little bit of feedback for the CF extensions as documented at:

http://www.unidata.ucar.edu/software/netcdf-java/CDM/CFpoints.html

My $0.02, take it for what it's worth as Im still learning ;-)  Post to
whatever
groups you see fit (eg: GALEON?).

* Could/should #4 Profile Data just be a special case of #5 Station Profile
Data?
It seems that Profile Data is just Station Profile Data, where the time
dimension
has a size of 1.  To me it seems #4 can go away.

* In some cases, profile/sounding data might include time/lat/lon values
that vary
with Z. In other words, as the balloon is rising, it's recording the
time/lat/lon as
well as the wx phenomena. Rather atypical, but I have heard of such a thing.

In this case, the profile really becomes a trajectory.  Food for thought...

A coupla questions/comments in regards to the '6. Section Profile Data'.

* It seems that the same structure you suggest could/would be used for
vertical
cross-sections (through a forecast grid), yes? They seem the same...

* In 6.1, can the time *values* be constant along the time dimension?
This is important for our constant-time/single-forecast
cross-sections (yet we also envision time-varying xsects along a flightpath,
that combine/interpolate several forecasts into a single xsect result). It
seems
that a psuedocode example such as geoGrid.getValuesWhereTimeEquals(
"12:00Z")
would return the whole shabang (though an index could be used rather than a
time). See below***

* How about incorporating both a vertical and a horizontal xsect into the
same
structure? Im trying to represent the vert and horiz xsects along an
arbitrary 3D flightpath
in CF (rob's extension), as shown in the two attached 3d graphics. These
geometries are
important to our NNEW project. These may likely be different birds than your
'Section
Profile Data', but there seems to commonality too, and what do you think
anyway? eg:

dimensions:
   distanceFromPath = 42 ;  // UNLIMITED?
   time = UNLIMITED ;

variables:
   float distanceFromPath(distanceFromPath) ;
       distanceFromPath:long_name = "distance from path in vertical
dimension" ;  // for horiz xsect: orthogonal dist from path, in lat/lon
plane
       distanceFromPath:units = "km" ;
       distanceFromPath:positive = "up" ; // for horiz xsect: starboard or
port
   double time(time);
       time:long_name = "time" ;
       time:units = "days since 1970-01-01 00:00:00" ;

   float lon(time);
       lon:long_name = "longitude" ;
       lon:units = "degrees_east" ;
   float lat(time);
       lat:long_name = "latitude" ;
       lat:units = "degrees_north" ;
   float z(time) ;  // this is the z of the sampled point along the
flightpath
       z:long_name = "height above mean sea level" ;
       z:units = "km" ;
       // z:coordinates = "time lon lat distanceFromPath" ;  // I dunno
what these are, so leaving out for now ;-(

   float temperature(time, distanceFromPath) ;
       temperature:long_name = "temperature" ;
       temperature:units = "Celsius" ;

   float humidity(time, distanceFromPath) ;
       humidity:long_name = "reletive humidity" ;
       humidity:units = "%" ;

attributes:
 :CF_datatype = "vertical cross-section";  // or 'horizontal cross-section
------------------

*** That all assumes that time values can be constant.  If not, then I think
the following
would be appropriate:

dimensions:
   distanceFromPath = 42 ;  // UNLIMITED?
   sampleIndex = UNLIMITED ;

variables:
   float distanceFromPath(distanceFromPath) ;
       distanceFromPath:long_name = "distance from path in vertical
dimension" ;  // for horiz xsect: orthogonal dist from path, in lat/lon
plane
       distanceFromPath:units = "km" ;
       distanceFromPath:positive = "up" ; // for horiz xsect: starboard or
port
   float sampleIndex(sampleIndex) ;
       sampleIndex:long_name = "0 based index for sampled points along a
flightpath" ;
       sampleIndex:units = "none" ;

   double time(sampleIndex);
       time:long_name = "time" ;
       time:units = "days since 1970-01-01 00:00:00" ;
   float lon(sampleIndex);  // this is the lon of the sampled point along
the flightpath
       lon:long_name = "longitude" ;
       lon:units = "degrees_east" ;
   float lat(sampleIndex);
       lat:long_name = "latitude" ;
       lat:units = "degrees_north" ;
   float z(sampleIndex) ;  // this is the z of the sampled point along the
flightpath
       z:long_name = "height above mean sea level" ;
       z:units = "km" ;
       // z:coordinates = "time lon lat distanceFromPath" ;  // I dunno
what these are, so leaving out for now ;-(

   float temperature(sampleIndex, distanceFromPath) ;
       temperature:long_name = "temperacture" ;
       temperature:units = "Celsius" ;

   float humidity(sampleIndex, distanceFromPath) ;
       humidity:long_name = "reletive humidity" ;
       humidity:units = "%" ;

attributes:
 :CF_datatype = "vertical cross-section";  // or 'horizontal cross-section
---

Thanks.   ;-)

-- Rob

Attachment: HorizXSectPerspective.png
Description: PNG image

Attachment: VertXSectPerspective.png
Description: PNG image