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
>
>
