This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> Yuan, > > Thanks for the response. > > So the problem is not that we have the 3rd dimension, but rather the problem > is that it does not have a CF-compliant name associated with it - right? > Then other than using a kluged name, there is no way to get these files to > work with IDV? you are right. > > That could be an obstacle for us. Since we are generating an official > dataset that will be going into a NASA archive, we probably don't want to use > a name that would be misleading, such as "ensemble". I gather > characteristics of satellite data may not be too well supported yet, since > pass direction is a pretty fundamental concept. > I would suggest that you create different dataset with the attribute to define the direction, this will make it easier. I also like to see what the netcdf group will recommend. Yuan > We will be interested to hear what the netcdf folks have to say. I assume > there must be a procedure to suggest new terms to be adopted into the CF > nomenclature, right? Is that worth pursuing or is the timeframe involved too > lengthy? > > thanks > > Ken > > > > > On Oct 3, 2011, at 2:32 PM, Unidata IDV Support wrote: > > >> IDV Folks, > >> > >> We are are the verge of converting several existing datasets from a > >> previous proprietary binary format into (hopefully) CF compliant netCDF to > >> make the data more accessible to the wider Earth science community. Part > >> of our conversion process has been to test the new formatted data with the > >> various tools that support netCDF. IDV is an obvious choice, and we ran > >> into a hiccup with that testing. We have two main types of satellite data > >> sets across several different platforms: (1) a composite of each day's > >> swaths, and (2) a 3-day average of the same data. The structure of both > >> data sets is nearly identical, with the exception that the daily composite > >> (1) has an array of "pass direction" flags, so each parameter has an > >> ascending and descending view. > >> > >> Both of these data sets (daily and 3-day) seem to be handled fine by other > >> tools, i.e. panoply, but we have a problem with the daily files when > >> attempting to read them with IDV. IDV complains that it cannot find any > >> gridded data and (apparently) fails to open the file. Our best guess is > >> that the "pass direction" array is causing the problem, but based on our > >> interpretation of the documentation for both netCDF and IDV, the structure > >> we have created should be correct. > >> > >> We would like to get this resolved before starting the conversion of these > >> datasets at our repository - the Global Hydrology Resource Center (GHRC) - > >> a NASA DAAC. We would really appreciate it if you could review the linked > >> files and give us a read on if we are doing something wrong or if this is > >> a problem for IDV. If it is our problem, we would like to fix it before > >> our conversion effort. If it is IDV's problem, then we can go ahead with > >> our conversion and hope it gets resolved. > >> > >> At the links below, is one example of both the daily composite and the > >> 3-day average. We are using the Java netCDF 4 libraries to create these > >> files, which as we understand it generates netCDF-3 output. A little > >> confusing, but that is what we understand from the documentation. > >> > >> Daily > >> http://www.itsc.uah.edu/~keiser/projects/DISCOVER/netCDF/IDV_test/f13_20090101v7.nc > >> > >> 3-Day average > >> http://www.itsc.uah.edu/~keiser/projects/DISCOVER/netCDF/IDV_test/f13_20090101v7_d3d.nc > >> > >> > > > > Hi Ken, > > I checked these two datasets, the 3-day average is looking good in the > > IDV. The problem with the daily dataset is indeed this additional > > dimension. I don't think there is CF convention to deal with this type of > > dimension. But you do need a variable to go with a dimension. The only > > possible I can think about is to cheat this dimension as Ensemble, see the > > attached ncml file, and this can make this dataset being recognized as grid > > type in the CDM and can be loaded in the IDV. I will transfer this support > > to netcdf-java department to ask for their help. > > > > > > > > Yuan > >> > >> We appreciate any guidance you can provide on this. > >> > >> Ken Keiser > >> ------------------------------ > >> Information Technology and Systems Center > >> University of Alabama in Huntsville > >> email: address@hidden > >> phone: 256-824-6825 > >> > >> > >> > >> > >> > >> > > > > > > Ticket Details > > =================== > > Ticket ID: RTU-584517 > > Department: Support netCDF Java > > Priority: Normal > > Status: Open<f13_20090101v7.ncml> > > ------------------------------ > Information Technology and Systems Center > University of Alabama in Huntsville > email: address@hidden > phone: 256-824-6825 > > > > > Ticket Details =================== Ticket ID: RTU-584517 Department: Support netCDF Java Priority: Normal Status: Open