Jody Garnett wrote: > Saul this API (ImageReaders) kind of is what you want to make it to be;
Not quite sure what you mean here...do you mean that the javax.imageio.ImageReader class (the ImageReader I'm referring to below) is an open-ended enough API that one can write a new ImageIO plugin (an ImageReader subclass) in any number of ways? Or do you mean that the API as defined in modules/coverage (I think you referred to it as GCE below) is open-ended enough that making a new reader/format is kind-of amorphous? > > I have proposed an alternative DataAccess thing with an eye towards > rasters, but currently most applications are skipping GCE and making new > Formats directly. I would personally try and stuff as much information > into the Format as possible and then create a Reader as needed. What do you mean when you say "skipping GCE"? I'm not sure I know what GCE is if it's not the creation of a Format, Factory and Reader (by extending AbstractGridFormat, AGFFactory and AbstractGridCoverage2DReader). Is there another way of creating a coverage plugin? Is that GCE? As for "create a reader as needed" I'm a little confused by that. It could mean: 1) "create a concrete subclass of AbstractGridCoverage2DReader as needed" I'm not sure I get to make a call on this, as geoserver simply creates one GridCoverageReader for each configured coverage and then calls "read(extent, imagesize)" each time it wants a coverage image. I don't really get to choose when to create a GridCoverageReader, I just have to return a "long-lived" one. 2) "create a concrete subclass of javax.imageio.ImageReader as needed" This is one I get to make a call on, but I'd really like (for simplicity's and sanity's sake!) to make exactly one of these for each AbstractGridCoverage2DReader that's created. The question is whether there's something in the superclass that would prevent me from doing this...since AbstractGridCoverage2DReader is threadsafe (and commonly called from a multi-threaded context) then this would mean that my javax.imageio.ImageReader subclass would need to be threadsafe as well. I can guarantee this within my OWN javax.imageio.ImageReader.read() method but I can't necessarily guarantee it within the general ImageReader class. The javadocs caution USERS of ImageReader plugins to not assume that a given ImageReader is threadsafe, but as I'm implementing my own and I know that *my* code is threadsafe...I wonder if I can assume that I'm allowed to use my own object in a threaded context. Hmm...I'm not sure I could have explained #2 in a more complicated way, but hopefully it got through! > > For the information that varies *all* the time we should make sure that > that is passed in as an object (or array of objects) to your read method. I hadn't realized there was more than one way of creating a raster plugin to geotools, but just to clarify, I was really asking about implementation strategies as they concern the (confusingly similarly named!) javax.imageio.ImageReader and javax.imageio.spi.ImageReaderSpi and their interaction with the JAI imageio->PlanarImage operator "ImageRead". My question was really about imageio and JAI, not so much geotools So are we talking about the same thing? Thanks jody! --saul > Jody > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
