That is too bad Micheal;
I was hoping to tag along with you on the design side of things. As you can
tell there are a lot of frustrations around the coverage
side of things - and I think you got feedback from all ends of the spectrum?
For me there is a disconnect between the theory expressed in coverage
(RecordType / Category) which I understand at an information modeling point
of view.
* Record is very much like a C++ struct
* Category is very much like a bit mask allowing me to pull bits out of
longer byte array and use those to represent a specific value (maybe an
Enum, or Float)
However when it comes to sample the values out of a coverage -- that
information seems to be lost to me?
Forgive me if this discussion is exactly why you would like a simple grid
coverage ....
Jody
On Mon, Apr 18, 2011 at 12:56 PM, Michael Bedward <[email protected]
> wrote:
> 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
