CatalogBuilder fails to create the CoverageStore if the subset coverage results in null

Obtaining a full coverage was what the code was doing before this and it blew up any attempt to configure big coverages with obvious OOM.

any other workaround that you can think of? Does that hold true even for readers that do deferred loading of data?

Cc'ing Simone since he's the coverage expert.

If the readers do deferred loading the problem won't happen, but not all readers do and there is no way to tell if the reader is deferred loading capable afaik.

I'm wondering if the behavior of your reader is similar to the one of the other readers though. I understand the image is not regular, but should'nt you return a coverage full of "nodata" values in that case? Not sure. What happens, for example, if one asks for an area that has a hole in it?

What about asking for the full coverage extent with a small grid envelope (say, 5x5 pixels as of today)?
Most formats should cope with that or they won't be able to work by WMS/WCS anyway, right?

>I'm wondering if the behavior of your reader is similar to the one of the other readers though. I understand the
>image is not regular, but should'nt you return a coverage full of "nodata" values in that case? Not sure. What happens,
>for example, if one asks for an area that has a hole in it?

That was part of my question on the mailing list. My understanding is that ImageMosaicReader.read(...) returns null in this case too:

		final Collection<GridCoverage2D> response = rasterManager.read(params);
		if(response.isEmpty())
			return null;
		else
			return response.iterator().next();

I would still love some opinion on an alternative approach for CatalogBuilder though, since returning null seems to be the common practice when the requested extent finds no data (not no-data values, but NO data).
Do we try with random points until finding some actual sample? do we "fix" the coverage readers so that they return null only if the requested bbox does not overlap the coverage's original extent, and in the case of a mosaic with holes, if the requested extent completely lies inside a "hole" they fake a coverage full of no-data values? (seems to make the most sense to me? at least there's some way of specifying the coverage's extent as anything else than a bounding box...)

I would prefer to have the readers fixed, but that would seem a lot of work.
We could go for an heuristics: try with a fixed number of random points inside the coverage (or with a quadtree like grid, increasing density) and if that fails, well, then we try to read the whole coverage at reduced resolution. This will still fail for sparse but very big mosaics but might be an improvement for the common case