On Thu, Jan 31, 2019 at 8:32 AM Andrea Aime
wrote:
>
> If I understand correctly, what you did is normal lazy loading, once a
> coverage is loaded, it stays in memory, you're just avoiding up front
> loading...
> meaning that during encoding all coverages end up being loaded in memory.
>
>
This
On Thu, Jan 31, 2019 at 3:22 PM Daniele Romagnoli <
daniele.romagn...@geo-solutions.it> wrote:
> (It has been developed 10 years ago so there might be the case that at
> time the immediate read was solving some issues occurred with deferred
> loading).
> Since you already started playing with
Hi Clifford,
ImageMosaic allows to select between immediate read (in memory) and
deferred read whilst as far as I remember the pure NetCDF store internally
uses immediate mode.
However, I think that ImageMosaic has never been tested before against
NetCDF aggregations (whilst it has been used with
I haven't tried the latest RC, I believe we are using 2.14 at the moment,
so I will check it out (if memory usage is improved I will do backflips).
The store is NetCDF, and in particular NetCDF aggregations using the
NCML/FMRC XML formats (this prevents making use of the Direct Download
feature
Hi Clifford,
I have a couple of questions on your use case for some feedbacks:
1) which GeoServer version are you using? (did you already tried with the
latest RC?)
2) which store are you using to configure your input data? Is it a NetCDF
store OR an ImageMosaic one?
Please,
let us know.
On Tue,
I've run into a problem with the memory footprint using the netcdf-output
plugin with n-dimensional datasets. Consider a WCS 2.0.1 request that
wants multiple times and elevations in netcdf format. The WCS GetCoverage
operation slices this request into 2D slices, and loads these slices into a
