Javier de la Torre wrote:
Hi,
I am using an SLD with filers inside the Rules to represent the features with different colors depending on a feature property. I also have the possibility to filter all features based on a user search. The problem I have is that Geoserver currently does not support <LayerFeatureConstraints>
so I have to repeat in each Rule the same user filter. Considering that I have two NamedLayers I have to repeat the same filter 8 times in the SLD (4 Rules * 2 NamedLayers).
I am exclusively presenting the NameLayers based on Max-Min- ScaleDenominator so in theory only one of the layers should be processed.
Unfortunately this gets horribly slow with Geoserver taking all processing power, I suppose filtering features.
I am about to create a "dynamic" SLD using PHP where I pass parameters to help constructing much smaller SLDs based for example in the scale (or where I previously query the database and give a set of FeatureIds that must be presented to the SLD).
I would like to know how is Geoserver interpreting the SLDs in order to give him more friendly SLD constructions.
1) Is the MaxScaleDenominator processed before anything else? I mean, if the scale does not match are the filters still processed or resolved?
Yes, sez Dave. There is a class called LiteFeatureTypeStyle which does this. It pre-determines which rules should be applied.
From the comment:
* Basically, for a SLD, you create one of these for each of the
* FeatureTypeStyles inside it. LiteRenderer uses this to do the
* actual renderering.
*
* It contains:
* a. a BufferedImage so lite knows where to do the drawing
* b. a list of rules (minimal # -- ie. remove the ones that dont apply to this scale)
* c. "else" rule list
*
* To process this, you would
* a) foreach FEATURE
* b) foreach LiteFeatureTypeStyle
* c) <process rules and draw to the appropriate image>
* d) combine the images
*
* This was setup so you can "parallelize" literenderer in the simple
* way -- only read data once. The old implementation would re-read
* the data for each one FeatureTypeStyle.
2) When a filter has the form of something like:
property1 < 100 and property2 >10 and property3 like 'value'
Is the filtering in Geoserver (Geotools?) going to check property3 like 'value' even if property1 < 100 and property2 >10 fail? Does grouping the conditions help, something like:
((property1 < 100 and property2 >10) and property3 like 'value')
It would appear no: http://svn.geotools.org/geotools/branches/2.2.x/module/main/src/org/geotools/filter/LogicFilterImpl.java
has:
} else if (filterType == LOGIC_AND) {
contains = true;
while (iterator.hasNext()) {
contains = ((Filter) iterator.next()).contains(feature)
&& contains;
}
}
}
Could be optimized to return false at the first contains encountered that is false.
I think the thought in general is that filters should be passed back to the db as much as possible. Of course that doesn't work any longer when SLD filters aren't passed back to the DB.
Dave sez that in 2.2.x we actually do pass filters back in to the db. There's a maxFiltersToSendToDatastore param (default to 5, no way to set it without getting in to code right now). It does:
// first we check to see if there are > "getMaxFiltersToSendToDatastore" rules
// if so, then we dont do anything since no matter what there's too many to send down.
// next we check for any else rules. If we find any --> dont send anything to Datastore
// next we check for rules w/o filters. If we find any --> dont send anything to Datastore
//
// otherwise, we're gold and can "or" together all the fiters then AND it with the original filter.
// ie. SELECT * FROM ... WHERE (the_geom && BBOX) AND (filter1 OR filter2 OR filter3);
Note this is only in 2.2.x, and thus only available in 1.3.1beta. So it looks like we're going to have to do some serious debugging to figure out the problem with open postgis connections. This may be one of the things that does it.
Maybe we could set up a time next week to chat and have a debug session?
3) Someone asked some days ago about a way to do InList filters I think... what is the limit of this? How many elements could I include in such a filter? Would it perform well? (this is for the idea of pre- filtering in PHP)
There is no way to do InList filters, except against featureids. I don't think there's a limit to this. If passed back in to a db it will likely perform very well. If not it will probably perform pretty poorly.
If anybody has more ideas, advices on ways of improving performance on complicate SLDs I would be very happy to hear about them.
Looks like the main advice is to upgrade to 1.3.1beta. Dave did a bunch of work to squeeze more performance from stuff.
Chris
Thanks in advance.
Javier.
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org