Styler Introduction

Styler is under development by  OpenGeo. See the  current demo or get it as part of the  OpenGeo Suite. The latest develpment version is available from SVN.

Styler's goal is to democratize cartography – making it easy for anyone to make a map look the way they want it to. This could be as simple as tweaking some colors to match the aesthetics of their website. Or it could mean composing a new map from many different sources with a design that emphasizes the point a user is making with her data. For example, a user could combine data about air quality with data about asthma rates to create a map about public health outcomes near highways.

Our goal is to improve the usability of the styling components of general GIS applications and optimize the experience for web mapping. This means Styler will be a completely web-based application built completely with Javascript, leveraging the OpenLayers and GeoExt libraries, so as to work in any browser. It also leads to a different design focus, optimizing the user experience around setting zoom levels for web map exploration, instead of the traditional GIS emphasis on a single zoom level for printed maps. Styles will also all be open and able to be remixed, so that a user can take someone else's map as a base and change it to suit their purposes, rather than having to start from scratch.

Styler is built on open standards, using the Styled Layer Descriptor (SLD) XML language at the center. It is rendered with the Web Map Service (WMS) standard, which has extensions to render remote SLDs, and uses REST calls to persist styles to servers. It is built with GeoServer as an initial target, but the emphasis on open standards and flexible design should make it adaptable to any WMS server.

The initial release is a standalone application to edit the default styles in GeoServer, but future versions will simply be a set of components that could be used in any GeoExt applications. When that happens the core Styler code base should live in GeoExt, with extensions to talk to various servers (GeoServer, MapFish/Pylons, etc).

Styler Roadmap

This roadmap contains an overview of the anticipated directions, with links to more detailed design specifications and tickets for software development. There are no set dates on the roadmap, but anyone is welcome to build the components or contract out a developer who will commit to a deadline. The order is not definitive at all, and indeed will shift according to funding. Check out our comprehensive list of design proposals and don't hesitate to raise other ideas for features and directions on the  mailing list.

Symbolizer improvements

In order to support features like roads with outlines, we need the ability to define more than one symbolizer on a rule. Right now there is an assumption that each rule only has one symbolizer. This is not a constraint of SLD, just on what we've built thus far. The first release of Styler also does not support all the potential options for SLD strokes and labels. These should be accessible in the UI, to give users full control over their output.

Design proposal: Symbolizers
Implementation details: Meta-ticket #39

Image Manager

Currently the management of remote images is not very intuitive. Users must select 'external' from a drop down menu, and then fill in a URL to an image on the web. Many however may not know of a good set of images on the web, or they may only have images on their desktop. A good Image Manager should easily present a set of default images, plus ones that others are using on the same server. It should also have nice upload capabilities, for users with appropriate permissions to upload their images to the server, where they may be available to others. An advanced image manager would handle lots of images well, perhaps presenting them as groups, and make it easy to add another whole group on the web (like Google's KML images).

Design proposal: Image Manager
Implementation details:

Integration with GeoExt toolkit

Right now Styler is a standalone application. It should instead be built to be a set of components for GeoExt, with the 'Styler application' simply being a collection of GeoExt components that allow users to pick layers, log-in, and edit the styles. This work item includes the GeoExt components needed to support a Styler application, and the integration of Styler code in to the  official GeoExt codebase.


  • AttributesReader #46
  • AttributesStore #47
  • ColorField #48
  • ComparisonComboBox #49
  • FontComboBox #50
  • FeatureRenderer #51
  • symbolizers #52
  • FilterPanel #53
  • FilterBuilder #54
  • ZoomSlider #55
  • MultiSlider #56

More labeling options

GeoServer supports a number of vendor specific options for labeling (grouping, displacement, follows, line breaks, etc) that should be controllable from Styler. Ideally Styler will be able to detect what type of server is doing the rendering of SLD, and would not make available vendor options that the server does not support.

Implementation Details:

  • Support all of SLD: #57
  • Support vendor specific extensions of GeoServer: #58


There are many times when a user might do something a particular way in one style, and want to copy it for use in another. We should support a variety of copy and paste options, within styles and hopefully even across styles. A number of things could be copy/pasted in a sensible way: colors, single symbolizers, symbolizer stacks, single rules, rule groups.

Design proposals (tentative):  Copy & Paste via context menu

  • application level clipboard manager #60 (note this does not implement the above proposal, it only deals with managing copied objects

"View Source" / Edit SLD

Until we support every option in SLD, and every potential vendor option, we need to give users a way to edit the raw SLD file through Styler. It should be presented in a window that has nicely indented XML, and should reflect the current state of the GUI. If options that can be represented in the GUI are changed then the GUI should reflect those changes. The window should also do minimal validation, making sure it is at least valid XML, before sending to the server and generating the error there.

Design proposal: Managing Styles/SLDs
Implementation details: #59

Improved Scale Management

This is one of the least clear items, as it is charting somewhat new territory – no GIS stylers are optimized for web mapping. To do this right we'll need to try out a few different ideas, and do extensive user testing, to make a truly intuitive management and generation of zoom levels. This is potentially one of the biggest work items, but also one with a big pay off if done right.

Design proposal: Limit by scale

Management of Groups: Unique Values and Thematic Maps

Two standard features of any GIS styler are to do Unique values and Thematic maps. The first is extremely useful when there are features of a few different types, which should all be drawn differently. A good example is roads – you want your interstates, your highways, your primary roads, and your secondary roads to all look different. We should provide nice wizard type functionality to generate unique values, and work flows that make it easy to further customize.

Design proposal: Style as categories

Thematic maps classify the data in to different colors, to get across various information visually. Thanks to uDig, GeoServer already has the ability to generate thematic maps in to SLD, with support for equal intervals and quantiles, generating a color ramp and number of steps supplied by the user. MapFish also has some of this functionality, so we should be able to access either (or better yet align the two servers to a common REST interface). The main thing needed is a good UI to generate and manage the groups of rules that are generated by the server.

Design proposal: Style as quantities

Pop-up styling

(For Google Earth, GeoRSS, etc) Since one of the main use cases of Styler is to make things look good to serve to Google Earth we should let users style the 'description' and 'snippet' fields of KML output. Ideally users could also edit extrudes and time templates through Styler. (Implementation details: For OWS-5 we extended SLD to handle description and snippet. For GeoServer we got this working with an expression that read our Freemarket templates. The better way to do it would be to update our implementation to make use of the ExtendedData stuff (hopefully the changes we suggested got in), and then the template thing that Google provides (need to look up the name, am offline right now), as it is a bit more standard than our Freemarket language.

Cascadenik CSS-like language

One of the coolest things we've seen recently is  Cascadenik, which turns Mapnik's styling language in to a CSS-like language that is more accessible to designers. Many designers may grok this really well, and prefer it to editing SLD/XML and to navigating a GUI. It would be great to share the same language, and SLD should be close enough to Mapnik's style rules. We could then have a 'view source' tab that lets you edit either SLD or the cascadenik language. Ideally Styler could also be used to style Mapnik.

(Implementation – a basic pass might not be too hard to implement – it would just translate cascadenik to and from OpenLayers style objects. These could then be represented in the GUI and persisted out as SLD. Getting Styler to style Mapnik could maybe use the same route cascadenik uses, or could be written to go straight to/from Mapnik style XML to OL style objects.)

ArcMap export

Though outside the scope of Styler per se, it would be really good to have a tool that exports from ArcMap in to styler. Many users have many styles already defined in ArcMap, and some may prefer to start styling their map there, and finish off the zoom level customization in Styler. We hope that someone will built a tool that easily exports from ArcMap to SLD and in to Styler.

CQL for filters

Many times it may be tedious to use the filter builder gui if you know exactly the complex filter you want to write. Making an XML filter is a bitch, but CQL is a nice little intuitive language to make filters. This would involve mostly writing a CQL parser / producer for OpenLayers filter objects. Probably not worth the effort, but worth mentioning.

Live editing

OpenLayers has some awesome style support, that works directly in the browser using SVG or VML. Instead of having the server render the style, which takes a network round trip no matter what, Openlayers could render the style directly in the browser. Once the user is happy it could send to the server to make sure it looks as expected. To truly support this we would need to have OL cover all the options in SLD, as well as the vendor params we will expose in Styler.

(Implementation stuff – limits on rendering, so huge datasets don't time out. And provide a way to start applying rules on a huge dataset. Maybe just a max features, and zoom to a narrower bounds).