PS. forgive the sloppy "GridCoverage2D split into two" metaphor. I know in reality its already split into many parts (GridGeometry etc) but I just wanted a back of the envelope phrase for the purposes of discussion.
On 16 April 2011 18:08, Michael Bedward <michael.bedw...@gmail.com> wrote: > On 16 April 2011 17:52, Andrea Aime <andrea.a...@geo-solutions.it> wrote: >> I can't imagine a system without it. You sure all of the coverages that >> people are interested into will be created directly in memory? >> Nobody reading an arcgrid or a geotiff file? :-) >> > > Mmm... I think I didn't express myself very well before, or perhaps > we're talking at cross purposes (or maybe my thinking is just too > muddy at the moment). > > When you asked about bridges I wasn't thinking about I/0. As I > mentioned (again not very clearly) to Jody, I have been deferring that > in favour of starting with those API elements that address questions > on the user list that I have seen crop up more than once, at least > those I remember. > > When it comes to IO I have thought to steal the concept of > RasterAccessor class from JAI. As you know, that class is used in some > image operators to shield the op from the fiddly bits of the > underlying image format / color model etc. I though we could > generalize on that theme by having a GridDataSource interface > (hopefully with a better name) that takes care of handling data > requests for locations, expressed either in world coordinates or > zero-indexed grid coordinates, and knows how to retrieve the data from > the underlying data source. Imagine GridCoverage2D split into two: one > part that handles transforming coords and getting values from a > backing image (= a class implementing GridDataSource) and the other > part being the front window of the grid coverage. So accessing a > geotiff would be handled by a class implementing GridDataSource and > yes, that would be a wrapper for components in gt-coverage. > > These questions are the sort of feedback that I'm looking for. I > should say that I am not determined to have a simplecoverage module in > GeoTools at all costs :) Rather I'm trying to decide, with the help > of all here, whether the idea is of any worth. > > Michael > ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
