Patrick Webb wrote: > I'm definitely warming up to the idea of the pluggable 19117 protocol. You guys have to communicate what 19117 *is*, remember we have not all got access to the doc :-) So you guys want to tell me what 19117 *is* and then I can consider getting excited as well....
Jody >> 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. >>> > > Hello there. I'm reading all the material in the link you included > below. Thank you. > >>> >> 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) >>> > > I've been on the developer list, just haven't really contributed until > now. Bryce, I don't have a copy of the 19117 format to peruse. Do you > happen to know of a place where I could acquire such information? > Also, is the uDig rendering system an alternative to the 19117 format, > or just a means of implementing a renderer (which could just as well > conform to 19117)? Like you I have no idea :-) The important part to me of the uDig rendering system is the way in which a renderer is selected for the content, user controlled style, and device at hand. >> 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. > Lots of information here to read. Whew. :-) Have fun. Jody _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
