Hi guys,
As you know I've been working on refurbishing the geotools arcsde module to
support more raster formats. In the process, I've found the previous Saul work
invaluable to understand how the arcsde raster api works, started adding
support for some specific formats (16-bit unsigned, 32-bit float, 8bit-u
colormapped) following the initial Saul's design. As a parallel inspiration I
started spiking how to better integrate with JAI. It turned out to be easier
than expected (once I learned a lot, remember I'm a newbie in gce land). In
the end, I refactored a lot of code and come up with a new design, which makes
use of an ImageInputStream implementation that reads arcsde tiles and is
wrapped by a RawImageInputStream.
So far so good, we have now a single raw arcsde raster format reader to rule
them all.
So, I would like to kindly ask you to answer a couple questions, before I go
forward in wraping up the work and backporting to 2.5.x.
- Saul: what is the intended use of the LZERO_ORIGIN_TILE parameter? I would
need to check if it still applies.
- All: I would love a concept check on the following explanation of the new
workings of the module, and even a bit of a code review would be highly
appreciated. Though there may be still a couple rough edges, I think I could
make good use of your higher experience with gce to early catch on conceptual
missunderstandings or technical mistakes.
* How it used to work:
Given a read request to the GT arcsde AbstractGridCoverage2DReader
implementation:
1- connect to the raster table and gather raster layout and metadata
information
2- create a BufferedImage compatible with the raster format, backed by the
appropriate colormodel and samplemodel, and with the requested dimensions.
Fail if there's no support for the raster's format and number of bands.
3- find out the most appropriate pyramid level to fullfill the requested
extent and image dimension, as well as the matching tiles.
4- look up for a specific ArcSdeRasterReader(tm) for the given pixel depth
and number of bands.
5- start fetching the raster tiles, for each tile, pass it to the
ArcSdeRasterReader, together with the target BufferedImage's WritableRaster and
the offset and band where to write the tile's content. The reader takes care of
writing only the samples that match the target extent.
6- create and return the coverage backed by the BufferedImage. It matches
exactly the requested extent and image size.
* How it works now:
Given a read request to the GT arcsde AbstractGridCoverage2DReader
implementation:
1- Gather the raster layout and metadata. It is cached so fetch it if not
yet available. It contains the raster dimensions, band, and pyramid info.
2- use the OVERVIEW_POLICY argument to determine the most appropriate
pyramid level, default to QUALITY if not provided. This leverages the code in
AbstractGridCoverage2DReader.setReadParams to select the overview (ie, pyramid
level)
3- based on the requested extent and pyramid level, calculate the matching
tiles that overlap the requested extent for the selected pyramid level, as
well as the resulting image size and extent. This may well be different than
the requested extent and image dimension, but we're going to return the native
resolution and only the matching pixels, letting the client code deal with
interpolating if needed.
4- If the request does not match the raster extent, create a zero area
image, and return a null extent coverage. Otherwise create an
ArcSDEImageInputStream to fetch the raw byte[] data for the whole matching
tiles, and call the JAI ImageRead operation with an appropriate
ImageTypeSpecifier and ImageLayout.
5- since the read image contains an area covered by full tiles, use the JAI
crop operation to crop it to the image dimension that better match the
requested extent.
6- create and return the coverage backed by the actual RendedImage and
resulting extent, in native (pyramid level) resolution.
Tha's quite it. Any comments will be appreciated.
--
Gabriel Roldan
OpenGeo - http://www.opengeo.org
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
