Hey Andrea, that looks great.
Here's an idea, instead of two vendor options, use a single one with enum values, like in: <VendorOption name="inclusion">normal|legend_only|map_only</VendorOption> with "normal" being the default -included both for legend and map rendering- (call it "default" or "both"). On Wed, 24 Mar 2021 at 07:16, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > Hi, > I'm writing this mail to discuss an option to improve styles usage in map > rendering and legend generation. > Since it involves changes in both GeoTools and GeoServer, I'm cross > posting the two devel lists (sorry!). > > It all starts with being able to control the appearance of a legend in > GeoServer, while retaining dynamic > abilities that a static image legend does not offer, in particular: > > - A static legend cannot be configured for layer groups > - A static legend cannot be content dependent, that is, based on the > current bounding box contents (match counting and rule elimination) > - A static legend does not offer any support for multi-linguism > (multiple legends would have to be created and associated by language) > - A style can be used to generate a JSON representation of a legend, > to be rendered client side. > > Now, some systems, like CARTO, offer a separate language to setup legends: > https://carto.com/help/tutorials/builder-legends-overview/ > > Without having to get there, a simpler approach would be to mark feature > type styles and rules in a style, as targets > for map rendering or map generation: > > - Some bits of the SLD can be shared among map rendering and legend > generation (the common case, no new vendor options for it, it's what we are > already doing) > - Some bits should be used for map rendering, but turned off for > legend generation, as they only cause visual noise in the legend (symbol > too small, too big, road casing via FTS generating separate legend entries > while visually the symbol is one) > - Some bits should be used for legend generation, as they provide > better symbol in the context of a legend (e.g. a single fixed width circle, > or multiple rules with examples using different circle sizes), but not be > used in the map generation (where the width is picked by an attribute value > on the fly) > > To handle the last two cases, two new vendor options would be added to > feature type style, rule and symbolizer (as usual, open to better names): > > - <VendorOption name="renderingLegend">false</VendorOption> > - <VendorOption name="renderingMap">false</VendorOption> > > Elimination of the bits that are not meant for a particular target can be > implemented using a DuplicatingStyleVisitor subclass > that would pre-process the style before it's being used. > > While this approach makes styles longer, it also allows to keep everything > in one place, making the life of who's editing > the styles easier (map and legend rules for the same symbol can be kept > back to back, hopping from one to the other while editing). > > Now, implementation is easy, but there is a catch: Rule today does not > have an option map. > Hence, I wrote a proposal for that one API change, see separate mail for > it (this one, available only on geotools-devel). > > Cheers > Andrea > > == GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it http://twitter.com/geosolutions_it > ------------------------------------------------------- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le > sarei comunque grato se potesse darmene notizia. This email is intended > only for the person or entity to which it is addressed and may contain > information that is privileged, confidential or otherwise protected from > disclosure. We remind that - as provided by European Regulation 2016/679 > “GDPR” - copying, dissemination or use of this e-mail or the information > herein by anyone other than the intended recipient is prohibited. If you > have received this email by mistake, please notify us immediately by > telephone or e-mail.* > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Gabriel Roldán
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
