johann sorel ha scritto: > 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.
This is actually "perpendicularOffset" (SE spec, page 21), but yeah, thanks for pointing this out. >> - 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. The PDF case is an optimization indeed, the "draw a portion of a line from km 5 to km 10 a different color" pops up from time to time on the GeoServer users mailing list and it's no optimization. It's something that routing related renderers are able to do, and SLD driven ones cannot. >> - 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. This is actually displacement (SE spec, page 21), but I see your point. Still, I'm looking for something more general. >> - 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 ? That works for a stateful renderer, not for web based ones. Plus, being able to draw the vertices is something has popped up a few times on the geoserver user list already, not something I'm making up. I also had to hand modify the current renderer to support this a few times for debugging purposes. >> 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). Sorry I don't follow you. When you evaluate the property name against a feature, don't you get a different geometry for each feature? What's different in evaluating a function instead of getting the feature geometry? You still get back one geometry per feature, and you can still cache the result, functions are stateless as far as I know, given the same inputs you'll get back the same output, so the result seems to be cacheable. > > 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. Hum, my experience with the GeoServer users is that SLD covers all the basics, but it's quite away from a professional usage. Just see all the options we provide to control labelling on a per symbolizer basis, or the dynamic symbolizers, which are quite appreciated by most of the user base, or the common need to draw road plates (symbol + number superimposed, and locked togheter so that if the label is not drawn due to label conflict resolution, neither is the symbol). Sure SE is a neat improvement over SLD 1.0, uom support is important, and the classification functions improve a lot the readability of a style document, but there are still a number of common things that you cannot do, and that non SLD based softwares already provide. Among the "big" maps made by GeoServer users that I looked at recently, none used only the pure SLD abilities, some of the current extensions was always used. If you want another example, look at the DeeGree ability to draw charts on top of a map. Guess what, they ended up doing something very similar to the "dynamic symbolizers" proposal, and they did so independently of us. > - For all other things (endless possibilities) make new symbolizer > implementations that the streaming renderer will be able to understand. Sure, I could make a PointSymbolizerEx, LineSymbolizerEx, and so on, that extend the base symbolizers. And then alter the parser to build these extended classes. As long as you don't know what they have to offer beyond the GeoApi abilities you simply don't use them. If the user chose to use extended abilities the rendering will break anyways. But isn't already what's happening with the gt2 symbolizer interfaces? They extend the GeoApi ones to provide extra functionality. So, why not put this extension there too? A GeoApi based renderer will just not see the extra methods, and end up drawing the default geometry instead. 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
