NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hello,I am currently working on the netcdf extensions of geotools/geoserver, although I should say I am fairly new at netcdf, so I am still learning. I am currently trying to get some particular datasets to work with geoserver, and I think I might have hit against some limitations, perhaps even a bug, in netcdf-java, so I wanted to ask you for advice.
We have a .ncml have that aggregate datasets based on 'runtime'. This is an explanation from the client:
/"'runtime' is not a first class coordinate in the data produced by our production groups, so the initial approach to solve this using unidata mechanisms is to use NCML to aggregate // //two datasets with different runtimes together using a 'joinNew' aggregation, which adds a new coordinate axis 'runtime' to the dataset // //(this takes place in several of the .ncml files included in the test data). The runtime axis would then be exposed as a custom dimension in geoserver so that it can be used for subsets. This means that a reader would have to be prepared to handle dimension values that are possibly two dimensional(a set of values for each available 'runtime'), which I don't think the current reader can handle? "/
My first question is what it would entail for building support for this in netcdf-java? In the meantime I have been extensively debugging what happens when I try to load the aggregation file, and I can give some detailed information about what goes wrong in the code. I think I might have found something else that is going wrong.
* as part of the aggregation, the runtime dimension is being added to every other variable of each of the .nc files.
* During *CoordSysBuilder.buildCoordinateSystems* some things happen as a consequence of that that is different from when I read the .nc files individually:
-> In *makeCoordinateSystemsImplicit*, as a consequence of all variables having an additional dimension, the CRS with lacking runtime dimension is not considered sufficient and is not being set. -> However, in *makeCoordinateSystemsMaximal* the CRS's are being set, except for one variable called "surf_el", because it is being considered an AXIS (see line 873, call to*!vp.isData()*).
* During index building (*NetCDFImageReader.init -> initIndex -> getCoordinateSystem*), a runtime exception is thrown because surf_el doesn't have a CRS.
The thing is, surf_el is not an axis. The reason it is considered an axis is because it has a "positive" attribute. This happens in *DefaultConvention.findCoordinateAxes -> getAxisType -> getAxisTypeCoards* (see line 297, *positive != null*).
To quote my colleague Ben who I asked advice about this:/"surf_el is a time-varying data variable and not any kind of coordinate. Surface elevation looks to me like an output of the HYCOM ocean model //<https://hycom.org/>//. Any logic that says that a variable is a coordinate if it has attribute "positive"="up" is broken. There is this statement in the CF conventions: //
//// //"A vertical coordinate will be identifiable by: // // units of pressure; or //// the presence of the positive attribute with a value of up or down (case insensitive)." //
//http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html//// //////There are such things as time-varying multidimensional coordinate variables (think of the lat and lon grids for a satellite swathe), but this is not one of these. //
//////I think that, to be a coordinate variable, a variable must be mentioned in the "coordinates" attribute of another variable in the same file, or have a name that matches its dimension (i.e. a basic single-dimensional coordinate variable). "
/ So have I indeed identified a bug here? please advice./ / / / Thank you for your help. Kind Regards, Niels/ / / / //
netcdf-java archives: