Got to go pluggable :-) We use it in uDig and it *rocks*, not even limited to/by SLD, you can use any "metadata" to control your rendering that is placed on a "style blackboard".
Okay now that that is out of the way I can respond to the email :-) > Problem: Geotools' renderer is based on SLD, SLD does not allow anything > which is not specifically defined, and SLD does not define a means of > portraying vector data, aka wind barbs. Current hacks generate a large > number of icons (for each wind-speed/direction combo) and define one rule > per icon. Patrick is interested in solving this problem so the hack is not > necessary. > We have resolved the *extention* approach at an architecture level - see discussion on "shield" labels. If you need to extend an existing SLD construct (or add a new kind of symbolizer) you can add it to StyleFactory2, extensions should be marked as such (so TextSymboloizer has a subclass TextSymboloizer2 that is geotools specific). All such things are optional and may not be understood by all renderers (since they would not conform to a standard) but what the heck. Cory has permission to collapse the GeoAPI style interfaces, allowing us to directly use the GeoAPI interfaces. We will still keep our practice of extension as described above. Just retire our own interfaces in a the same manner as is happening with Expression and Filter on trunk right now. > The discussion thus far has centered on the approach to use, and Patrick > has solicited feedback from me (as a GT-associated-person) as to what is > "most useful". It thus becomes time to connect Patrick with the > developers list, lest my opinion be mistakenly construed as consensus. :) > Hi Patrick - afraid my above two statements were a bit definitive. I have examples of both approaches working (but the uDig based one is *so* much nicer to use). > The choices discussed focus on these two alternatives: > 1] Refactor the rendering framework to accept some sort of pluggable > rendering component. Write a wind-barbing component too. If we're doing > this, the framework might as well conform to 19117. > Would love to see this compared with the "Adaptive Rendering" used by uDig, and outlined in an OGC OWS-3 implementation report (if you can get your hands on such things). > 2] Extend SLD (& our renderer) to define a WindBarbSymbolizer & parameters. > This would need to be a legal tag for point features and coverages. > Approach used in GeoTools currently. > #2 grates on my nerves because too many "extensions" is going to produce > nasty code. #1 is more work, but provides a very nice framework into which > new functionality may be added (e.g., it allows everything not specifically > forbidden). Can you guess which one I've been talking up? :) > Understood, but why not review the uDig implementation - the code can be back ported and it is working out perfectly. With plug-ins being written OSSIM, WMS and optimizations for common use like shapefiles it appears to scale, allow for specific code where useful etc... > My concern regarding #2 (aside from the nasty code that such grafting > generally produces) is "tampering" with SLD. Are people going to want a > "normal" SLD to live side by side with the "extended" SLD? Could we just > replace the normal SLD parser with our extended version, or does this cause > heartburn? If we need _two_ SLD parsers, how do we select the one to use? > Note: we needed to allow for extension of SLD when people work on the "next" version of the specification SLD 1.1 so it was not really going out of our way. > Please "reply to all" with comments, as I do not know if Patrick is on the > list yet. (Patrick, it'd be good to join the mailing list if you haven't > already. http://docs.codehaus.org/display/GEOTOOLS/Mailing+Lists) > Thanks for the intro and trying to entice new developers. I know I went through the above issues very quickly, and all the docs describing what uDig does at an architecture level is either commercial training materials or locked behind an OGC process right now. Here is a programmers guide document though: - http://udig.refractions.net/confluence/display/DEV/7+Renderers The examples at the bottom of the page show the system working with both SLD styles (for feature renderers) and named styles (for WMS renderers). Adding renderers is based on a plugin system, choosing renderers is based applicability and a quality vs speed trade off as appropriate. I know it is not the right level of detail for this discussion but should at least introduce terms. There are only a couple *great* ideas in uDig and this is one of them. Aside: The Renders in the above link are isolated from SWT or SWT and could be used to draw into an OpenGL pipeline if needed. Writing platform specific renderers, or making use of C++ code (like OSSIM) is all fair game. Cheers, Jody _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
