Seems like updating the behavior of every coverage reader implementation
might be tough. Might be better to just check for null in CatalogBuilder
itself and apply any workaround there. That seems to jive well with the
nature of that class.
2c.
-Justin
On 3/23/10 11:25 AM, Gabriel Roldan wrote:
> Hey all,
>
> I'm running into a bit of API consistency hunting wrt handling null
> return values for GridCoverageReader.read in general and its use in
> CatalogBuilder in particular.
>
> API wise, it'd be enough for AbstractGridCoverage2DReader.read to state
> null is a valid return value. So far it only says "@return a {...@linkplain
> GridCoverage grid coverage} from the input source."
>
> That's alright, all over the place the norm is whenever you call read,
> you might get null. What is not that clear is in which situations that
> could happen. If the requested envelope is outside the coverage
> envelope, then returning null is alright. But what if you have a mosaic
> with sparser data and hence a requested envelope, even if inside the
> coverage bounds, overlaps no raster in the mosaic? I would say it's
> equally fine to return null instead of a fake coverage?
>
> Now, my problem with CatalogBuilder, is that its buildCoverage method
> reads a test coverage accounting for the 4x4 bottom left pixels or so,
> and if the reader returns null it throws an exception. Problem with that
> is that it doesn't let me configure a raster mosaic (from ArcSDE) where
> that corner has no raster (the mosaic is irregular, does not form a
> rectangular shape).
>
> So question is what to do in that situation. We could either require
> coverage readers to return something, even a fake coverage, iif the
> requested envelope overlaps the coverage's original envelope, or we
> could fall back in CatalogBuilder to read the whole coverage if that
> little optimization returned null. Opinions?
>
> Cheers,
> Gabriel
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
