Re: CF1.0 compliant .nc file problems

Hi Stuart-

Sorry for the delay in responding. I've been on vacation.

Stuart Maclean wrote:
Thanks Don, I'll try the 1.2RC1 release.

Actually, after I had posted I did note one difference in the RUC data set and my .nc file, and that was that model variables in the RUC had an attribute named _CoordinateSystems, with value of a coordinate variable ("projectionCoordSys"). When I added this attribute to my .nc output tool, my data showed up fine in IDV 1.2b2, hurrah. I just stumbled on this really. I couldn't find any mention of this attribute name in the CF standard, nor in the IDV user guide. Of course it shows up in the source code search ;) I did try to single step IDV at .nc load time, but the nc2.2 jar bundled in IDV didn't match up source line wise to the nc2.2 src distro I have ;(

This is part of the nc2.2 code that is under development, so it's not
well documented yet.  The best place I can point you to is:

One more point now that I have solved the coordinate problems. The mm5 data set has some variables (atmospheric) available at taus 0, 3, .... 48. However, surface parameters are available at 3.. 48, i.e. not at 0. I do not really want to populate the nc file with large chunks of missing values. I'd prefer to define more than one time coordinate variable, and I presume > 1 time dimension. I'm a little unclear on how this would affect coordinate systems and grid mappings (since in the RUC, the projectionCoordSys variable mentions time in its axes list)? IS there still a single time 'axis'?? The RUC example had just one time variable, so I cannot glean info from it in this respect.

The latest release handles time coordinates for GRIB data like you
want.  If there are different sets of variables on different time
axes, they will get different coordinate systems.  However, I'm not
sure how this could be done in a netCDF file.  The GeoGrid interface
would need to know that there are multiple time coordinates.  I've
cc'd John Caron who wrote that interface so he can comment.
Alternatively, if you can put your MM5 output out in GRIB, you
could do it right out of the box (and save some disk space).

Don Murray                               UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307
        "Time makes everyone interesting, even YOU!"