Set z-index or stroke-z-index on rules, it's a numeric field that is used to
sort the rules before outputting to sld. Like most other properties, it can
be repeated to provide different values for repeated strokes of the same
fields:
[type='road'] {
stroke: red, yellow;
stroke-width: 6, 2;
stroke-z-index: 0, 10;
}
Each unique z-index value produces a new FeatureTypeStyle in the SLD.
--
David Winslow
OpenGeo - http://opengeo.org/
On Tue, Apr 5, 2011 at 1:52 PM, Charles Galpin <[email protected]> wrote:
> Yes that's pretty interesting.
>
> Ok, I've got one more for you. Even though I am listing my styles in order,
> the generated SLD seems to re-arrange them so that I see interesting overlap
> order - like a weaving effect.
>
> I have something like this, the idea being draw red lines above the green
> ones but sometimes you'll see a red line go under a green line and over the
> next. Is there any way to force the ordering?
>
> [data_type < 4], [data_type > 5]
> {
> stroke-width: 2;
> }
>
> [data_type = 4] {
> stroke-width: 2;
> stroke-dasharray: 2 2;
> }
>
> [congestion_level = 'G'] [data_type < 4],
> [congestion_level = 'G'] [data_type > 5]
> {
> stroke: #008000;
> stroke-linecap: butt;
> stroke-linejoin: miter;
> }
> [congestion_level = 'G'] [data_type = 4]{
> stroke: #008000;
> }
>
> [congestion_level = 'R'] [data_type < 4],
> [congestion_level = 'R'] [data_type > 5]
> {
> stroke: #FF1919;
> stroke-linecap: butt;
> stroke-linejoin: miter;
> }
> [congestion_level = 'R'] [data_type = 4]{
> stroke: #FF1919;
> }
>
> And the generated SLD looks something like
>
> FeatureTypeStyle
> Rule G data_type=4
> Rule R data_type=4
> Rule G data_type < 4, >5
> Rule R data_type < 4, >5
>
> Instead of
>
> FeatureTypeStyle
> Rule G data_type < 4, >5
> Rule G data_type=4
>
> Rule R data_type < 4, >5
> Rule R data_type=4
>
> Thanks,
> charles
>
> On Apr 4, 2011, at 3:37 PM, David Winslow wrote:
>
> Well, conceptually the CSS extension has to consider all possible
> combinations of rules from the original style to produce an equivalent SLD -
> ie, every CSS rule you add effectively doubles the amount of work the
> translator has to do. There is a basic simplifier built in to reduce the
> translation time and the size of the resultant SLDs, but you can still get
> into trouble if you have many rules, especially if they don't reference any
> of the same properties.
>
> For example, compare the translation times for the quick.css and slow.css
> styles I'm attaching. They are equally complex, but the slow.css is not
> simplifiable so it takes much longer to convert and generates an enormous
> SLD file (37MB, in case you don't want to wait around for the conversion to
> finish). Hopefully this will give you a bit of insight into what sorts of
> rules work well together.
>
> It would also be possible to modify GeoTools/GeoServer to render directly
> from CSS styles and avoid the translation step, but it's not a task I'm
> planning to undertake while the CSS module is still a spare-time project for
> me.
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On Mon, Apr 4, 2011 at 3:13 PM, Charles Galpin <[email protected]> wrote:
>
>> Yes I was trying to keep it brief. I have similar statements for each
>> color as well. I had gone down the path of entries for each data_type and
>> anted to just make sure I wasn't doing any more work than necessary here too
>> as the rendering seemed to get a lot slower that way.
>>
>> Thanks again,
>> charles
>>
>> On Apr 4, 2011, at 3:10 PM, David Winslow wrote:
>>
>> The only thing I see that's off about this example is that it doesn't
>> specify a color. The CSS translator won't output <LineSymbolizer> elements
>> unless there is a "stroke" property explicitly provided in the style. If
>> you are adding it to either of your previous examples in this thread that
>> shouldn't be a problem though.
>>
>> --
>> David Winslow
>> OpenGeo - http://opengeo.org/
>>
>> On Mon, Apr 4, 2011 at 3:06 PM, Charles Galpin <[email protected]> wrote:
>>
>>>
>>> On Apr 4, 2011, at 2:26 PM, David Winslow wrote:
>>>
>>> A rule like:
>>>
>>> *[data_type < 4] [data_type > 5] *
>>> *
>>> *
>>> only matches when the data_type property is *both* less than 4 and
>>> greater than 5. The CSS translator optimizes that out since it can't ever
>>> happen; that's why you end up with an empty SLD. If you want to match when
>>> either of these conditions is met, just separate them with a comma.
>>>
>>>
>>> Doh, I knew it was going to be something simple (and stupid on my part).
>>>
>>> Before I do anything else stupid, this still mans I have to do something
>>> like this if combining with different scale levels correct?
>>>
>>> [@scale < 1000000000] [@scale > 10000000] [data_type<4],
>>> [@scale < 1000000000] [@scale > 10000000] [data_type>5]
>>> {
>>> stroke-width: 1;
>>> }
>>> [@scale < 1000000000] [@scale > 10000000] [data_type = 4] {
>>> stroke-width: 1;
>>> stroke-dasharray: 2 2;
>>> }
>>>
>>> thanks,
>>> charles
>>>
>>>
>>> --
>>> David Winslow
>>> OpenGeo - http://opengeo.org/
>>>
>>> On Mon, Apr 4, 2011 at 2:01 PM, Charles Galpin <[email protected]> wrote:
>>>
>>>> I'm having trouble with the CSS module. My ultimate goal is to filter
>>>> out data with the attribute data_type = 5, and use a different style for
>>>> data_type = 4 (while displaying a different line color based on
>>>> congestion_level and then adjust line widths by scale) .
>>>>
>>>> If I use
>>>>
>>>> [data_type = 3],[data_type = 6],[data_type = 7] {
>>>> stroke-width: 2;
>>>> }
>>>>
>>>> [congestion_level = 'G'][data_type = 3], [congestion_level =
>>>> 'G'][data_type = 6], [congestion_level = 'G'][data_type = 7]{
>>>> stroke: #008000;
>>>> stroke-opacity: 0.5;
>>>> stroke-linecap: butt;
>>>> stroke-linejoin: miter;
>>>> }
>>>>
>>>> I get expected results, but not if I do
>>>>
>>>>
>>>> [data_type < 4] [data_type > 5] {
>>>> stroke-width: 2;
>>>> }
>>>>
>>>> [congestion_level = 'G'][data_type < 4] [data_type > 5] {
>>>> stroke: #008000;
>>>> stroke-opacity: 0.5;
>>>> stroke-linecap: butt;
>>>> stroke-linejoin: miter;
>>>> }
>>>>
>>>> In this case no SLD is generated. I also can't use "data_type <> 4"
>>>> either, but I get an exception for this so I'll file a bug.
>>>>
>>>> thanks,
>>>> charles
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Create and publish websites with WebMatrix
>>>> Use the most popular FREE web apps or write code yourself;
>>>> WebMatrix provides all the features you need to develop and
>>>> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>>>> _______________________________________________
>>>> Geoserver-users mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>
>>>
>>>
>>>
>>
>>
> <slow.css><quick.css>
>
>
>
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
