JAMISON CONLEY wrote: > Andrea & Jody, > > From reading the proposal I didn't think that assignment process I > described was how it worked, but with a sufficiently (or overly) > complex symbol name, most of the functionality can be incorporated. > Instead of an XML snippet of > <Parameter name="headSize">15</Parameter> > the name could have > glyph://arrow?headSize=15&length=${speed}&orientation=${direction} > where speed and direction are attributes. I think both are ways to > get around limitations in SLD 1.0/SE 1.1, and the primary difference > is how that is achieved, through adjustments to the XML or creatively > embedding that information in the name. I understand your proposal; and it is something that was considered (since the code to allow parameters to be expressions was already in place). I agree with you that both are hacks; so I decided to go with the one that had an active developer - at the time I could not find anyone who was using or understood the GlyphRenderer class. > What seems to be missing is the ability to go beyond attribute names. CQL lets you work with the full range of the Expression Syntax... > It often made sense to set the size of a mark to an expression like 50 > * attribute so that the marks were big enough, or set the size to > log(attribute) so the map isn't dominated by one or two humongous > marks. To my knowledge, CQL doesn't permit this, It does; check out the examples here: - http://udig.refractions.net/confluence/display/EN/Common+Query+Language#CommonQueryLanguage-Math > I have code that, in effect, adds a column to a FeatureCollection > (assuming that code can survive the changes to the FeatureCollection > interface in 2.5), so adding a new column logAttribute to the dataset > and naming the symbol glyph://arrow?headSize=${logAttribute}... should > be a workaround. With that workaround, the proposal looks good to me. I am very interested in hearing about your FeatureCollection functions, previously GeoVista (in GeoTools 2.2) made use of functions that looked up the FeatureCollection associated with an individual Feature and performed a bit of summary work. That functionality was not supported by the OGC General Feature Model and was removed for GeoTools 2.3 ...
So now you have kind of a two step process: - Explicitly run a function / expression on the FeatureCollection to generate a result - Take the result and use it as a parameter when evaluating an expression for each feature Using this you can do a lot of the attribute normalization work that GeoVista made good use of.. although I suspect that most of that can be reduced to one of the SE 1.1 Categorization functions... > I'd probably do a glyph library using implementations of the > ExternalGraphicFactory interface, since the glyphs could easily become > more complex than a single java.awt.Shape object. Agreed; I hope that the use of Icon there will help. Jody ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel