Thanks for the detailed discussion, I wondered if we would end up going in
this direction the moment I saw the CSS syntax.
That is a pretty deep change, I would feel better about hacking at this
level if the SLD specification was alive (and we had a line of
communication so we could tell what is coming).
Thoughts:
- Kind of wish SLD was more specific about the two pass nature ("rules
produce list of symbolizers", "symbolizers used to draw").
- You suggestion of an evaluation mode is similar to how a filter else
rules behaves (append these symbolizers if the list is empty) in this case
trying to special case "first".
- CartoDB (the original CSS styles) are stepping away from the CSS model
and moving to an OpenGL model (to better make use of client side styling)
- Do we have any other evaluation modes that make sense?
- would make more sense to mark the rule rather then the individual
symbolizers?
Jody Garnett
On Sun, Nov 30, 2014 at 1:06 PM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:
> 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
>
>
------------------------------------------------------------------------------
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
