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

Reply via email to