Yes, that is correct. Cheers Andrea
Il lun 14 set 2020, 04:02 Jody Garnett <jody.garn...@gmail.com> ha scritto: > Was reading the mapbox style documentation here > <https://docs.geotools.org/latest/userguide/extension/mbstyle/spec/layers.html#background> > and wanted to double check this thread to confirm if background layer > "basic functionality" is actually supported. > > It looks like it is, backgroundImgStyleTest.json > <https://github.com/geotools/geotools/blob/master/modules/extension/mbstyle/src/test/resources/org/geotools/mbstyle/backgroundImgStyleTest.json>, > and I need to update the documentation. > > -- > Jody Garnett > > > On Mon, 16 Sep 2019 at 15:46, Torben Barsballe via GeoTools-Devel < > geotools-devel@lists.sourceforge.net> wrote: > >> This sounds like a great plan to me, and once implemented in SLD would be >> good to replace MBStyle's rather hacky solution with something more proper. >> Considering other GeoServer styling languages: >> >> - YSLD is basically just SLD, but having backgroundColor at the >> UserStyle level would probably look the cleanest for most ysld styles, >> since it can ignore any higher level structure. E.g.: >> >> name: style_example >> background-color: #0000FF >> feature-styles: >> - rules: >> - name: all >> symbolizers: >> - polygon: >> fill-color: '#808080' >> fill-opacity: 0.5 >> stroke-color: '#000000' >> stroke-opacity: 0.75 >> >> >> - I'm not as familiar with the CSS extension, but I don't think there >> would be any problems there regardless of the solution >> >> One minor quibble - I'd prefer it if the final name of the SLD tag was >> either BackgroundColor or BgColor rather than BGColor - CamelCase does not >> work well with abbreviations. >> >> Cheers, >> Torben >> >> >> On Wed, Sep 11, 2019 at 10:23 AM Andrea Aime < >> andrea.a...@geo-solutions.it> wrote: >> >>> Hi, >>> in Testbed 15 we are asked to implement a way to set the map background >>> color in the >>> style itself, at least for styles that are meant to be used as basemaps. >>> >>> The SLD specification does not allow for that, which makes sense in the >>> context of "overlay" WMS, >>> with a client deciding the set of layers to be displayed, and >>> controlling the background color from the >>> GetMap itself. >>> >>> However, the need to set the background color is real and we have seen >>> in GeoServer since the >>> beginning: anyone forgot about the "giant_polygon" layer used in the NYC >>> demo layer group? :-D >>> Looking at the MBStyles code I see a similar solution, the code is >>> taking the bgcolor specification >>> found in Mapbox GL and turning it into a inline user style with a GML >>> giant polygon defined inside. >>> >>> The giant polygon approach has been labelled as clumsy and ineffective, >>> and indeed, I have to agree: >>> >>> - Why expose a dedicated, user visible layer with a massive polygon >>> just to set the color of the painting canvas >>> - Reprojection issues abund when going to local projections, the >>> advanced projection handling help here by cutting the geometry, but it's >>> not available for all projections >>> >>> The idea proposed in the testbed is to add a BGColor element inside >>> UserStyle that would allow setting the background >>> color for the entire style (imagine a multi-layer stylesheet, also known >>> as style group, in GeoServer): >>> >>> <UserStyle> >>> <BGColor>FFAA00</BGColor> >>> ... >>> </UserStyle> >>> >>> The idea seems useful and has no backwards compatibility issues, so I'd >>> like to implement it, at least in the >>> SLD parser, to give a simple solution to.. well... a simple problem. >>> The renderer would then simply use the information to paint the canvas >>> with the first bgcolor found in the layer stack. >>> If the map is requested to be transparent (&transparent=true) then it >>> would ignore the bgcolor, allowing the layers >>> to be used both as suitable backgrounds but also as overlays >>> >>> Objections? :) >>> >>> 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.* >>> _______________________________________________ >>> Geoserver-devel mailing list >>> geoserver-de...@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >> >> >> -- >> Torben Barsballe >> Software Engineer >> Planet Federal >> tbarsba...@federal.planet.com >> _______________________________________________ >> GeoTools-Devel mailing list >> GeoTools-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
