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 <cgalpin@anonymised.com> 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 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 <cgalpin@anonymised.com> 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 <cgalpin@anonymised.com> 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
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
<slow.css><quick.css>