Hi Everyone,
I have changed my mind on this other aggregation issue I discussed in
one of my emails (see below), I said it was unrelated to netcdf-java but
it doesn't seem to be the case. Well, I really want to hear your
opinion. The issue is related to the order of files listed for aggregations.
I have found that the issue lies in part with geotools, because it is
making certain assumptions about time variables being increasing rather
than decreasing. Convention does demand that a variable is either one of
the two (but not in random order).
The question is whether the list of files in an .ncml files should also
be in a certain order. It seems that netcdf-java (which does the actual
aggregating of the variables) follows the order from the ncml code. That
means that the values inside the aggregated variable may end up in
random order.
For example, assume you have two files.
One has time values 1,2,3. The the other one has 4,5,6.
If we now place them in opposite order in our .ncml file, netcdf-java
appears to create an aggregated variable with values 4,5,6,1,2,3
In that case, geotools cannot even assume that the extremes are on both
ends of the list, which is IMO faulty and can cause many issues with
other assumptions in the code.
Have I found something here, or do you disagree? Thank you for responding.
Should we just demand from users to place the list of file sin the same
order as the order of values inside the .nc files
(increasing/decreasing)? is that (un)reasonable?
Kind Regards
Niels
On 08-09-16 14:51, Niels Charlier wrote:
3. changing the order of the list of files in the inner aggregation tags.
<netcdf location="hycom_glb_regp01_old_t003.nc"/> <netcdf
location="hycom_glb_regp01_old_t000.nc"/>
instead of <netcdf location="hycom_glb_regp01_old_t000.nc"/> <netcdf
location="hycom_glb_regp01_old_t003.nc"/>
Otherwise the one with the earliest time coordinates is last in the
list instead of first... and geotools fails on this. Is this normal?
This issue is definitely unrelated to netcdf-java, but I am not
sure whether this is a bug in geotools or in the .ncml file.
