[Geoserver-users] SLD Too many rules/filters?

Pedro_Mendes2 · March 24, 2009, 4:25pm

Hi,

When trying to do a GetMap to a FeatureType with a certain sld
http://www.nabble.com/file/p22684181/sld_node_db_longer.sld
sld_node_db_longer.sld the following exceptions are thrown
http://www.nabble.com/file/p22684181/geoserver.log geoserver.log . With a
shorter version sld
http://www.nabble.com/file/p22684181/sld_node_db_shorter.sld
sld_node_db_shorter.sld (90% of sld rules were cut off) the expected result
is outputed.

Version: Geoserver 1.7.2 + oracle extension (old oracle plugin).

By the way we're experimenting some issues with wfs-t (USING NULL SRID) with
the oracle NG extension. I read the thread reporting this problem. Where can
I grab a nightly build of this extension with this issue resolved Geoserver
1.7.2 compatible?

--
View this message in context: http://www.nabble.com/SLD-Too-many-rules-filters--tp22684181p22684181.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Andrea_Aime3 · March 25, 2009, 8:53am

Pedro Mendes ha scritto:

Hi,

When trying to do a GetMap to a FeatureType with a certain sld http://www.nabble.com/file/p22684181/sld_node_db_longer.sld
sld_node_db_longer.sld the following exceptions are thrown http://www.nabble.com/file/p22684181/geoserver.log geoserver.log . With a
shorter version sld http://www.nabble.com/file/p22684181/sld_node_db_shorter.sld
sld_node_db_shorter.sld (90% of sld rules were cut off) the expected result
is outputed.

Version: Geoserver 1.7.2 + oracle extension (old oracle plugin).

