Hi Martin, hi list
we had a meeting here at NURC last monday with the guys from USDA - FireLab, Bryce Nordgren and Meghan Salmon. We spoken about many issuses and guesses on the GeoTools Rasters and GeoServer WCS side and we made some plans for the near future pointing out several common needs and establishing a sort of common work-plan.
Very soon Bryce will create a wiky page describing in detail all the things we discussed about.
The basic point is that both of us really need some very important improvements to the Coverage part of GeoTools in order to go on with our work.
Me and Simone have a lot of un-committed code here in our lab that can be very very useful to the Raster improvement including the support for other kind of gridded data Formats (HDF-EOS for instance) and many enanchements to the existing ones.
Unitl now we could not commit the code because it requires several important changes to the basic structure of the Coverages, for instance we have made some changes to the GridGeometry in order to make it consistent with the Coordinate Reference System and we plan to change a bit even the Envelope classes.
We know that the Coverage future should be ISO-19123, but we think that if we do a very good work with the existing classes, trying to inspect all the problems and the advantages of some choices the porting will be really "light" and less time expensive.
In our plans there is for esample the time and third dimension support and e better integration of the coverages with JAI.
So ... we think that may be very useful to split (temporally or not ?) the GeoTools Raster package from the main package (something similar to the Referencing package) in order to let us work more easily on that without breaking the main build. Meybe we can create a sort of raster-branch on GeoTools with the splitted coverages where to commit all the code and made some experimentation.
But the very important thing for us is that we absolutely don't want to be de-synchronized from the GeoTools trunk release, this is one of the main reasons a split can be useful.
We would like to know what do you think about that and if our proposal is acceptable for you and, obviously, any kind of comment and suggestion.
Cheers,
Alessio.
