[Geoserver-devel] Setting the map background color in the style (small change from OGC Testbed 15)

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? :smiley:
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):
FFAA00 ...

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? :slight_smile:

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.

No objections, great to have a useful solution. Is the opacity of the background color also defined?

Out of curiosity why as part of a single UserStyle, since an SLD may have several? Would it make sense to provide a background color as part of StyledLayerDescriptor which describes an entire
map with several layers?

···


Jody Garnett

No objections, great to have a useful solution. Is the opacity of the background color also defined?

It is not.

Out of curiosity why as part of a single UserStyle, since an SLD may have several? Would it make sense to provide a background color as part of StyledLayerDescriptor which describes an entire
map with several layers?

That is a valid point… we are targeting multi-layer vector tiles, and the styles can also be defined as a single UserStyle with many FeatureTypeStyle
inside, each targeting a different feature type.
The issue is that SLD allows to target layers both at the level of UserStyle/NamedLayer at inside the UserStyle… should probably be handled in both cases…

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.

Hi Ian,

they are still going through a GetMap of sorts, the Maps API equivalent, and the Tiles API is also going to have
a bgcolor parameter, and a transparent parameter.

A trick that is being discussed is that tiles would be rendered and cached as transparent, but with a transparent
color that happens to be the background color with zero opacity. In case no opacity is requested, the tile server
can simply read the tile and flip the alpha information in the palette (or change the pixels in case of full RGB),
and in case of different color, swap the color in the palette or change the transparent pixels accordingly.
Of course that would come with some overhead (decoding and re-encoding PNGs is not fast) but less expensive
than rebuilding the tile from scratch.

None of that would be feasible with JPEG compression though.

This is still ongoing discussion, it may or may not end up in a standard, but still find the ability to set a bgcolor
without going through a “giant polygon” useful.

Cheers
Andrea

···

Regards, Andrea Aime == 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.

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

···

Torben Barsballe

Software Engineer
Planet Federal
tbarsballe@anonymised.com

Was reading the mapbox style documentation here and wanted to double check this thread to confirm if background layer “basic functionality” is actually supported.

It looks like it is, backgroundImgStyleTest.json, and I need to update the documentation.

···


Jody Garnett

Yes, that is correct.

Cheers
Andrea

Il lun 14 set 2020, 04:02 Jody Garnett <jody.garnett@…403…> ha scritto:

Was reading the mapbox style documentation here and wanted to double check this thread to confirm if background layer “basic functionality” is actually supported.

It looks like it is, 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.aime@anonymised.com> 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? :smiley:
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):
FFAA00 ...

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? :slight_smile:

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-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Torben Barsballe

Software Engineer
Planet Federal
tbarsballe@anonymised.com


GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel