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? - 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. 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 - if ColorMap is defined at the GeoAPI level (is it?) it is the kind of integration issue that should be discussed on that list. - 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. The obvious fix is to make ColorMap a Function in the GeoAPI sense; the intension is the same - and I have an implementation on trunk showing that it is possible to make the function. What are your thoughts on the Eclesia? I went over ColorMap, Categorize and the raster Category APIs on the GeoAPI list; did we come to any resolution? > Of course you know more about thechanges than I do, so is there anything > else that might break existing functionality? > 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. 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? > One final curiosity is about the parsers and encoders for SE 1.1/SLD 1.1. > This is quite of a natural extension for a set of concepts defined in an XML > schema. Do you have any plans on working on them, or > are you going to persist your styles with some other means? > This time it better not be JaxB :-) I think Eclesia's short term goals involve making these interfaces available at all; so while I am concerned about this one it would not effect my vote. The longer term plan for styling should of a have this work... Jody ------------------------------------------------------------------------- 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
