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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
