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
