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