On Wed, May 14, 2008 02:17 PM, Jody Garnett <[EMAIL PROTECTED]> wrote:
>
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.
>
>Understandable.
>
>> 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 was wrong. Thank you for sending that link.
>
>> 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 ...
>
>We adapted to that by passing the FeatureCollection along with the Feature.
>It was some extra bookkeeping, but nothing too onerous.
>To my knowledge, this was mostly, if not entirely in the form of
>classification functions, and I switched over to the ones in the geotools
>library (e.g., org.geotools.filter.function.EqualIntervalFunction).
>
>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
>
>
>
The use of Icon will help.
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
