Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Hi Robert: The problem is that the vertical coordinate is not being recognized. Section 4.3 of CF specifies a vertical coordinate is identified by units of pressure or the "positive" attribute. The older version of the code was making anything not recognized into a vertical coord, but that was causing errors in other files, so i had to change to conform to the spec.Can you let the writer of the file know, hopefully they can fix at the source.
Sorry for the trouble, John Robert B. Schmunk wrote:
Take a look in ftp://ftp.giss.nasa.gov/outgoing/caron/ There are two files. tavg.00005.01.01.nc is the original. tavg.00005.01.01x.nc is the one I "fixed" by adding the positive attribute There are about 8 variables which have a vertical dimension. NJ 2.2.18 recognizes them in the original file, but NJ 2.2.20 only in the "fixed" file. By "recognize", I mean that the hasVerticalAxis() method in the variables' CoordinateSystems is true. rbs On Jun 27, 2007, at 18:45, John Caron wrote:im not sure whats going on, can yo send me the file? Robert B. Schmunk wrote:On Jun 27, 2007, at 17:43, John Caron wrote:Do you know what Conventions are being used (ie what CoordSysBuilder class is being used?)If I add some diagnostics right after opening the dataset NetcdfFile ncf = NetcdfDataset.acquireFile (url.toString ( ), null); NetcdfDataset ncd = new NetcdfDataset (ncf); CoordSysBuilder csb = new CoordSysBuilder ( ); csb.buildCoordinateSystems (ncd);System.out.println ("csb uses convention " + csb.getConventionUsed ( ));I get that csb uses convention _Coordinates Same result using either NJ 2.2.18 or 2.2.20. rbsRobert B. Schmunk wrote:John, I'd like to check with you about a change that seems to have occurred between NJ 2.2.18 and 2.2.20 when it comes to recognition of vertical dimensions. After a query from a user, I was tracking down a change in behaviorbetween two versions of my Panoply application and found that it resulted from updating from using NJ 2.2.18 to NJ 2.2.20. In his dataset (taggedwith the convention attribute value "CF-1.0", there is a dimension described as double zt(zt=19); :axis = "Z"; :edges = "zt_edges"; :long_name = "depth of the t grid"; :standard_name = "depth"; :units = "m"; If Panoply uses NJ 2.2.18, this dimension is recognized. If Panoply uses NJ 2.2.20, this dimension is not recognized, but it can be made recognizable by adding a :positive = "down"; attribute. At this point my main question is whether this change in behavior was deliberately made? If so, what was the reasoning for making it? Thanks for your help, rbs -- Robert B. Schmunk, rschmunk@xxxxxxxxxxxxxNASA Goddard Institute for Space Studies, 2880 Broadway, New York, NY 10025-- Robert B. Schmunk, rschmunk@xxxxxxxxxxxxxNASA Goddard Institute for Space Studies, 2880 Broadway, New York, NY 10025-- Robert B. Schmunk, rschmunk@xxxxxxxxxxxxx NASA Goddard Institute for Space Studies, 2880 Broadway, New York, NY 10025
netcdf-java
archives: