David Winslow ha scritto: > On 04/06/2010 04:04 PM, Andrea Aime wrote: >> Hi, >> looking at how CSS behaves I have the impression >> the relationship with the CSS and the generation >> of multiple feature type styles follows a set of >> heuristics. >> >> I was wondering, wouldn't it be better to have >> it user controlled by means of something explicit, >> like z-index, for example? >> >> Cheers >> Andrea >> >> > Yes it would. Tickets are welcome, patches more so.
Here is a jira: http://jira.codehaus.org/browse/GEOS-3905 Patches... hmmm... having a hard time even reading the Scala code that makes up the CSS module. I'll pass on that. > > btw, the current heuristic is to order by geometry type, then by > declaration in the style rule. so we have: > > polygon symbolizers (fill only, the css module never outputs a stroke > for a polygon) Meaning that polygon styles with borders end up always generating two FTS? > line symbolizers > point symbolizers Overlapping simple point symbols to generate more complex ones is a common trick (think of a triangle inscribed in a circle), in that case you really don't want two separate FTS, as you'd get the wrong visual effect. > text symbolizers (although I think geotools treats these specially anyway?) Yeah, putting them on their own FTS is a waste of memory, the renderer will draw them last anyways (without the need of an extra buffer in memory) > No rule is produced with more than one symbolizer in it, and then > featuretypestyles are created with only mutually exclusive rules in > them. No provisions are made to avoid mixing symbolizer types within > these featuretypestyles, so I imagine there are some combinations of > rules with different numbers of strokes/fills that could have fills > overlapping outlines, etc. Yeah... unfortunately the current setup makes for quite expensive to build maps in terms of memory used, each FTS uses its own separate in memory buffer. Imho this makes the module not very palatable to setup styles meant for production use (I fully understand it's still a community one and it's still not meant for production). That's why I was suggesting better control. Oh, btw, tomorrow I'll commit http://jira.codehaus.org/browse/GEOT-3023 which will also improve the CSS -> SLD conversion, by creating more compact SLD representations. Hum... that seems to break the existing CSS tests. Anyways, the output of the conversion of: * { fill: lightgrey; stroke: black; } will be "just": <?xml version="1.0" encoding="UTF-8"?> <sld:UserStyle xmlns="http://www.opengis.net/sld"; xmlns:sld="http://www.opengis.net/sld"; xmlns:ogc="http://www.opengis.net/ogc"; xmlns:gml="http://www.opengis.net/gml";> <sld:Name>Default Styler</sld:Name> <sld:Title /> <sld:FeatureTypeStyle> <sld:Name>name</sld:Name> <sld:Rule> <sld:Name>*</sld:Name> <sld:PolygonSymbolizer> <sld:Fill> <sld:CssParameter name="fill">#d3d3d3</sld:CssParameter> </sld:Fill> </sld:PolygonSymbolizer> </sld:Rule> </sld:FeatureTypeStyle> <sld:FeatureTypeStyle> <sld:Name>name</sld:Name> <sld:Rule> <sld:Name>*</sld:Name> <sld:LineSymbolizer> <sld:Stroke> <sld:CssParameter name="stroke-linecap">miter</sld:CssParameter> <sld:CssParameter name="stroke-linejoin">butt</sld:CssParameter> </sld:Stroke> </sld:LineSymbolizer> </sld:Rule> </sld:FeatureTypeStyle> </sld:UserStyle> Err... I think there is a mishap in the linecap/linejoin param values generated by the CSS module. From the SLD spec: --------------------------------------------------------------- The allowed values for line join are “mitre”, “round”, and “bevel”, and the allowed values for line cap are “butt”, “round”, and “square”. The default values are system-dependent. --------------------------------------------------------------- Created an issue for this one as well: http://jira.codehaus.org/browse/GEOS-3906 Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
