Andrea can I ask if this is a problem with the SLD parser; or a problem with
the data structures? I tried to carefully make the geometry operations
reduce their values to two expressions; the String based PropertyName
accessors are still there; but have warnings that they only work with the
expression used is a PropertyName.
This was one of the motivations for FilterFactory2 (
http://geoapi.sourceforge.net/snapshot/javadoc/index.html). So you must be
talking SLD / SE.
I would like to see if we can make that a choice; based on your examples I
can only see the use of Function or PropertyName right now (are their any
other useful possibilities?).
Jody
On Sun, Feb 15, 2009 at 1:34 AM, Andrea Aime <[email protected]> wrote:
> Hi all,
> I'm writing this mail to explore the possibility of extending
> our current SLD support for symbolizer geometry.
> With the current SLD 1.0 (and even with SE 1.1) we're stuck
> with just telling the symbolizer which geometry attribute to
> use, as the <sld:geometry> element is hard coded to be a
> PropertyName.
>
> This is lame, things would be much more flexible if that
> was an Expression instead.
> Coupled with filter functions that we already have today
> and a handful of new ones we could get:
> - on the fly geometry generation, such as buffering
> points and lines to draw buffer areas on the fly
> - on the fly slice and dice, such as drawing only a portion
> of a line with a certain color, or making sure the
> geometry is sliced against the bouding box before
> rendering it into a vector format (I'm thinking PDF,
> using the Graphics object provided by iText)
> - drop shadow effect, which could be achieved by just
> offsetting the geometry and drawing it with a darker
> color
> - draw a line vertexes (typical selection style) by
> turning the line into a multipoint on the fly
>
> Add the ability to define you own geometry manipulation
> functions and the possibilities are endless.
> Unfortunately there is a significant drawback: everything
> in the current api is stuck to geometryName <=> String.
>
> Soo... how could we add such support without breaking things
> too much? One thing that comes to mind is to have a new
> element, <GeometryEx> that is declared as an Expression.
> This could be added to the existing symbolizer
> classes/interfaces without much breakage, and extending
> the parser to handle that as well.
>
> The xml would look like:
>
> <PointSymbolizer>
> <GeometryEx>
> <Function name="extractVertex">
> <ogc:PropertyName>myLineStringGeom</ogc:PropertyName>
> </Function>
> </GeometryEx>
> ...
> </PointSymbolizer>
>
> What do you think?
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
