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