[galeon] [cf-pointobsconvention] CF Extensions feedback

• To: "Unidata GALEON" <galeon@xxxxxxxxxxxxxxxx>
• Subject: [galeon] [cf-pointobsconvention] CF Extensions feedback
• From: John Caron <caron@xxxxxxxxxxxxxxxx>
• Date: Tue, 25 Mar 2008 09:23:43 -0600

Hi Rob:

Thanks for your comments, responses are below:


Rob Weingruber wrote:

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?).

as you can see, im cc'ing to the cf-pointobsconvention mailgroup.

* 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.

a tricky question as to when to make one a special case of another. lets see
whether in actual usage, data providers choose to do so.

* 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...

in this case, i would recommend storing the balloon sounding as a
trajectory.

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...

I would say the main difference is that a section has profiles/soundings
connected in z. A cross-section is connected in both its dimensions.

* 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

I think a cross-section (both vertical and horiz) would be categorized as a
swath, at least in the CDM feature types at

http://www.unidata.ucar.edu/software/netcdf-java/CDM/CDMfeatures.doc.

The data variables are clearly 2D, and one could use the swath "scan" and
"xscan" names for the dimensions:

temperature(scan, xscan);

the x,y,and z in general all have to be 2D to follow an arbitrary flight
path:

lat(scan, xscan);
lon(scan, xscan);
z(scan, xscan);

but the time could be constant:

time;

or vary only with the scan dimension:

time(scan);

I think this is a variation of a swath datatype, thanks for the use case!

(also, thanks for the nice pictures, can I steal them?)

Attachment: VertXSectPerspective.png
Description: PNG image

Attachment: HorizXSectPerspective.png
Description: PNG image