Andrea Aime wrote: > 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. > Agreed; so when we learn more from both groups we can make some decisions here. Thanks for getting the conversation started. >> 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? ; > No it is a function (in the mathmatical sense) mapping an input (value) to an output (color). > Kidding, you do mean we'd have the function implement the old ColorMap > inteface, right? Correct. > This should make for an easy transition in the code that's using the existing > one. > I see the following: - ColorMap in coverage; marked as since 2.4 - Martin what is your integration plan if anything? - ColorMap in styling; this is the one that after the SE1.1 update will implement function (if I understand the schema correctly). Eclesia can you clarify? > Oh boy, I suffer the very existence of GeoAPI a lot... > Nice rant: even if it is just debating the interfaces - we still need to debate the interfaces :-) And at least with GeoAPI the idea pool is a little larger and the Jira for tracking changes is a lot better. >> - 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? > I am not interested in fair; I am interested in making this beautiful; or at least consistent. Seriously I asked the recent raster symbolization work to review SE1.1 as part of me voiting +1. Simone did do that and did not find any conflicts; now is the time we get to see if he was right. >> 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... > Just so. > 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. > Understood; it is not something we can remove; but this is an area I would like to clean up. I got my work cut out for me cleaning up data access first. > 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? > Other way around; if you take one of these new GraphicMarks that uses an inline graphic you will not be able to write it out as an SLD 1.0 document. We have backwards compatibility in all cases; but we do not have forward compatibility (the new function names etc can be used in SLD 1.0 however).
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
