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
>>>
>>
>>
>>
>
>
[A0 < 0] { stroke: black; }
[A1 < 0] { stroke: black; }
[A2 < 0] { stroke: black; }
[A3 < 0] { stroke: black; }
[A4 < 0] { stroke: black; }
[A5 < 0] { stroke: black; }
[A6 < 0] { stroke: black; }
[A7 < 0] { stroke: black; }
[A8 < 0] { stroke: black; }
[A9 < 0] { stroke: black; }
[A10 < 0] { stroke: black; }
[A11 < 0] { stroke: black; }
[A12 < 0] { stroke: black; }
[A < 00] { stroke: black; }
[A < 10] { stroke: black; }
[A < 20] { stroke: black; }
[A < 30] { stroke: black; }
[A < 40] { stroke: black; }
[A < 50] { stroke: black; }
[A < 60] { stroke: black; }
[A < 70] { stroke: black; }
[A < 80] { stroke: black; }
[A < 90] { stroke: black; }
[A < 100] { stroke: black; }
[A < 110] { stroke: black; }
[A < 120] { stroke: black; }
------------------------------------------------------------------------------
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
