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.
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.
Hi Ben, Niels, To answer Ben's question from way back: "Sean, do you expect aggregations to behave the same as single files with the same Conventions? It looks like Niels has identified a difference." Yes, that would be what I expect. However, when the aggregation is done. The difference that Niels notes is a little disturbing. It's also possible that my understanding of the aggregation code and how it works is not quite right. Niels, Is there any way I could get the files you are trying to aggregate to debug locally? We'll get this figured out one way or another, Sean On Wed, Sep 28, 2016 at 7:16 AM, Sean Arms <sarms@xxxxxxxx> wrote: > Hi Niels, > > I apologize for the delay. We've been preparing for our User Committee > meeting (which just finished), and I've been preparing for surgery (this > Friday). I'll be taking a look at this today. I'm not yet totally clear on > what is happening in the code, so it will take some time, but I will focus > on this until it's figured out. If anyone else is interested in digging in > too, that'd be great. > > Sean > > > On Wednesday, September 28, 2016, Niels Charlier <niels@xxxxxxxxx> wrote: > >> Hi, >> >> Can anyone on here please advise whether they think the issue below is a >> fault in the .ncml, in geotools or a fault in netcdf-java? >> I can see exactly what is going wrong in the debugger, but I am not sure >> where the fault lies. >> Really need some help on this one. >> >> Kind Regards >> Niels >> >> On 08-09-16 14:51, Niels Charlier wrote: >> >> removal of the "time" variable in the aggregation (see commented line in >> attached .ncml file) >> >> This issue is related to the previous one, it is again about >> *makeCoordinateSystemsImplicit* versus *makeCoordinateSystemsMaximal*. >> >> * If the "time" variable is included as aggregation variable, it also >> gets the "runtime" dimension added to its dimensions. >> * As a consequence, netcdf-java does not recognise it as an AXIS. >> * As a consequence, *makeCoordinateSystemsImplicit *fails to include >> it in the CRS's for the actual variables (water_u, salinity, etc...). >> * As a consequence, *makeCoordinateSystemsMaximal *creates a CRS for >> these variables. However, it puts the dimensions in the order of the >> *dimension >> variable* list >> (rather than the variable's own dimensions), which is completely >> arbitrary as far as I can see. >> * "runtime" ends up as the last axis instead of the first. This is >> inconsistent with the order of dimensions in the variable. Geotools fails >> on this inconsistency. >> >> I am not sure whether the fault here lies with the .ncml file, >> geotools or netcdf-java. >> >> >>
netcdf-java archives: