Dear All (ok, especially Michael :) ), here is what I would say, start dropping what you have done under spike, so that we can start looking at it as well as discussing about it.
We have done quite some work in order to replace parts of the GridCoverage packages, although a lot could be done. Doing that alone is a huge effort, if someone else with experience like you participate I think we could come up in time with something simpler/better, so, please, share somehow what you are doing then i think collaboration will forster accordingly likewise for jai-tools. What do you think? Regards, Simone Giannecchini ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder 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/simonegiannecchini http://twitter.com/simogeo ------------------------------------------------------- On Mon, Apr 18, 2011 at 6:56 PM, Justin Deoliveira <jdeol...@opengeo.org> wrote: > To chime in with some thoughts. One of the things on the long term radar for > geoscript is to provide raster data access. And since one of the major goals > of geoscript is to simplify geotools apis the two would seem to be inline. > Now i am not advocating for this to be done in geoscript or even to be > implemented in not pure java, but i wonder if the same approach could be > taken. That is implement the new simple api at a higher level that wraps the > old api. It would have the benefit of continuing to maintain a single raster > "chain" (for lack of a better term) and also make it less risky for users > migrating to the new api since it is still backed by the old code. > 2c. And apologies if the idea is totally out of scope with that you are > thinking Michael. > > On Mon, Apr 18, 2011 at 8:12 AM, Jody Garnett <jody.garn...@gmail.com> > wrote: >> >> 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 >> <michael.bedw...@gmail.com> 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 <whatni...@gmail.com> 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 >>> > 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 >> > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
