On Nov 10, 2017, at 07:27, Fang, Fan (GSFC-610.2)[ADNET SYSTEMS INC] <firstname.lastname@example.org> wrote:
I think I wondered off a bit by the jargons. I realize we probably have been talking about the same thing regarding “user-side aggregation” and level-2 aggregation. The user-side function is in fact the aggregation servlet described in this link, correct?
I tested this one before. The users would need to prepare an ascii file listing all the granule data for subsets. It outputs a zip file containing a list of netcdf files. Yes I agree, although the link mentions swath aggregation, it shall work (though I haven’t tried) for grid data as well. For swath, I also agree that the subsets would not be “regular”, and “aggregating” for one netcdf file would be an ambiguous job methodology-wise (since time is still unique for each swath, we can consider aggregating along time like for grid data, instead of doing spatial aggregation, as one of the probable approaches). If the granules are globally gridded, aggregating into one netcdf file would be conceptually clear, but still quite involved as it would need to find the time variable, determine the values if not available, and combine along the time dimension, all of which the “server-side” NcML handler can already support.
Since the aggregation servlet uses roi() etc., these functions are very important in this “user-side” paradigm, as well as functioning as server-side functions alone. The deficiency for roi() etc. functions not supporting subsetting a 3D+ variable with “height” or “level” or “wavelength” dimensions will become significant. From this point of view perhaps you want to consider sooner the original request I made in this email thread – to support subsetting swath arrays that are >2D with extra “height” or “level” dimensions in the roi() etc. functions?