Hi,
while working on the CSS to SLD transator I've stumbled into a
performance issue that could be easily solved if we added a slightly
different matching mode in the SLD evaluation chain.
In CSS the rules cascade, it means that all applicable rules are applied
and concur to generate a single set of symbolizers, e.g., if 10 rules
compete to define the aspect of a point symbolizer, only one will be
generated, and its contents will depend on the rule selectivity (the
highest one covers the definition of the second highest, and so on).
In SLD instead, the 10 matching rules will be applied in sequences, the
first
one will paint its symbolizer, the second one too, and so on, until
all of them have painted their symbol, each on top of the previous ones.
>From the SLD 1.0 spec:
------------------------------
Filters used in different Rules applicable to the same FeatureTypeStyle are
allowed to overlap in terms of the features selected by each rule. The map
styler must
execute all rules that are applicable to a feature in the order that the
rules appear. For
example, if one rule for a user style has the (SQL) condition “num_lanes >=
6” and a
subsequent rule has the condition “num_lanes >= 4”, then all roads with
four or more
lanes would cause both rules to “fire”
------------------------------
Nowadays the CSS to SLD approaches we have (gt-css and geoscript Scala)
all generate the power set of CSS rules, to setup all possible combinations,
and then go though a process of elimination (I call it domain coverage) to
make sure the combination with the highest selectivity generates one rule,
the second one generate one or more rules in the areas of the scale/data
domains not covered by the first one, and so on, until all rule combinations
are either eliminated because their domain is already covered, or turned
into equivalent SLD rules.
Now, this process is complex, but most importantly, very expensive when the
original set of CSS rules is "large".
It must be done only once for sure, but we stumbled into real world cases
in which the conversion takes too much time.
Point in case, a 21 rules CSS style, all against a single feature type,
driving the styling of features on a cross of 7 scale range selections,
4 possible values of one variable, 3 possible values of another,
and 2 more ranges of yet another one.
The power set theoretically generates 21! combinations, that is,
51090942171709440000, the filtered power set in gt-gss actually
generates "only" 540, which are then tamed down to around 150 by
post processing involving, at least partly, the domain coverage.
The issue is, the whole process takes around 2 minutes, which is too much
time
(the CSS to SLD trasformation should be interactive, at least for what we'd
like to do in GeoServer), almost all of it spent going down from the 540 to
the 150 via the domain coverage (mind, a good set of these rules are
actually eliminated via a much simpler process that does not require
computing the domain coverage, but for those that do, eh, it's hard).
Originally it took much longer, I've spent time optimizing the process,
adding caching and so on, but 2 minutes is still too long.
One approach that was suggested in the past was to avoid doing the expensive
conversion, and just have a "cascading" mode for SLD as well.
This sounds interesting in theory, but it would throw away a good amount of
optimizations
we built into the styling engine because it would require to build the
Style2D objects
almost afresh for each incoming feature, leading to a large amount of
garbage generation,
not to mention a good amount of changes in the rendering subsystem.
To give you a term of reference, avoiding the generation of Style2D objects
and
creating a cache of them was one the very first optimization we made
something like
10 year ago (give or take, did not check the exact date)
because it was the one that was showing as the highest offender in profiles,
even before the light coordinate sequence, the many optimizations to the
shapefile
reader, the shapefile renderer, screenmap, and so on.
However, there is a simpler way... we just need to tell the renderer to stop
processing a feature the moment the first rule matches, if we do that, we
don't
really need to compute the domain coverage, we can just generate the SLD
rules as they come out of the gt-css filtered power set, plus some light
post
processing to remove the obvious duplicates.
I propose we move along this path, and allow people to select the mode of
rule evaluation by adding a VendorOption list of tags inside
FeatureTypeStyle,
just like we added them into Symbolizer:
<VendorOption name="evaluationMode">firstMatch</VendorOption>
I've made some quick tests, the changes in the generated SLDs are not
dramatic,
but the time to generate it goes down from 2 minutes to around 3 seconds
(cold
VM, CSS -> SLD processing done from a command line invocation of a Java
"main").
The option is imho of general utility as well, despite how SLD works, I
believe most
people tend to setup styles so that only one rule matches anyways, telling
the
rendering engine that is the case will speed up also maps written direclty
in SLD.
We could also have an option in the CSS -> SLD converter to allow people to
choose
the conversion mode between an exhaustive mode that uses domain coverage,
and a more expiedient one that just relies on the first match behavior,
suitable
for the larger styles.
Feedback welcomed
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
