Many questions ...
Andrea Aime a écrit : > Hi, > here are a couple of bits about the upgrading styles proposal. > Generally speaking, the proposal sounds nice, and it's going > to introduce some very interesting new functionality, so > I'm favourable, but there are a couple of issues preventing > me from voting +1 on it. > > 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? > I dont have a svn diff to offer, It's a week or perhaps more of work which is not yet done. I made basic implementations of geoapi interfaces in the go module. I guess I could do the work and come back with an svn diff in one week, but if the answer is "no", I'll have lost my time for nothing. > If they are really really big I'd prefer to have GeoTools > 2.5.x cut and have this go on trunk. > > 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 function will be available but all other methods in the colorMap will still be there. Jody wrote the categorize function in the render module : org.geotools.filter.CategorizeFunction You can find an exemple using it in the go module (in the test package): org.geotools.RasterFunction > In GeoServer 1.7.x the raster symbolizer support is one of the > major new features. Who's going to fix the raster symbolizing > code so that it keeps on working after that in the ColorMap > interface? If the previous methods are still here, it should still work. Jody Garnett a écrit : > 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? > I think the interfaces in geoapi should stay like they are, using "Function" and not more precise. In geoTools we should make convinient implementation and provide several methods that offer something really close to the current colormap in geotools. >> 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... > We are using a JaxB solution. What I see is that everyone is fine with the proposal. What I understand now, we do not want to take the risk to upgrade the style classes so close to geoserver and geotools release. I can understand that. But we need a date. I dont know when is planned Geoserver release,same thing for geotools 2.5 . I've told you my deadline a few weeks ago, now I give you a real date : 15 July I must have definitively close the style problem. It means at this date, I must have the styles classes implemented completely in geotools or somewhere else if I have no other choice. Seens I dont want to break geoserver or geotools release, here is what I'm going to do : I'm going to start a branch today, an start upgrading the styles on it. And the 15 july I will merge with the trunk. I hope this will suit everyone. regards -- Johann Sorel Company - Geomatys GIS Developer Mail - [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
