I'm definitely warming up to the idea of the pluggable 19117 protocol. > 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)? > 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. -Patrick Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
