Just going to chime in with a second reply. I am in favour of experimenting in
an unsupported module.
However I would still like to see what we have there documented; out of all the
docs the stuff for gt-coverage had the highest noise to signal ratio.
Indeed I would expect that these docs are largely responsible for the high
number of confused questions; even after my rewrite they still basically tell
people they need to go home and study what an affine transformation is and then
apologise for raster != coverage.
--
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
> Geotools-devel@lists.sourceforge.net
> 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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
