[netCDFJava #QBC-740297]: Potential bug in aggregation with timeUnitsChange="true"

Roland,

I spoke with John a little more about what you are proposing...and I 
still have to recommend against pursuing the nested aggregations.  I 
don't think separating the NcML into three files will help, either. I 
asked him about fmrc, and he thought this might work, but really we are 
hoping to move this sort of problem into our feature collections.  While 
NcML works in array index space, feature collections work in coordinate 
space, which eliminates a lot of the headache surrounding unions and joins.

-Lansing

On 12/18/2013 11:14 AM, Roland Schweitzer - NOAA Affiliate wrote:
> New Client Reply: Potential bug in aggregation with timeUnitsChange="true"
>
> Well, indeed the nested aggregations are complex, but they are very handy.
>
> All of this build-up that has led to the report you have now is in
> preparation to add yet another layer of aggregation to build a 5
> dimensional data set that includes an ensemble axis.  Without the ability
> to build the aggregation of aggregations I don't know of any good way to
> organized a collection into a ensemble so we can standardize access across
> of the different clients that we'd like to use.  Otherwise we're stuck with
> sort of adhoc methods understood by each client.
>
> While, I appreciated the automated building of the aggregations, I'll note
> I was able to build a perfectly fine aggregation by defining the time axis
> myself. So if you're looking for feedback, while I love the automation, I'm
> perfectly willing to do more work if you need to require it in order to
> reduce the complexity of your code (and possibly increase the performance
> by defining more in the XML).
>
> Would it matter/help if we built the aggregation of aggregations in 3
> separate NCML files using the TDS URL of union as input to the time
> aggregation (with the time axis defined in NCML) and then URLs of the time
> aggregations at input to the ensemble?  This a opposed to building nested
> NCML.
>
> Roland
>
>
> address@hidden> wrote:
>
>> Hi Roland,
>>
>> Thanks for sending me back on the axis.  At first blush, the time
>> coordinate looks correct in the aggregated file because the numbers are
>> nicely sequential.  Going back into the original files shows the offset,
>> which I hadn't caught.
>>
>> Sadly, nested aggregations have become too unwieldy to manage.  They end
>> up being slow and prone to bugs.
>>
>> -Lansing
>>
>> On 12/18/2013 10:04 AM, Roland Schweitzer - NOAA Affiliate wrote:
>>> New Client Reply: Potential bug in aggregation with
>> timeUnitsChange="true"
>>> Lansing,
>>>
>>> Thanks for the reassurance that you are tracking the problem.
>>>
>>> I would note in your last comment in Jira, the the time axis is in fact
>> not
>>> correct. It's shifted by 13 days. At least that's the case on my server.
>>> And yes, the bounds variable is not being treated by the aggregation at
>>> all.  This was discussed here:
>>>
>> http://www.unidata.ucar.edu/mailing_lists/archives/thredds/2012/msg00015.html
>>> I'm not sure what you mean that "nested aggregations won't figure
>>> prominently in the solution".  Do you mean that you won't allow this sort
>>> of aggregation in the future?
>>>
>>> Thanks,
>>> Roland
>>>
>>>
>>> address@hidden> wrote:
>>>
>>>> Hi Roland,
>>>>
>>>> I've been watching the discussion over e-mail, and I've actually already
>>>> reproduced the behavior you are seeing.  Unfortunately, nested
>> aggregations
>>>> get very complicated, and we're thinking about how to handle situations
>>>> such as yours in the future.  I suspect that the nested aggregation
>> won't
>>>> figure prominently in the ultimate solution.
>>>>
>>>> In the meantime, I've moved your support question over to JIRA, our bug
>>>> tracking system.  You can watch it's progress here:
>>>>
>>>> https://bugtracking.unidata.ucar.edu/browse/TDS-514
>>>>
>>>> Regards,
>>>>     Lansing Madry
>>>>     Unidata
>>>>     Boulder, Colorado
>>>>
>>>> Ticket Details
>>>> ===================
>>>> Ticket ID: QBC-740297
>>>> Department: Support netCDF Java
>>>> Priority: Normal
>>>> Status: Open
>>>>
>>>>
>>>
>>> Ticket Details
>>> ===================
>>> Ticket ID: QBC-740297
>>> Department: Support netCDF Java
>>> Priority: Normal
>>> Status: Open
>>> Link:
>> https://www.unidata.ucar.edu/esupport/staff/index.php?_m=tickets&_a=viewticket&ticketid=23154
>>
>>
>>
>> Ticket Details
>> ===================
>> Ticket ID: QBC-740297
>> Department: Support netCDF Java
>> Priority: Normal
>> Status: Open
>>
>>
>
>
> Ticket Details
> ===================
> Ticket ID: QBC-740297
> Department: Support netCDF Java
> Priority: Normal
> Status: Open
> Link:  
> https://www.unidata.ucar.edu/esupport/staff/index.php?_m=tickets&_a=viewticket&ticketid=23154



Ticket Details
===================
Ticket ID: QBC-740297
Department: Support netCDF Java
Priority: Normal
Status: Open