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.
What seems to be missing is the ability to go beyond attribute names. 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, but 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'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.
Lastly, I noticed what appears to be an editing mistake in the proposal: the
sentence after the box containing the MarkFactory and ExternalGraphicFactory
interfaces in the API section ends with "that can be sized, filled and stroked
at will (even TTF symbols can be turned into a shape using." The end of the
sentence appears to be missing.
Jamison
On Tue, May 13, 2008 04:11 PM, Andrea Aime <[EMAIL PROTECTED]> wrote:
>
JAMISON CONLEY ha scritto:
>> Jody,
>>
>> If the question I asked in a previous e-mail (about assigning
>> expressions to any attribute of a symbol) is addressed, then yes, it
>> does work for my needs.
>
>No, it does not work like this. It allows you to embed feature
>attributes in the symbol name instead, and then the symbol generator
>can extract the attributes.
>
>A symbol name could be something like:
>chart://histogram?dataSeries=${dataSeriesId}&title=${chartTitle}
>
>where dataSeriesId and chartTitle are attributes of the feature. The
>chart symbol factory would get an Expression out of that name (courtesy
>of some extra parsing done centrally in the SLDStyleFactory).
>
>What you ask, assigning expressions to everything, would just break
>solid the SLD compliancy, so I (personally) don't consider it a
>solution.
>
>But please, have a look at the proposal, provide feedback on it:
>http://docs.codehaus.org/display/GEOTOOLS/Dynamic+SLD+Graphic+objects
>
>Cheers
>Andrea
>
>
>
>
>
>
Jamison Conley
Dept. of Geography
Pennsylvania State University
-------------------------------------------------------------------------
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
