Hi, What do people make of this thought - StyledMapPane already contains a windbarb component?
Before continuing: sorry if I seem to go on about StyledMapPane a lot :-) As you'll guess I am keen to see it reunited with the trunk and will help with the GO implemenmtation when I can. (One reason I tried to help with the JTS geometry wrappers was because according to jira this was a blocking issue for the GO-1 work). Anyway, the RenderedMarks used by StyledMapPane have amplitude and direction attributes. The RenderedGridMarks layer uses these to represent a coverage and one of the default representations is arrows, the sizes and direction of which depend on the sample values. In my experience, these RenderedMark things are pretty darn flexible. Also, it is fairly easy to animate such a layer, and performance is good because the lower layers can be buffered. Do all the features of StyledMapPane have a place in the GO-1 implementation? Or alternatively, is there scope for "some sort of pluggable rendering component" in GO-1? col > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Jody Garnett > Sent: 20 June 2006 11:30 > To: Bryce L Nordgren > Cc: [EMAIL PROTECTED]; geotools-devel > Subject: Re: [Geotools-devel] Rendering: Pluggable or Extensible? > > 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 > _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
