[Geoserver-devel] Pluggable style languages

GeoServer GeoServer Developer
1

Hi all,

I have been working on making GeoServer capable of storing styles natively in alternate languages. The most obvious use case being a better integration for the css styling extension. The work is worth a GSIP but I wanted to post here to start some initial discussion before doing up the first draft of the proposal.

For the impatient the current state of the work can be found here:

https://github.com/jdeolive/geoserver/compare/style-plug

The approach is to create an extension point named “StyleHandler” (which will replace the current “Styles.Handler” enum) that can parse, encode, and validate styles. With the new extension point the task then becomes updating all the bits around it. Which will require some changes to a few different subsystems.

Catalog/Config

A couple of changes to StyleInfo:

  1. An additional property: the style format/language identifier
  2. Changing the “SLDVersion” property to the more generic “FormatVersion” property.

WMS

To support styles directly in a WMS request (via SLD or SLD_BODY) the idea is to add an additional “STYLE_FORMAT” parameter to identifier the format. In the implementation I have now i have continued to use SLD and SLD_BODY parameters for the style content, even though in non SLD cases it is a misnomer. We could add more generic parameters and make the SLD specific ones an alias for them… what do folks prefer?

Web UI

What I have done thus far is simply add a format field to the style editor page. When creating a new style the user can choose the style format.

https://www.evernote.com/shard/s222/sh/76cb558c-b7d4-457a-9f93-4281ff631d2f/88f76db60e5d93212fa5551a0e20cc0f

In the interest of simplicity I thought it best to simply disable the drop down when editing a style:

https://www.evernote.com/shard/s222/sh/fa4aace6-2e58-4c99-9000-27595e1f94b8/24c790ea34050cf7a5ce6361fe23f142

Rationale being that since style handlers might not support both parsing and encoding, like the css module transforming the same style between formats would be tricky.

Rest API

The final bit is the rest api. Nothing too exciting here except that now folks will be able to upload files in different formats.

That is about it… let me know what you think!

-Justin

–

Justin Deoliveira
VP Engineering | Boundless
jdeolive@anonymised.com
@boundlessgeo

2

On Thu, Jul 10, 2014 at 8:45 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Hi all,

I have been working on making GeoServer capable of storing styles natively
in alternate languages. The most obvious use case being a better
integration for the css styling extension. The work is worth a GSIP but I
wanted to post here to start some initial discussion before doing up the
first draft of the proposal.

For the impatient the current state of the work can be found here:

  https://github.com/jdeolive/geoserver/compare/style-plug

The approach is to create an extension point named "StyleHandler" (which
will replace the current "Styles.Handler" enum) that can parse, encode, and
validate styles. With the new extension point the task then becomes
updating all the bits around it. Which will require some changes to a few
different subsystems.

Sounds reasonable.
About CSS, how do you do the encoding? Afaik the only path available is the
css -> sld translation, but we don't have a way to parse and re-encode
(pretty-print) the css

*Catalog/Config*

A couple of changes to StyleInfo:

  1. An additional property: the style format/language identifier
  2. Changing the "SLDVersion" property to the more generic
"FormatVersion" property.

*WMS*

To support styles directly in a WMS request (via SLD or SLD_BODY) the idea
is to add an additional "STYLE_FORMAT" parameter to identifier the format.
In the implementation I have now i have continued to use SLD and SLD_BODY
parameters for the style content, even though in non SLD cases it is a
misnomer. We could add more generic parameters and make the SLD specific
ones an alias for them... what do folks prefer?

"Captain obvious" would say "STYLE" and "STYLE_BODY". Styles is taken,
style is not though.

*Web UI*

What I have done thus far is simply add a format field to the style editor
page. When creating a new style the user can choose the style format.

https://www.evernote.com/shard/s222/sh/76cb558c-b7d4-457a-9f93-4281ff631d2f/88f76db60e5d93212fa5551a0e20cc0f

In the interest of simplicity I thought it best to simply disable the drop
down when editing a style:

https://www.evernote.com/shard/s222/sh/fa4aace6-2e58-4c99-9000-27595e1f94b8/24c790ea34050cf7a5ce6361fe23f142

Rationale being that since style handlers might not support both parsing
and encoding, like the css module transforming the same style between
formats would be tricky.

Yeah, makes sense to me. As an alternative, allow change but warn the user
that the contents will be wiped out, or that
the translation is not an invertible process (e.g., css -> sld, sld -> css
not right not, and if we coded it it would not give
us back necessarily the same original style).

*Rest API*

The final bit is the rest api. Nothing too exciting here except that now
folks will be able to upload files in different formats.

How about the current reformatting behavior that made some users mad, would
it be there for all style types?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

3

Do we need to throw legend graphic into the mix here Justin? We have a few sections of code where an SLD is scanned to produce a graphic.

···

Jody Garnett

On Thu, Jul 10, 2014 at 11:45 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I have been working on making GeoServer capable of storing styles natively in alternate languages. The most obvious use case being a better integration for the css styling extension. The work is worth a GSIP but I wanted to post here to start some initial discussion before doing up the first draft of the proposal.

For the impatient the current state of the work can be found here:

https://github.com/jdeolive/geoserver/compare/style-plug

