Jody Garnett ha scritto: > Andrea Aime wrote: >> The first one is the size of the change. I would like to avoid seeing >> massive change of code in the >> gt2 codebase so close to GeoServer 1.7.x freeze. Can you svn diff you >> changes and post them somewhere? >> If they are really really big I'd prefer to have GeoTools 2.5.x cut >> and have this go on trunk. >> > So we have a bit of a planning question - so the question is: > - Andrea when is the GeoServer 1.7.x freeze?
Eh, good question, we do not have a plan and we failed to discuss it into yesterday's meeting due to too many topics piling up. > - Eclesia when would you like to start committing? > > There should also be room to negotiate here right? Andrea I assume some > things could be worked on now; such as implementing the function list > mentioned by the SE1.1 specification? User guide documentation and so > on? We also must recognize that Eclesia has a group waiting on him to > commit this work ... before they can start working on a renderer they > need the style interfaces locked down. I understand this perfectly, that's why I'm open to other solutions, such as branching out 2.5.x even before an RC is out to accomodate for this particular situation. > Eclesia GeoTools 2.5.0 has a couple gaping QA holes; we covered these > issues in a meeting two weeks ago - can you review the IRC log for that > meeting and we can start a discussion on who can do what when. I would > like to get a handle on when 2.5.0 can be released. >> Same goes for the raster symbolizer related changes. I'm not seeing >> how the getFunction() >> approach is going to replace the ColorMap, can you provide more detail >> on it? >> > The categorization function ISA colormap; we probably can make our > implementation support both interfaces Hem, so ColorMap would return a function, that's a ColorMap? ;) Kidding, you do mean we'd have the function implement the old ColorMap inteface, right? This should make for an easy transition in the code that's using the existing one. > - if ColorMap is defined at the GeoAPI level (is it?) it is the kind of > integration issue that should be discussed on that list. <rant> Oh boy, I suffer the very existence of GeoAPI a lot... why should we discuss stuff there when we're basically the only "serious" implementors of it? I mean, if at least openjump or degree implemented those interfaces, it would make sense... </rant> > - if it is not (ie it is our own geotools class) then we have an > integration problem - SE 1.1 integration with Categorization function > was presented as something to check during the recent raster symbolizer > work. I'm not sure what is the implication here. Do you mean the Geosolutions guy would have to fix their implementation because someone else broke the interfaces? This does not seem fair? > Some changes to the StyleFactory interface will be required; my > understanding is new methods will be added and the javadocs will say > @since SE1.1? I hope we can avoid maintaining the existing StyleBuilder > - but I have not looked at the proposal to see if it offers a replacement. Maybe @since 2.6.0 (gt2 2.6.0) as opposed to the spec itself? Or track the geoapi release if that's part of GeoApi... About StyleBuiler, Eclipse says there are 192 references to that class in the sole GeoTools code base. So if you ditch it, someone will have to fix all usage points as well. > In general its seems pretty clean. Obviously some of the information > captured (say fallback values and the inline graphics) will not be > representable in SLD 1.0 documents. Perhaps we can ask the existing > transform code to write out an XML comment when these constructs occur? I lost you there. I tried to make extra sure we did not lose any functionality, your comment seems to imply otherwise. What are we going to give up with SE 1.1 interfaces, and why? Cheers Andrea ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
