[THREDDS #RVU-583307]: problem with netcdf subset as point service

Hi Don,

Yes, the current stable release listed on the web site is 4.2.19. (Sorry, you 
have to dig down to the CHANGES file to see the release number.)

We plan to release TDS 4.2.4 in the next week or so. We are running the current 
release candidate here

http://motherlode.ucar.edu:8080/thredds/catalog.html

If you want to take a look.

Ethan

> Thanks, John.  Welcome back.
> 
> Is 4.2.19 an official release (4.2.18 was experimental)?
> 
> Is there going to be a TDS release soon that will include this (since
> it's in the thredds/server package?
> 
> Don
> 
> On 2/1/11 4:56 PM, Unidata THREDDS Support wrote:
> > this fix is in 4.2.19 (just released).
> >
> >> Actually, I was thinking of getZDimensionIndex(), but use whatever you
> >> think is the best way to determine if a grid has Z or not.  I don't have
> >> a way of compiling the tds code, so please make sure this works. ;-)
> >>
> >> On 1/4/11 9:49 AM, Unidata THREDDS Support wrote:
> >>> ok great, ill apply it. im guessing you mean
> >>>
> >>> if (grid.getZDimension().getLength()>= 0)
> >>>
> >>> ??
> >>>
> >>> thanks
> >>>
> >>>> John-
> >>>>
> >>>> Here's a proposed patch for GridPointWriter:
> >>>>
> >>>> ### Eclipse Workspace Patch 1.0
> >>>> #P njtrunk
> >>>> Index: tds/src/main/java/thredds/server/ncSubset/GridPointWriter.java
> >>>> ===================================================================
> >>>> --- tds/src/main/java/thredds/server/ncSubset/GridPointWriter.java
> >>>> (revision 12922)
> >>>> +++ tds/src/main/java/thredds/server/ncSubset/GridPointWriter.java
> >>>> (working copy)
> >>>> @@ -225,10 +225,19 @@
> >>>> continue;
> >>>> }
> >>>>
> >>>> -            GridAsPointDataset.Point p = gap.readData(grid, date,
> >>>> zCoord, qp.lat, qp.lon);
> >>>> +            GridAsPointDataset.Point p;
> >>>> +            if (grid.getZDimension()>= 0) {
> >>>> +                p = gap.readData(grid, date, zCoord, qp.lat, qp.lon);
> >>>> +            } else {
> >>>> +                p = gap.readData(grid, date, qp.lat, qp.lon);
> >>>> +            }
> >>>> latData.set(p.lat);
> >>>> lonData.set(p.lon);
> >>>> -            if (grid == useForZ) zData.set(p.z);
> >>>> +            if (grid == useForZ) {
> >>>> +                zData.set(p.z);
> >>>> +            } else {
> >>>> +                zData.set(0);  // maybe NaN?
> >>>> +            }
> >>>> mdata.setDouble(mdata.getIndex(), p.dataValue);
> >>>> }
> >>>> w.write(stnName, date, sdata); // one structure per time
> >>>> step per vertical level
> >>>>
> >>>> which will return values for the 2D grid, regardless of the level 
> >>>> selected.
> >>>>
> >>>> Don
> >>>>
> >>>>
> >>>> On 1/3/11 5:32 PM, Unidata THREDDS Support wrote:
> >>>>> This is a problem where the ncss is not smart enough to realize its a 
> >>>>> single level, and so can use a station representation. so it uses a 
> >>>>> profile representation because its a 3D field. Plus you cant mix 
> >>>>> station and profile. anyway ill put it on the todo list, but i wont get 
> >>>>> back to it until next month.
> >>>>>
> >>>>>> John/Ethan-
> >>>>>>
> >>>>>> I'm trying to get gridded data at a point using the form at:
> >>>>>>
> >>>>>> http://motherlode.ucar.edu/thredds/ncss/grid/fmrc/NCEP/GFS/CONUS_80km/files/GFS_CONUS_80km_20110103_1200.grib1/pointDataset.html
> >>>>>>
> >>>>>> I'd like to select some 2D variables as well as 3D variables (SLP and
> >>>>>> 500 hPa vars).  When I do this (set the level to 500), the 2D variable
> >>>>>> ends up being NaN.
> >>>>>>
> >>>>>> I understand the caveats of selecting the same variable with different
> >>>>>> vertical coordinates, but it seems like 2D variables should be returned
> >>>>>> regardless of the level(s) selected at that point.
> >>>>>>
> >>>>>> Also, it seems like the data are being returned with profile info:
> >>>>>>
> >>>>>> int firstProfile(station) ;
> >>>>>> firstProfile:long_name = "index of first profile in
> >>>>>> linked list for this station" ;
> >>>>>> int numChildren(profile) ;
> >>>>>> numChildren:long_name = "number of children in linked
> >>>>>> list for this profile" ;
> >>>>>> int numProfilesTotal ;
> >>>>>> numProfilesTotal:long_name = "number of valid profiles" ;
> >>>>>> int firstChild(profile) ;
> >>>>>> firstChild:long_name = "record number of first obs in
> >>>>>> linked list for this profile" ;
> >>>>>> char time(profile, time_strlen) ;
> >>>>>> time:long_name = "ISO-8601 Date - time of observation" ;
> >>>>>> int station_index(profile) ;
> >>>>>> station_index:long_name = "index of parent station" ;
> >>>>>> int nextProfile(profile) ;
> >>>>>> nextProfile:long_name = "index of next profile in
> >>>>>> linked list for this station" ;
> >>>>>> int profile_index(record) ;
> >>>>>> profile_index:long_name = "index of parent profile" ;
> >>>>>>
> >>>>>> when this should be station data.  Or am I misreading this?
> >>>>>>
> >>>>>> Don
> >>>>>> --
> >>>>>> Don Murray
> >>>>>> NOAA/ESRL/PSD and CIRES


Ticket Details
===================
Ticket ID: RVU-583307
Department: Support THREDDS
Priority: Critical
Status: Closed