Wow, a 27.000 lines SLD, that's the longest I've ever seen.
From what I see there you have a lot of different "subtypes"
and you need to display each of them with a different
symbol stored in a TTF symbol font, right?
Do you also need label conflict resolution? Otherwise you
may find a more compact solution using the dynamic symbolizer
features?
http://blog.geoserver.org/2008/12/16/dynamic-symbolizers-part-2/
(that might require some changes in the data structure thought,
you'd need to have the symbol code stored in one of your
feature variables.

Hmmm... looking at the code there should be some bug, the
renderer tries to build a filter out of the rules to limit
the amount of data it has to read, by or-ing the conditions
of each rule, but there is a limit of 20 rules, if that is
exceeded, it should give up and just use the bbox as the
filter. Indeed, I can confirm it's an issue, there is a bug
in the query building code inside the WMS renderer:
http://jira.codehaus.org/browse/GEOS-2781

I hopefully fixed it, can you double check by downloading
a nightly build starting from March 26? (the March 25 one
does not contain the fix):
http://gridlock.openplans.org/geoserver/1.7.x/

By the way we're experimenting some issues with wfs-t (USING NULL SRID) with
the oracle NG extension. I read the thread reporting this problem.

And... was the problem actually solved? (don't remember)

Where can
I grab a nightly build of this extension with this issue resolved Geoserver
1.7.2 compatible?

Hmmm... nowhere. The extensions and GeoServer are developed hand in hand, so an extension made for GeoServer 1.7.3 won't work for GeoServer
1.7.2.
OpenGeo provides the service of making custom bugfix build out
of older branches for customers of its support contract (among other
things).
Also, if you want to build your own, we can point you at the relevant
branches and the diffs and you can do the backport yourself.

Generally speaking, if anybody is interested in making custom bugfix
builds and share them with the community (say, release a 1.7.2.1,
1.7.2.2 and so on) we'll be happy to assist the effort providing
directions on how this can be done.

Cheers
Andrea

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

Pedro_Mendes2 · March 25, 2009, 10:28am

Wow, a 27.000 lines SLD, that's the longest I've ever seen.
From what I see there you have a lot of different "subtypes"
and you need to display each of them with a different
symbol stored in a TTF symbol font, right?

[Pedro Mendes] Yep. It's simple: We need to display the elements (types)
with different sizes on 7 scales >> 1 element == 1 SLD file. Each element
can have 1 or more subelements (subtypes). If there is a type with 20
subtypes, the correspondent SLD could have up to 14*20 Rules. Why 14?
Because the necessity of built Rules on pairs, one for background rendering
and other for foreground rendering.

Do you also need label conflict resolution? Otherwise you
may find a more compact solution using the dynamic symbolizer
features?

[Pedro Mendes] In this moment, yes, because of this issue:
http://www.nabble.com/SLD%3A-two-text-symboloizers-within-same-rule-td212107
78.html
But even with PointSymbolizer we'll have 7*20 Rules, so the issue will
persist.

http://blog.geoserver.org/2008/12/16/dynamic-symbolizers-part-2/
(that might require some changes in the data structure thought,
you'd need to have the symbol code stored in one of your
feature variables.

[Pedro Mendes] We already have the corresponding TTF character for each
subtype on database side, it should be just an update with character code.

Hmmm... looking at the code there should be some bug, the
renderer tries to build a filter out of the rules to limit
the amount of data it has to read, by or-ing the conditions
of each rule, but there is a limit of 20 rules, if that is
exceeded, it should give up and just use the bbox as the
filter. Indeed, I can confirm it's an issue, there is a bug
in the query building code inside the WMS renderer:
http://jira.codehaus.org/browse/GEOS-2781

I hopefully fixed it, can you double check by downloading
a nightly build starting from March 26? (the March 25 one
does not contain the fix):
http://gridlock.openplans.org/geoserver/1.7.x/

[Pedro Mendes] I'll do that.

And... was the problem actually solved? (don't remember)

[Pedro Mendes] I think so:
http://www.nabble.com/WFS-T-oracle-update-faild-on-GS-1.7.2-tp22331042p22331
042.html

Hmmm... nowhere. The extensions and GeoServer are developed hand in
hand, so an extension made for GeoServer 1.7.3 won't work for GeoServer
1.7.2.
OpenGeo provides the service of making custom bugfix build out
of older branches for customers of its support contract (among other
things).
Also, if you want to build your own, we can point you at the relevant
branches and the diffs and you can do the backport yourself.

Generally speaking, if anybody is interested in making custom bugfix
builds and share them with the community (say, release a 1.7.2.1,
1.7.2.2 and so on) we'll be happy to assist the effort providing
directions on how this can be done.

[Pedro Mendes] For the moment we'll just keep waiting for the bugs fix in
the nightly/stable versions.

Pedro_Mendes2 · March 30, 2009, 10:55am

Just tried out the nightly builds from days 26, 27 and 30 of March. The bbox
filter fix for SLD rules number greater than 20 works properly. But those
SLD that have less than 20 rules, only the first rule filter for a certain
scale it's picked up.
Example: there are 12 rules determined by maxscaledenominator=3406,
maxscaledenominator=5040 each one with a Filter(PropertyIsEqualTo) where
PropertyName(SUBTYPE) = 6 | 7 | 8 | 9 | 10 | 11.

The logs output this:
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - SELECT
GIRID,SCALE_FACTOR,SUBTYPE,ROTATION,COLOR,LOCATION as LOCATION FROM
CADREDE.GIR_INFRA_NODES WHERE (TYPE = ? AND (SDO_FILTER(LOCATION, ?) =
'TRUE' AND (SUBTYPE = ? OR SUBTYPE = ? OR SUBTYPE = ? OR SUBTYPE = ? OR
SUBTYPE = ? OR SUBTYPE = ? OR SUBTYPE = ? OR SUBTYPE = ? OR SUBTYPE = ? OR
SUBTYPE = ? OR SUBTYPE = ? OR SUBTYPE = ?)))
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 1 = 3
2009-03-30 11:10:50,268 DEBUG [org.geotools.data.oracle.sdo] - Using layer
SRID: 27492
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdb] - Setting paramtetr 2 as
MDSYS.SDO_GEOMETRY(2003,27492,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(-44126.549504996605,108112.96023011261,-44021.28067295289,108112.96023011261,-44021.28067295289,108167.35853407085,-44126.549504996605,108167.35853407085,-44126.549504996605,108112.96023011261))
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 2 = POLYGON
((-44126.549504996605 108112.96023011261, -44126.549504996605
108167.35853407085, -44021.28067295289 108167.35853407085,
-44021.28067295289 108112.96023011261, -44126.549504996605
108112.96023011261))
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 3 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 4 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 5 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 6 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 7 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 8 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 9 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 10 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 11 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 12 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 13 = 6
2009-03-30 11:10:50,268 DEBUG [org.geotools.jdbc] - 14 = 6

So the query resultset only contains records where SUBTYPE attribute is
equal to 6...there's something wrong, right?

regards,
Pedro Mendes

Pedro Mendes wrote:

Wow, a 27.000 lines SLD, that's the longest I've ever seen.
From what I see there you have a lot of different "subtypes"
and you need to display each of them with a different
symbol stored in a TTF symbol font, right?

[Pedro Mendes] Yep. It's simple: We need to display the elements (types)
with different sizes on 7 scales >> 1 element == 1 SLD file. Each element
can have 1 or more subelements (subtypes). If there is a type with 20
subtypes, the correspondent SLD could have up to 14*20 Rules. Why 14?
Because the necessity of built Rules on pairs, one for background
rendering
and other for foreground rendering.

Do you also need label conflict resolution? Otherwise you
may find a more compact solution using the dynamic symbolizer
features?

[Pedro Mendes] In this moment, yes, because of this issue:
http://www.nabble.com/SLD%3A-two-text-symboloizers-within-same-rule-td212107
78.html
But even with PointSymbolizer we'll have 7*20 Rules, so the issue will
persist.

http://blog.geoserver.org/2008/12/16/dynamic-symbolizers-part-2/
(that might require some changes in the data structure thought,
you'd need to have the symbol code stored in one of your
feature variables.

[Pedro Mendes] We already have the corresponding TTF character for each
subtype on database side, it should be just an update with character code.

Hmmm... looking at the code there should be some bug, the
renderer tries to build a filter out of the rules to limit
the amount of data it has to read, by or-ing the conditions
of each rule, but there is a limit of 20 rules, if that is
exceeded, it should give up and just use the bbox as the
filter. Indeed, I can confirm it's an issue, there is a bug
in the query building code inside the WMS renderer:
http://jira.codehaus.org/browse/GEOS-2781

I hopefully fixed it, can you double check by downloading
a nightly build starting from March 26? (the March 25 one
does not contain the fix):
http://gridlock.openplans.org/geoserver/1.7.x/

[Pedro Mendes] I'll do that.

And... was the problem actually solved? (don't remember)

[Pedro Mendes] I think so:
http://www.nabble.com/WFS-T-oracle-update-faild-on-GS-1.7.2-tp22331042p22331
042.html

Hmmm... nowhere. The extensions and GeoServer are developed hand in
hand, so an extension made for GeoServer 1.7.3 won't work for GeoServer
1.7.2.
OpenGeo provides the service of making custom bugfix build out
of older branches for customers of its support contract (among other
things).
Also, if you want to build your own, we can point you at the relevant
branches and the diffs and you can do the backport yourself.

Generally speaking, if anybody is interested in making custom bugfix
builds and share them with the community (say, release a 1.7.2.1,
1.7.2.2 and so on) we'll be happy to assist the effort providing
directions on how this can be done.

[Pedro Mendes] For the moment we'll just keep waiting for the bugs fix in
the nightly/stable versions.

------------------------------------------------------------------------------
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
View this message in context: http://www.nabble.com/SLD-Too-many-rules-filters--tp22684181p22780668.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Andrea_Aime3 · March 30, 2009, 3:02pm

Pedro Mendes ha scritto:

Just tried out the nightly builds from days 26, 27 and 30 of March. The bbox
filter fix for SLD rules number greater than 20 works properly. But those
SLD that have less than 20 rules, only the first rule filter for a certain
scale it's picked up.

Right, managed to reproduce the issue, and fixed it.
Shame on me, this time I added a unit test to cover for this problem.
Can you try again tomorrow with the new nightly build?

Cheers
Andrea

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

Pedro_Mendes2 · March 31, 2009, 11:50am

Hi Andrea,

Well done, I confirm the issue is fixed! But now another problem has just
appeared... Has i explained before in previous posts we're using
textsymbolizers to render symbols of our custom TTF. What's happening now is
that the symbols are render with a slight displacement as shown in picture.
http://www.nabble.com/file/p22803498/1.jpg
You can also see i've render a geometry point layer using capitals.sld which
use PointSymbolizer to render geometries and this one is displayed
correctly. I already tried out "Using decorative True Type fonts as markers"
implementation but I've got no good results with our custom TTF: several
different hexadecimal codes from the TTF always output the same symbol, a
strange square which doesn't even exists. I'm only getting the expected
output when trying different symbols (hexadecimal codes) from Wingdings..The
Arial TTF also outcomes the same results as our custom TTF.
So, I'm kinda on a dead end: with TextSymbolizers, symbols aren't render
where they supose to, with PointSymbolizer, always the same symbol an
unexisting square...

Note: we've several layers displaying regular text labels styled out with
TextSymbolizers and they all work right. The highlight shown in the picture
is the geometry on a vector layer.
http://www.nabble.com/file/p22803498/2.jpg

Andrea, some ideas on this one?

regards,
Pedro Mendes

Andrea Aime-4 wrote:

Right, managed to reproduce the issue, and fixed it.
Shame on me, this time I added a unit test to cover for this problem.
Can you try again tomorrow with the new nightly build?

--
View this message in context: http://www.nabble.com/SLD-Too-many-rules-filters--tp22684181p22803498.html
Sent from the GeoServer - User mailing list archive at Nabble.com.