Re: [Geotools-devel] GridCoverages and data stores

[Chris H. <ch...@op...>]

> I have a question for you. I am the only one that thinks that the data
> store and grid coverages does not mix well? Or that the current style
> of wrapping a grid coverage as an attribute in a feature is counter
> intuitive?
> I'd really prefer to have a separate API to access grid coverages from
> the persistent stores, and also to handle them in memory. 
I agree with this, I think a seperate API is appropriate.  We should 
examing The Web Coverage Service spec and GML 3.0's section on coverages 
and see what the OGC thinks.  But yeah, it is different than vector 
features, and should have a different api.  Would be nice to have a common 
abstact DataStore class that they both descended from.


> I also feel that this thing should be changed before the release, since
> there are not that many users of B1, but B2 will be different (we are getting
> stronger both at rendering and at accessing data)...

I disagree with this.  I think we just need to start putting out releases 
more often.  I'd actually like to see us release about once a month, just 
put out what we've got.  None of the core developers can really hit any 
geotools deadlines, stuff gets done when people have time to do it, not 
before, and not after.  We are always going to have stuff we want to 
squeeze into each release, holding things up for others.  By the time 
Martin finishes up the GeoAPI stuff Andrea wants to put in grid coverages, 
by the time that happens I'll want to pause to just wait until I finish up 
filter, and we'll never get it out.  I feel geotools is losing some 
respect for just not putting out releases.  Ideally we'd all put solid 
time in, and come up with all sorts of great demos and package things up 
super nicely.  But none of us really has time for that.  I can do it for 
GeoServer, since I'm directly paid to work on GeoServer.  So I think we 
need to just start putting releases out - the first release got us to 
clean up enough to be reasonable.  Now we should start putting out 
releases so people can track our work.  Perhaps we can aim for beta 5 to 
have lots of nice demos.  Or perhaps we just call that rc1.  We have a 
pretty solid toolkit, and I personally don't think it'd be that bad to 
call it 2.0 pretty soon, and then start working on 2.1 and on.  I'd really 
like to see beta2 out by the end of the month, and I really think all that 
we need for it is a full clean build of all the modules we want to go out.

Chris