[Geoserver-users] question about SLD performance

Hello,

Does anyone know the performance implications of creating an SLD with 1 FeatureTypeStyle and having all your “Rule” elements in that OR splitting your “FeatureTypeStyle” out into multiple elements and having 1 Rule in each. Any insight or documentation will be helpful.


Signed,
Alessandro Ferrucci

Alessandro Ferrucci ha scritto:

Hello,

Does anyone know the performance implications of creating an SLD with 1 FeatureTypeStyle and having all your "Rule" elements in that OR splitting your "FeatureTypeStyle" out into multiple elements and having 1 Rule in each. Any insight or documentation will be helpful.

In theory GeoServer should look at the rules and build a query by or-ing
all of the rule filters. Yet, if there are more than 20 rules an heuristics will kick in that assumes the query is becoming too big, and
thus no filter (besides the bbox) will be sent to the database.

In the case of shapefiles the filtering will occur in memory anyways.

What problem are you seeing?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea,

Re: 'if there are more than 20 rules ... no filter (besides the bbox)
will be sent to the database'

I think I might not be understanding what you have said. With
Geological maps, we need to use many more than 20 colours - the
Geological map that I am using for testing Geoserver at the moment has
51 colours - ie. my SLD has 51 rules based on a field called
'polycolour' and when I view it as a rasterised image in Google Earth
or uDig all the colours seem to show OK. I do have a problem, though,
when I zoom in and get vector output in GE - one of the colours is
missing (ie. transparent) but it is not the 21st rule - it is my 2nd
rule ...

       <Rule>
          <Name>12</Name>
          <Title>12</Title>
          <ogc:Filter>
            <ogc:PropertyIsEqualTo>
              <ogc:PropertyName>POLYCOLOUR</ogc:PropertyName>
              <ogc:Literal>12</ogc:Literal>
            </ogc:PropertyIsEqualTo>
          </ogc:Filter>
          <PolygonSymbolizer>
            <Fill>
              <CssParameter name="fill">#FFFFCC</CssParameter>
              <CssParameter name="fill-opacity">1</CssParameter>
            </Fill>
          </PolygonSymbolizer>
        </Rule>

Can you please clarify what you mean about the 20 rule maximum?

Regards,
David Collins

If you have any ideas about the missing colour I will also be
grateful. (Thanks again for all the help you have already given me.)

On Wed, Jun 17, 2009 at 6:22 PM, Andrea Aime<aaime@anonymised.com> wrote:

Alessandro Ferrucci ha scritto:

Hello,

Does anyone know the performance implications of creating an SLD with 1
FeatureTypeStyle and having all your "Rule" elements in that OR
splitting your "FeatureTypeStyle" out into multiple elements and having
1 Rule in each. Any insight or documentation will be helpful.

In theory GeoServer should look at the rules and build a query by or-ing
all of the rule filters. Yet, if there are more than 20 rules an
heuristics will kick in that assumes the query is becoming too big, and
thus no filter (besides the bbox) will be sent to the database.

In the case of shapefiles the filtering will occur in memory anyways.

What problem are you seeing?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

David Collins ha scritto:

Andrea,

Re: 'if there are more than 20 rules ... no filter (besides the bbox)
will be sent to the database'

I think I might not be understanding what you have said. With
Geological maps, we need to use many more than 20 colours - the
Geological map that I am using for testing Geoserver at the moment has
51 colours - ie. my SLD has 51 rules based on a field called
'polycolour' and when I view it as a rasterised image in Google Earth
or uDig all the colours seem to show OK. I do have a problem, though,
when I zoom in and get vector output in GE - one of the colours is
missing (ie. transparent) but it is not the 21st rule - it is my 2nd
rule ...

       <Rule>
          <Name>12</Name>
          <Title>12</Title>
          <ogc:Filter>
            <ogc:PropertyIsEqualTo>
              <ogc:PropertyName>POLYCOLOUR</ogc:PropertyName>
              <ogc:Literal>12</ogc:Literal>
            </ogc:PropertyIsEqualTo>
          </ogc:Filter>
          <PolygonSymbolizer>
            <Fill>
              <CssParameter name="fill">#FFFFCC</CssParameter>
              <CssParameter name="fill-opacity">1</CssParameter>
            </Fill>
          </PolygonSymbolizer>
        </Rule>

Can you please clarify what you mean about the 20 rule maximum?

When hitting the data storage we can decide to OR all the rule
filters into a giant query, like:

select ... from table where geom in bbox and (prop = val1 or prop = val2
or prop = val3 or ...)

or just assume that you're not really trying to filter your data but
just coloring each with a different color, and thus a query like:

select ... from table where geom in bbox

is just as good. The threshold between the two behaviors is at 20
rules. It does not mean you cannot have more than 20 rules,
just means after 20 the query issued against the server will change.

As to why the second color is not showing up in GE, might it be
because the superoverlay code is deciding that those feature are
less important and thus you have to zoom in more?

Try adding &mode=download to your kml link, does it work any better?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.