That's fine. The problem with "interesting work" in the coverage module is that little of it gets out to the wider user community.
On 16 April 2011 19:21, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > On Sat, Apr 16, 2011 at 10:08 AM, 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. > > I see. I have a hard time relating to an effort > that does not aim to go end to end from the start. > If I can read, manipulate, process and write back I can see a usefulness, > if it's just API research on in memory coverages hum... let's say that > while I see the value in it, it also leaves me cold. > Also feel that the API will prove itself only once it can go end to end. > But yeah, one has to start somewhere... > >> 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. > > The other half of interesting API work is Simone's work on CoverageStore, > the idea of a coverage source that can read and write multiple grids instead > of > just one, which is actually the one point in current coverage system that is > really really bugging me (1 source <-> one coverage relationship). > I guess I managed to live with GridCoverage2D but never accepted this > I/O limitation. > > Maybe you can steal some pages from there or thing about bridging the > two when you start working on I/O? Just a thought. > > Cheers > Andrea > > -- > ------------------------------------------------------- > Ing. Andrea Aime > GeoSolutions S.A.S. > Tech lead > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > mob: +39 333 8128928 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ------------------------------------------------------- > ------------------------------------------------------------------------------ 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
