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
