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