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.
Something I discovered which fixed the error-prone data set I was working with -- I added an units attribute to the time variable and things started to work as expected. My data set contains values for lon/lat points for twelve months but no months in particular, so the values are actually January values, February values, etc. and not exactly fitting with the usual manner of specifying time values with units containing the "<units> ...since mm-dd-yyyy" specification for udunits (looks like I need to learn how to use climatological variables for this data, apparently this is a use case for which that approach is applicable). Once I added a units attribute to the time variable it became visible as a georeferenced data set containing GeoGrids, problem solved. Hopefully this will be helpful information to have in the mailing list archive. How can we best update the documentation to include this information -- is there a Wiki page or how to document for creating georeferenced NetCDF data sets that this can go into (and/or that I should have been following)? --James On Mon, Aug 25, 2014 at 4:34 PM, James Adams - NOAA Affiliate < james.adams@xxxxxxxx> wrote: > Is there a document that outlines the requirements for writing a NetCDF so > that the data contained therein can later be read as GeoGrids and/or > GridDatatypes? For example I want to be able to do this: > > GridDataset gridDataset = GridDataset.open(netcdfFilePath); > GridDatatype gridDatatype = > gridDataset.findGridDatatype("gridded_data_name"); > Array dataArray = gridDatatype.readDataSlice(monthIndex, -1, latIndex, > lonIndex); > > My problem is that I have written data which have lon, lat, time > dimensions and corresponding lon, lat, and time variables, but after I open > the NetCDF as a GridDataset I can't get the data out as a GeoGrid or > GridDatatype. I assume that the issue is that while creating/writing the > NetCDF I've not done something required to make it so that the data can be > read as desired, so I'm looking for a list of requirements I can satisfy > which will make this so. > > The Javadoc is confusing in that the interface > for > > GridCoordSystem mentions > the > following assumptions > : > > X and Y are 1 or 2 dimensional > T is 1 or 2 dimensional. The 2D case is that it depends on runtime. > We can create Dates out of the T and RT coordinate values. > Z, E, RT are 1-dimensional > An optional VerticalTransform can provide a height or pressure coordinate > that may be 1-4 dimensional. > > However > the Javadoc > for the corresponding > > > GridCoordSystem > class > only mention > s t > he > > s > e assumptions > : > > is georeferencing (has Lat, Lon or GeoX, GeoY axes) > x, y are 1 or 2-dimensional axes. > z, t are 1-dimensional axes. > > I have written NetCDF files which don't adhere completely to either of > the above sets of assumptions, however variables contained within those > NetCDF files can be read as GeoGrids/GridDatatypes. It'd be nice to have > some clarity as to what is and is not required to create a NetCDF that can > be treated as a GridDataset containing data that can be referenced as a > GeoGrid/GridDatatype -- can anyone clarify this? > > Thanks in advance for any suggestions or clarification. > > --James > >
netcdf-java
archives: