Skip to content

GSIP 117

Jump to bottom
Jody Garnett edited this page Jul 24, 2014 · 2 revisions

GSIP 117 - Pluggable Styles

Overview

Proposed By

Justin Deoliveira

Assigned to Release

This proposal is for GeoServer 2.6-beta.

State

  • Under Discussion
  • In Progress
  • Completed
  • Rejected
  • Deferred

Motivation

Historically GeoServer has supported styles encoded in a single language, the original SLD 1.0 format. However more recently additional style formats have emerged, most notably the CSS styling language.

At the moment using the CSS extension means first translating to the SLD representation and then having GeoServer consume the file through the regular means. This is less than ideal for a number of reasons.

  1. It requires us to maintain the CSS style separately, risking it going out of sync with the translated SLD representation.

  2. It doesn't tie in to existing workflows that involve working with styles such as editing styles from the UI, POSTing styles through RESTConfig, etc....

This proposal is to make GeoServer capable of consuming styles in other languages natively though a pluggable interface. The goal of which is to provide a smoother integration for the CSS extension, and to pave the way for possible future styling languages as well.

Proposal

StyleHandler Extension Point

The heart of the proposal is the addition of a new extension point named "StyleHandler" that encapsulates all style operations such as parsing, validating and encoding.

The current version of the extension point class can be found here.

With implementations for the SLD and CSS formats:

StyleInfo

In order to store styles natively in a different language the StyleInfo interface must be updated with some additional properties.

  • format - Tracks the format of the style
  • formatVersion - Tracks the version of the format of the style. This proposal replaces the existing "SLDVersion", which will be deprecated

WMS and GetMapRequest

To support styles directly specified in a WMS request three additional key value pair parameters will be supported for GetMap requests:

  • STYLE_URL - The equivalent of "SLD", made generic for formats other than SLD. Note: the name "STYLE" was not used to prevent confusion with the existing "STYLES" key value pair.
  • STYLE_BODY - The equivalent of "SLD_BODY".
  • STYLE_FORMAT - Format identifier.
  • STYLE_VERSION - Format version.

The "SLD", "SLD_BODY", and "SLD_VERSION" parameters will continue to be supported and will be treated as aliases for the more generic equivalents.

Web UI

The initial implementation will be a new drop down field for new styles allowing a user to choose the format of a new style. For existing styles the drop down will remain read-only.

Future improvements upon this functionality can include the ability to transform styles between formats (if a translation path exists) on the fly.

RESTConfig

Finally the RESTConfig api will be updated to utilize the new extension point to allow GET, PUT, and POST operations to operate with new formats.

One change worth mentioning is to the /styles endpoint for GET requests. Since it is not a requirement for StyleHandler implementations to support encoding a check is made during GET requests if the format being requested matches the one natively on disk. If they match rather than encoding the parsed style object the style contents is streamed out directly from disk.

Feedback

  • Have StyleHandler work directly with Styles, rather than StyledLayerDescriptor.
  • Stream styles on PUT/POST in addition to GET to preserve style formatting.

Backwards Compatibility

All changes proposed for this proposal are 100% backwards compatible.

Voting

Project Steering Committee:

  • Alessio Fabiani:
  • Andrea Aime: +1
  • Ben Caradoc-Davies:
  • Christian Mueller:
  • Gabriel Roldán:
  • Jody Garnett: +1
  • Jukka Rahkonen: +1
  • Justin Deoliveira: +1
  • Phil Scadden: +1
  • Simone Giannecchini: +0

Links

©2020 Open Source Geospatial Foundation

Home
Proposals
Release Schedule

Clone this wiki locally