+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
