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
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
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.
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)
line symbolizers
point symbolizers
text symbolizers (although I think geotools treats these specially anyway?)
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.
--
David Winslow
OpenGeo - http://opengeo.org/
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
AndreaYes 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.