I am mostly happy with this, even though... see below... ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy
phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo ------------------------------------------------------- On Fri, Apr 9, 2010 at 1:47 PM, Daniele Romagnoli <daniele.romagn...@geo-solutions.it> wrote: > Hi list, > these days I'm working on the ImageMosaic module (2.6.x) as well as JP2K and > I'm also working on aligning the gt-imageio-ext-gdal logic to the > ImageMosaic's one (leveraging on the same concepts introduced by Simone on > the mosaic). > I have noticed that there are several Utility methods in some modules which > could be surely exposed once in a common Utilities class. > As an instance (... from javadoc): > > - boolean checkEmptySourceRegion(final ImageReadParam readParameters, final > Rectangle dimensions): > Checks that the provided <code>dimensions</code> when intersected with > the source region used by the provided {...@link ImageReadParam} instance > does not result in an empty {...@link Rectangle}. > > - boolean checkFileReadable(final File file): > Checks that a {...@link File} is a real file, exists and is readable. this one should be moved to DataUtilities or anywhere where it would be available to everybody not just coverage. > > - ReferencedEnvelope getReferencedEnvelopeFromGeographicBoundingBox(final > GeographicBoundingBox geographicBBox): > Builds a {...@link ReferencedEnvelope} from a {...@link > GeographicBoundingBox}. > this should move to maine somehow, or to the ReferencedEnvelope class itself > - ImageReader getReader(final ImageInputStream inStream): > Look for an {...@link ImageReader} instance that is able to read the > provided {...@link ImageInputStream}, which must be non null. > > ... and other similar methods. As you may see they are mainly involved in > coverage/image I/O. > Therefore, I would like to create a GridCoverageUtilities helper class with > all of them as static methods, as an instance in the coverage module under > "org.geotools.coverage.grid.io" package. Notice that there is already a class called CoverageUtilities, I would make use of it before creating a new one. Simone. > > What do you think about it? In case this sounds good, I will open a JIRA > where I will also provide a list of added dependencies although, actually, > only commons-io would be added. > > Please, > let me know. > > Daniele > > > > ------------------------------------------------------- > Eng. Daniele Romagnoli > Software Engineer > > GeoSolutions S.A.S. > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 328 0559267 > > > http://www.geo-solutions.it > > ------------------------------------------------------- > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > ------------------------------------------------------------------------------ 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 _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
