Sean, Ben,
Isn't issue #2 related to the lack of support for two-dimension
coordinate variables that the client talked about with regards to the
runtime aggregations?
Sorry if I am stating the obvious here, I have only been learning while
working on this.
I did not fully comprehended the relationship between the two issues at
first. But reading back my description of what goes wrong in the code,
it all starts with the time variable not being recognised as an axis
because of the runtime dimension being added to it as a second dimension.
Still, the aggregation works fine if I leave out the time variable. I am
still not fully understanding how its presence as "variableAgg" affects
the end result. I don't see any examples online where axis variables are
included as variableAgg. This isn't exactly clear to me. Please
enlighten me on that point.
Kind Regards
Niels
On 09/08/2016 02:51 PM, Niels Charlier wrote:
2. 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.
