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
