Stay Connected with the Boundless Blog

Apply Styles to Maps in Open Source GIS with YSLD and GeoServer

Some years ago, I gave a talk at FOSS4G entitled “Styled Layer Descriptor, or How I Learned To Stop Worrying and Love XML.” Designed to appease the skeptical audience, I described some of the more nifty features of the SLD syntax that GeoServer uses to style its maps and layers. You could have been excused for not sharing in my enthusiasm and Dr. Strangelove fans may notice that I was equating XML with a nuclear bomb, so the point was never lost on me either.

For example:

<Rule>
  <PointSymbolizer>
    <Graphic>
      <Mark>
        <WellKnownName>circle</WellKnownName>
        <Fill>
          <CssParameter name="fill">#ff0000</CssParameter>
        </Fill>
        <Stroke>
          <CssParameter name="stroke">#000000</CssParameter>
          <CssParameter name="stroke-width">2</CssParameter>
        </Stroke>
      </Mark>
      <Size>8</Size>
    </Graphic>
  </PointSymbolizer>
</Rule>

That’s a lot of markup just to create red points with a black outline. Can’t we do better? Indeed we can.

Maps are not web pages, alas

There have been a few efforts over the years to make improvements to how users style layers in GeoServer. One such notable attempt was to adapt the usage of CSS in web page design to the task of map making. At first blush, this seems like a perfect fit: web-based maps can use web-based design! And in truth, the CSS styling extension for GeoServer is a powerful tool for converting CSS-like markup to SLD.

There are issues, though. CSS uses a fundamentally different painting model from SLD, so it is not possible to convert freely back and forth between CSS and SLD. Generated SLDs typically have many more rules than the CSS rules, so a reverse converter would need to identify the redundancies and eliminate them. Because the underlying rendering engine was built on the SLD model, this was problematic, and rewriting the engine wasn’t feasible.

So then the question became: is there a way to simplify the syntax, while still remaining true to the underlying rendering model?

Y not?

Frustrated from working with SLD, one of my former colleagues came up with an idea: why not adapt an existing markup language? He was familiar with YAML, which we had used internally in our work with map printing. It was pleasantly terse and seemed suited to the task. This idea percolated for a while, and months later, has emerged as a central component of OpenGeo Suite Composer: YSLD.

Remember that SLD example above? Here it is as YSLD:

point:
  size: 8
  symbols:
  - mark:
  	shape: circle
  	fill-color: '#FF0000'
  	stroke-color: '#000000'
  	stroke-width: 2

Much better isn’t it? Easier to read and more compact — and with many fewer brackets, that’s for sure.

There are other advantages to YSLD as well. Unlike XML, YSLD is schema-less, so ordering of components is not important. And for the first time, you can now define markup that is repeated throughout the document with a variable, so you can define it once and reuse it all over.

And, since YSLD uses the same underlying model as SLD, you can translate back and forth as you wish, making it completely interchangeable and compliant with OGC standards.

Get started with YSLD!

YSLD and OpenGeo Suite Composer are available exclusively to our enterprise customers. If you needed another reason to get OpenGeo Suite Enterprise, aside from proven on-demand support and maintenance, assistance with upgrades, and advice direct from the software developers, how about we add one more: a better way to style maps.

YSLD example

Have you checked out YSLD and Composer yet? Contact us to learn more or evaluate the tools.

Mike Pumphrey

Education Program Director

Mike leads the training department at Boundless, which provides professional development to both novice and experienced users on all software in the Boundless ecosystem. He is passionate about "translating computer into human", believing that software can only be great when it is understood by all. In this capacity, has also worked in both support and documentation roles, all in the pursuit of being an advocate for all users, not just the experts. Mike lives in Oregon in the United States.