Hi, (read bellow) Andrea Aime a écrit : > 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 > This is already in the SE definition for polygon symbolizer. See Displacement property. but not on points or lines. > - 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) > This is a renderer issue, we should not make a rendering operation in an expression, imagine how it would behave if your special expression optimized for the streamingRenderer is used in another renderer, a glyph factory or even a 3D renderer ? since style are generic and can be used by anything, they should not offer the possibility to be tightly related to some special optimizations. > - drop shadow effect, which could be achieved by just > offsetting the geometry and drawing it with a darker > color > This is already in the SE definition for polygon symbolizer. See Offset property. but not on points.
> - draw a line vertexes (typical selection style) by > turning the line into a multipoint on the fly > Shouldn't that be somewhere else ? this is relative to user interaction, so it should be stored somewhere in the application and given to the renderer as some kind of special feature list ? > 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. > I think the idea is not bad, but it's simple only for the streaming renderer once again, since it's rebuild it's cache each time it doesn't matter for it. The problem is different when you work in statefull mode. If the geometry becames an Expression, that means it can't be cached since it may change because of whatever factor, attribut or variable in the application (it could even change with time, impossible in statefull mode to track down a expression result change for each feature). Here is another approach I propose : - Keep close to the specification and dont change it. The specification is perhaps not perfect but it's fair and square and works for 98% of the use cases. - For all other things (endless possibilities) make new symbolizer implementations that the streaming renderer will be able to understand. This way you just extend the specification (by providing a new symbolizer) and you dont break anything. johann ------------------------------------------------------------------------------ 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
