Vertical dimension in NJ

[John Caron]

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.
>>> rbs
>>>>
>>>> Robert 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 behavior
>>>>> between 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 
>>>>> (tagged
>>>>> with 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 at giss.nasa.gov
>>>>> NASA Goddard Institute for Space Studies, 2880 Broadway, New York, 
>>>>> NY 10025
>>>>
>>> -- 
>>> Robert B. Schmunk, rschmunk at giss.nasa.gov
>>> NASA Goddard Institute for Space Studies, 2880 Broadway, New York, NY 
>>> 10025
>>
> 
> -- 
> Robert B. Schmunk, rschmunk at giss.nasa.gov
> NASA Goddard Institute for Space Studies, 2880 Broadway, New York, NY 10025