The approach is to create an extension point named “StyleHandler” (which will replace the current “Styles.Handler” enum) that can parse, encode, and validate styles. With the new extension point the task then becomes updating all the bits around it. Which will require some changes to a few different subsystems.

Catalog/Config

A couple of changes to StyleInfo:

  1. An additional property: the style format/language identifier
  2. Changing the “SLDVersion” property to the more generic “FormatVersion” property.

WMS

To support styles directly in a WMS request (via SLD or SLD_BODY) the idea is to add an additional “STYLE_FORMAT” parameter to identifier the format. In the implementation I have now i have continued to use SLD and SLD_BODY parameters for the style content, even though in non SLD cases it is a misnomer. We could add more generic parameters and make the SLD specific ones an alias for them… what do folks prefer?

Web UI

What I have done thus far is simply add a format field to the style editor page. When creating a new style the user can choose the style format.

https://www.evernote.com/shard/s222/sh/76cb558c-b7d4-457a-9f93-4281ff631d2f/88f76db60e5d93212fa5551a0e20cc0f

In the interest of simplicity I thought it best to simply disable the drop down when editing a style:

https://www.evernote.com/shard/s222/sh/fa4aace6-2e58-4c99-9000-27595e1f94b8/24c790ea34050cf7a5ce6361fe23f142

Rationale being that since style handlers might not support both parsing and encoding, like the css module transforming the same style between formats would be tricky.

Rest API

The final bit is the rest api. Nothing too exciting here except that now folks will be able to upload files in different formats.

That is about it… let me know what you think!

-Justin

–

Justin Deoliveira
VP Engineering | Boundless
jdeolive@anonymised.com
@boundlessgeo

Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

On Fri, Jul 11, 2014 at 7:21 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Do we need to throw legend graphic into the mix here Justin? We have a few
sections of code where an SLD is scanned to produce a graphic.

A GeoTools Style object is scanned, as long as any language can go towards
a Style representation we're good.
When we'll have one that does not well... we'll have much larger problems
(like having to rewrite the renderer to support it)

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

5

On Fri, Jul 11, 2014 at 2:23 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Thu, Jul 10, 2014 at 8:45 PM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:

Hi all,

I have been working on making GeoServer capable of storing styles
natively in alternate languages. The most obvious use case being a better
integration for the css styling extension. The work is worth a GSIP but I
wanted to post here to start some initial discussion before doing up the
first draft of the proposal.

For the impatient the current state of the work can be found here:

  https://github.com/jdeolive/geoserver/compare/style-plug

The approach is to create an extension point named "StyleHandler" (which
will replace the current "Styles.Handler" enum) that can parse, encode, and
validate styles. With the new extension point the task then becomes
updating all the bits around it. Which will require some changes to a few
different subsystems.

Sounds reasonable.
About CSS, how do you do the encoding? Afaik the only path available is
the css -> sld translation, but we don't have a way to parse and re-encode
(pretty-print) the css

Yeah, since there is no GeoTools Style Object -> CSS encoding that is
basically a no-op in that handler for now. So anything that requires we
encode the style (which I think may only be rest?) wont work with css.

*Catalog/Config*

A couple of changes to StyleInfo:

  1. An additional property: the style format/language identifier
  2. Changing the "SLDVersion" property to the more generic
"FormatVersion" property.

*WMS*

To support styles directly in a WMS request (via SLD or SLD_BODY) the
idea is to add an additional "STYLE_FORMAT" parameter to identifier the
format. In the implementation I have now i have continued to use SLD and
SLD_BODY parameters for the style content, even though in non SLD cases it
is a misnomer. We could add more generic parameters and make the SLD
specific ones an alias for them... what do folks prefer?

"Captain obvious" would say "STYLE" and "STYLE_BODY". Styles is taken,
style is not though.

Works for me!

*Web UI*

What I have done thus far is simply add a format field to the style
editor page. When creating a new style the user can choose the style format.

https://www.evernote.com/shard/s222/sh/76cb558c-b7d4-457a-9f93-4281ff631d2f/88f76db60e5d93212fa5551a0e20cc0f

In the interest of simplicity I thought it best to simply disable the
drop down when editing a style:

https://www.evernote.com/shard/s222/sh/fa4aace6-2e58-4c99-9000-27595e1f94b8/24c790ea34050cf7a5ce6361fe23f142

Rationale being that since style handlers might not support both parsing
and encoding, like the css module transforming the same style between
formats would be tricky.

Yeah, makes sense to me. As an alternative, allow change but warn the
user that the contents will be wiped out, or that
the translation is not an invertible process (e.g., css -> sld, sld -> css
not right not, and if we coded it it would not give
us back necessarily the same original style).

*Rest API*

The final bit is the rest api. Nothing too exciting here except that now
folks will be able to upload files in different formats.

How about the current reformatting behavior that made some users mad,
would it be there for all style types?

Right... this is because we don't pull the style file directly from the
disk and dump it out. I guess we could do that in the case where the
requested format matches the native format of the style. And attempt a
transformation from one format to the other when it is not?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

--
Justin Deoliveira
VP Engineering | Boundless <http://boundlessgeo.com/&gt;
jdeolive@anonymised.com
@boundlessgeo <http://twitter.com/boundlessgeo/&gt;