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