Hello Tisham, Thanks for your message which I'm forwarding to the developers' list.
You're correct that I was talking about Number objects. I'm not proceeding with this proposal for various reasons, one of which is an embarrassing backlog of issues that need addressing in the gt-swing module. However, your interest and suggestions are most welcome and I would encourage you to subscribe to the list to discuss ideas further with the coverage team and other developers. Michael On 18 April 2011 11:59, Tisham Dhar <[email protected]> wrote: > Hi All, > > I am not subscribed to the geotools list, so this is going off list, forward > to list if you see anything interesting. > > By Number I assume Michael is referring to the Java Object level numeric > type - http://download.oracle.com/javase/6/docs/api/java/lang/Number.html . > > We work in N-D grids and our coverages underneath are not simple, but we > would like a simple interface for sure. The API we are used to is the NetCDF > common data model - http://www.unidata.ucar.edu/software/netcdf-java/CDM/ . > NetCDF is attempting to approach OGC simple features model from their side. > > I see this as an opportunity to re-do the Coverage Access API to be less > restricted to 2-D and more intuitive. My aim is to fetch temporal slices > with lat-lon-z extents (data cubes) and render them in 3D. The underlying > data may not be evenly gridded in these co-ordinates, but the API > implementation should take care of regridding it. > > I am happy to discuss further on the list if you feel necessary. I am about > to push for the OSGi bundling and requisite pom.xml modifications on the > Geotools list anyway. > > Cheers, > > Tisham. > > On 04/16/2011 02:08 PM, Jody Garnett wrote: > > +1 From me; good to explore the ideas. > The only one that confused me was the working with Number? > Notes: > - I also put into some thought into the idea a more simple Format plugin > system (but cannot find the wiki page); but I think Simone got further than > me. > - whatnick was asking about this kind of thing perhaps he would be > interested > A question; does your module support its own plugin system for additional > formats to be added? Or does it wrap what is already around in an easier to > use interfaces? > > -- > Jody Garnett > > On Saturday, 16 April 2011 at 1:49 PM, Michael Bedward wrote: > > Hi all, > > For some time I've been thinking about how to ease the pain that some > users experience when coming to grips with GridCoverage2D and its > friends. My impression, based on questions on the user list over the > last couple of years, plus my own learning experience, is that the > coverage module is: > > - needlessly intimidating in the number and complexity of its classes > > - over-burdened with adherence to the OGC grid coverage specification > (doc 01-004) which has been retired by OGC > > - wildly over-engineered for the most common use cases. > > I'd like to propose a new community module: simplecoverage to cater > for the many use-cases that don't require the heavy-duty features > found in the coverage module. Some suggested features and constraints: > > - limited to cases where grid is parallel to the world coordinate axes > (ie. AffineTransform) > - read-only and writable coverage classes > - getters that work with Number rather than primitive types (plus > setters for writable coverages) > - getter methods for both grid or world coordinates (plus setters for > writable coverages) > - grid iterators > > I'd like to keep such a module very simple, something like the > SimpleFeature version of raster land. > > I have some initial sources for the above items which I've been > writing for my own use. They are at a proof-of-concept stage but > probably good enough to play with. > > Please let me know if you think a simplecoverage module is a > worthwhile idea or not. Although we have a low bar for community > modules, the build is already so big that I'm loathe to add anything > that won't be generally useful. > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
