1. <Presentation xmlns=http://2009. foss4g. org/>. <Name>
<Presentation xmlns= <Name> <Title> <Literal>Styled Layer Descriptor (SLD)</Literal> </Title> <Subtitle> <Literal>or How I Learned To Stop Worrying and Love XML</Literal> </Subtitle> </Name> <Presenter> <Literal>Mike Pumphrey</Literal> </Presenter> <Occasion> <Literal>FOSS4G, Sydney, Australia</Literal> </Occasion> <Date> <Literal>October 23, 2009</Literal> </Date> </Presentation>
Hi. My name is Mike Pumphrey. I work at OpenGeo as an Outreach Engineer, and yes that title is meaningless. It basically means that I write documentation, provide training and support, and do some light sweeping up in the office. And I’m here to talk to you about Styled Layer Descriptor, or SLD. As usual, I’ve got way too much material to cover in way too little time, so let’s jump right in.

2. So, what do you think of my map
So, what do you think of my map? It contains roads, rivers, buildings, cities, schools, parks, a nice topo layer, and points of interest. It’s also completely useless since it’s entirely blank.

3. Geospatial data has no inherent visualization
Geospatial data contains only position and attribute information. Nothing about visualization is inherent in the data itself. You can think of data as the raw materials needed to tell a story. And make no mistake, that’s what you are doing when you create a map. And so, in everyone’s new occupation as storyteller (congrats by the way), you have a great deal of, umm, latitude (sorry) in how you craft your map. You may not need to use all of the raw materials. You may wish to highlight certain data over others. But make no mistake…

4. We are all designers now. (Oh no.)
…if you are making a map, you are a designer. But don’t panic.

5. Style (noun/verb):
The way in which something is said, done, expressed, or performed.
A customary manner of presenting material.
The missing piece that turns geospatial data into a completed map.
There are many ways of thinking about styling, but as far as we are concerned, a style is the missing piece between data and map. And it’s a large missing piece, too. But don’t panic.

6. Ways to style maps Mapfile AXL ArcGIS Style files etc...
Depending on what framework you’re using to generate and serve your data, you may have options in terms of how your style is coded.

7. Styled Layer Descriptor (SLD)
But today I’m going to talk about Styled Layer Descriptor. This is the format that is used by the program that I spend much of my time working with, GeoServer.

8. (and we do love standards)
OGC standard
(and we do love standards)
SLD was created as a standard by the Open Geospatial Consortium (OGC) (who you may have heard of) as a schema for describing the appearance of map layers. This schema is expressed through XML.

9. XML? Really? <?xml version = '1.0' encoding = 'UTF-8'?>
<StyledLayerDescriptor version="1.0.0"
xsi:schemaLocation=" StyledLayerDescriptor.xsd"
xmlns=" xmlns:ogc="
xmlns:xlink="
xmlns:xsi="
<NamedLayer xmlns="
<Name xmlns="
<UserStyle xmlns="
<! Small paths - Outline -->
<!-- Paths OL Start of 1890 Zoom, covers 793 and below -->
<FeatureTypeStyle xmlns="
<Rule xmlns="
<ogc:Filter xmlns:ogc="
<ogc:PropertyIsLessThan xmlns:ogc="
<ogc:PropertyName xmlns:ogc="
<ogc:Literal xmlns:ogc="
</ogc:PropertyIsLessThan>
</ogc:Filter>
<MaxScaleDenominator xmlns="
<LineSymbolizer xmlns="
<Stroke xmlns="
XML? Really?
Yes, XML. Why? Well, XML is great for exchanging information. Web pages, after all, are a form of XML.

10. XML: Computers v. Humans
“Ooh, this is easy to read and output. I like this. “
“Oh dear, it looks like it was written by the Society for Far Too Much Verbosity and Redundancy Society.”
But in my experience, I’ve noticed that computers and humans have very different reactions to XML. Computers love it because it’s easy to parse. Humans, in my experience, dislike it because it’s verbose, cumbersome, and can be tedious to edit. And, since the vast majority of SLD is still edited by hand, this can be daunting.

11. and also a preview of the future of styling with SLD
How to Get By
and also a preview of the future of styling with SLD
But our charge is to figure out how to get by, to make the most of this, to love something that on the surface my look alien and aloof, but inside is very powerful, containing the ability to make very beautiful things. That’s my goal here today, to give you the high-level view of SLD, so you don’t need to learn it like I did, which is by parsing line SLD files line by line. Finally, if you’re fed up and ready to give up on this whole web mapping thing and pick back up your colored pencils, at the end I’ll show you some interesting projects that people are working on that eliminate the need to hand-code SLD. Stay tuned.

12. What’s in an SLD file? Symbology (Symbolizers) Metadata
Rules for drawing: Point/Line/Polygon/Text/Raster
Metadata
Name/Title/Abstract
An SLD really contains two sets of information: symbology and metadata. Symbology is a collection of rules for displaying certain types of data, while metadata contains name and title and abstract information about the style as a whole. There are five types of symbolizers (as those rules are named), point/line/polygon/text/raster. And please note that it is very common to mix and match symbolizers in the same style, for example, using a TextSymbolizer alongside a PointSymbolizer to display labels near points.

13. An SLD
<?xml version="1.0" encoding="ISO "?> <StyledLayerDescriptor version="1.0.0" … > <NamedLayer> <UserStyle> <FeatureTypeStyle> <Rule> ... </Rule> </FeatureTypeStyle> </UserStyle> </NamedLayer> </StyledLayerDescriptor>
Unfortunately, I don’t have nearly enough time to talk about the map information of an SLD. I’m talking about the header tags like NamedLayer and UserStyle. There’s a great 117 page PDF on the OGC website for those who are interested in the gory details. But time is short, and we’re going to hang out inside the UserStyle tag, which is where all of the style info goes.

14. Map Information
<StyledLayerDescriptor> <NamedLayer> <UserStyle> ...
What I will say is that there are a few minimal tags that you need to put in, or else many programs will reject the SLD as invalid. The first one, at the top, Styled Layer Descriptor, should be obvious. Named Layer is where I usually put the name of the layer that I’m styling. User Style is where the actual style goes.

15. Metadata
<UserStyle> <Name>town_street_1</Name> <Title>Town Streets</Title> <Abstract>If you want to know all about the streets in this town, this layer is for you.</Abstract>
For each tag, there is usually the option for a Name, Title, and Abstract. Having both a Name and a Title might seem redundant, but a Name generally refers to a computer-readable identifier (such as “town_street_1”) while a Title refers to a more human-readable identifier (such as “Town Streets”). An Abstract is usually a much longer description of the layer.

16. Remember: Don’t forget to call home Brush and floss twice a day
Create metadata
Metadata, like documentation, is often the last thing to be thought of in a project, and that’s really too bad, since this information is going to be published and/or reused. Adding information about your style is important. It’s also akin to good commenting in your code. It’s also akin to being asked to clean your room. You should do it anyway.

17. Symbology <FeatureTypeStyle> <Rule>
… <FeatureTypeStyle> <Rule> </Rule> </FeatureTypeStyle>
Okay, now that the nagging is out of the way, let’s talk about organization. Directives to visualize data are known as Rules. Each Rule contains one or more symbolizers. Rules are contained inside a FeatureTypeStyle, which, for our purposes, is just a set of rules. And, of course, you can have multiple rules and multiple FeatureTypeStyles. All the rules in the first FeatureTypeStyle are rendered before subsequent FeatureTypeStyles. This becomes handy when the layering of styles becomes important, which we’ll see later. For most simple situations, one FeatureTypeStyle is sufficient.

18. Symbology: Points Shape
<PointSymbolizer> <Graphic> <Mark> <WellKnownName> circle </WellKnownName> </Mark> </Graphic> </PointSymbolizer>
Enough bookkeeping. Let’s get down to the actual visualization. First, let’s talk about points. Points are the simplest type of data, I think, since they have just one coordinate. No length, no distance, just one position. So let’s think about what you can do with a point. You can give it a shape. SLD recognizes standard WellKnownNames of shapes, such as circles, squares, and stars. You can also use a graphic to use as your point.

19. Symbology: Points Size <Size>36</Size>
Once we have a shape, we can pick the size (in pixels). I should add here that there isn’t a way to make your shape geographically aware in standard SLD 1.0, that is to say make the graphic, say, 600 meters or 1200 feet. We use pixels, and as your renderer changes its view during zooming, the pixels will remain the same, even though it may “cover” a much differently sized area. The idea of a graphic getting larger as one zooms in, as would seem intuitively obvious to us, has to be done manually, for now.

20. Symbology: Points Inside (Fill)
<Fill> <CssParameter name="fill">#FF0000</CssParameter> </Fill>
Now as for coloring, assuming you’re using a standard shape, you can color the inside, known as a Fill. Some renderers (GeoServer comes to mind) allow for patterned fills, such as hatches.

21. Symbology: Points Graphic
<ExternalGraphic> <OnlineResource xlink:type=“simple” link:href="smileyface.png" /> <Format>image/png</Format> </ExternalGraphic>
You can use a graphic to fill your shape as well (known as an “External Graphic” in SLD) .

22. Symbology: Points Outside (Stroke)
<Stroke> <CssParameter name=“stroke”>#000000</CssParameter> <CssParameter name=“stroke-width”>2</CssParameter> </Stroke>
You can also color the edge of your shape, known as the Stroke. And because it’s an edge, you can do things like change the thickness (in pixels). For both the Fill and Stroke you can set opacity if you’d like, which is handy when dealing with multiple layers (so your symbolizing doesn’t totally obscure the layers beneath).

23. Symbology: Polygons Inside (Fill) <Fill>
<CssParameter name="fill">#00FF00</CssParameter>
</Fill>
A polygon, from a geometric standpoint, is made up of a collection of points, but from a styling perspective, can be thought of as one big, oddly-shaped point. As such, one can style it in much the same way as points, with some exceptions. The Shape, obviously, is determined for you, and also the size. But the Fill can be specified.

24. Symbology: Polygons Outside (Stroke)
<Stroke> <CssParameter name="stroke">#FF0080</CssParameter> <CssParameter name="stroke-width">5</CssParameter> </Stroke>
The Stroke can be specified as well, and is drawn around the edge of the polygon, from vertex to vertex. Thickness, color, and opacity can all be specified in the same way as we did with the point. Lovely!

25. Symbology: Lines
Q: <Stroke> and <Fill> for lines? A: Fake it.
Lines don’t even have a Fill option, so it seems that things are getting simpler and simpler, right? Not quite. To my eye and to many others as well, symbols with borders around them tend to look more pleasing to the eye. If you look at maps, print or otherwise, you will see this. And we want our lines to look as good as our points and polygons, don’t we? So, we’re going to fake it.

26. Symbology: Lines Two lines = simulated fill/stroke <Rule>
<LineSymbolizer>
<Stroke>
<CssParameter name="stroke">#000000</CssParameter>
<CssParameter name="stroke-width">16</CssParameter>
</Stroke>
</LineSymbolizer>
</Rule>
<CssParameter name="stroke">#0000FF</CssParameter>
<CssParameter name="stroke-width">14</CssParameter>
So how do we do that? It’s actually quite easy. Since lines only have strokes, we can draw each line twice, with the first one being a little thicker than the second one.

27. + = Symbology: Lines Two lines = simulated fill/stroke=
Making each line symbolizer a different color, congrats, we have a fill and stroke. And doesn’t that look nicer?

28. Symbology: Lines
Uh oh.
But if you were to just create two Rules for LineSymbolizers, you might encounter some rendering issues. This is because each line segment is being rendered with both styles at the same time, creating edge artifacts. What we want is all of one style (the thick black line) to be rendered first followed by the other style (the thinner blue line). Think of it like creating multiple layers.

29. Symbology: Lines <FeatureTypeStyle> <Rule>
<LineSymbolizer>
<Stroke>
<CssParameter name="stroke">#000000</CssParameter>
<CssParameter name="stroke-width">16</CssParameter>
</Stroke>
</LineSymbolizer>
</Rule>
</FeatureTypeStyle>
<CssParameter name="stroke">#0000FF</CssParameter>
<CssParameter name="stroke-width">14</CssParameter>
And we do this by using two different FeatureTypeStyles. All the rules in the first FeatureTypeStyle will be rendered first, followed by subsequent FeatureTypeStyles.

30. Symbology: Lines
Ahhh.
The result looks much better.

31. Symbology: Text
Now, we move onto the TextSymbolizers When you think TextSymbolizers, think labels. A data point might be useless if you can’t see what it’s referring to. What can you do with text when applied to a map? First you need to figure out what to display. Most often the text is linked to an attribute in the data set. (The name of the school, city, country, etc.)

32. Symbology: Text Label content
<Label> <ogc:PropertyName>name</ogc:PropertyName> </Label>
The content of this attribute will be displayed for each feature.

33. Symbology: Text Font (size, color, weight)
<Font> <CssParameter name="font-family">Arial</CssParameter> <CssParameter name="font-size">12</CssParameter> <CssParameter name="font-style">normal</CssParameter> <CssParameter name="font-weight">bold</CssParameter> </Font>
You can also determine the text attributes, such as the font, font size, font color, etc. As for the font choices, you are limited to whatever is doing the rendering, so even though you may love that wacky 1950’s diner font, your renderer may not.

34. Symbology: Text Placement
<LabelPlacement> <PointPlacement> <AnchorPoint> <AnchorPointX>0.5</AnchorPointX> <AnchorPointY>0.5</AnchorPointY> </AnchorPoint> <Displacement> <DisplacementX>0</DisplacementX> <DisplacementY>15</DisplacementX> </Displacement> </PointPlacement> </LabelPlacement>
Next you can determine placement. Placement refers to where the text is displayed relative to the data with which it is associated. The anchor point refers to where the feature would be placed relative to the label, from 0 to 1 (left to right). Values of 0.5 for both X and Y center the label on the point (or the centroid of the feature if you’re not dealing with a point). Displacement is just a distance in pixels to move the label away from the feature.

35. Symbology: Text With points:
Text Symbolizers are used in conjunction with point/line/polygon Symbolizers, so it makes sense to look at each case. In the case of the point, you generally want to make sure that the label is near, but not on top of the point itself. Our SLD code from the previous slides is displayed here.

36. Symbology: Text With polygons:
With polygons, on the other hand, it may make sense to have the label be in the center of the polygon, without any displacement.

37. Symbology: Text With lines?
Once again, lines turn out to be a tricky issue. Where should the label go? One could ask for the label to be superimposed on top of the line, but what if the line is curved? Should the label stick out, tangentially? Be offset? Perpendicular? What do we do?

38. Symbology: Text Vendor Options!
<VendorOption name="followLine">true</VendorOption>
By default, as part of the SLD specification, there is no “best answer” to this question. However, this is as good a time as any to bring up the fact that some vendors (again, GeoServer being the one that springs to mind) have extended the SLD spec to include additional styling options, known as Vendor Options. GeoServer has many VendorOptions to help ease rendering constraints imposed by SLD. And in this case GeoServer has a “FollowLine” option to make the text of the label curve along with the line. This is pretty awesome.

39. Symbology: Text
<VendorOption name="followLine">true</VendorOption> <VendorOption name="maxDisplacement">60</VendorOption> <VendorOption name="repeat">100</VendorOption> <VendorOption name="maxAngleDelta">30</VendorOption> <VendorOption name="autoWrap">50</VendorOption> etc...
There are many different Vendor Options. Remember that these are GeoServer specific.

40. Symbology: Raster Digital Elevation Model
<ColorMap> <ColorMapEntry color="#000000" quantity="-500" opacity="0.0" /> <ColorMapEntry color="#AAFFAA" quantity="0" /> <ColorMapEntry color="#00FF00" quantity="1000"/> <ColorMapEntry color="#FFFF00" quantity="1200" /> <ColorMapEntry color="#FF7F00" quantity="1400" /> <ColorMapEntry color="#BF7F3F" quantity="1600" /> <ColorMapEntry color="#000000" quantity="2000" /> </ColorMap>
So far we have restricted our focus to vector data only, but what of rasters? There are many different types of raster data but I’m going to focus on the DEM, or digital elevation model. A DEM has one band of data, and you can create a smooth gradient based on mapping specific values to specific colors with a ColorMap. Certain values can even be rendered as transparent.

41. Symbology: Raster
Digital Elevation Model
The result.

42. Attribute-based styling
Customize feature display
Show only what you want to show
So far, our symbology has been applied universally. That is to say, each feature in a dataset will be rendered the exact same way. But that’s not always desired. Within some datasets, you may have certain features you wish to make blue or some purple, or some you wish to make large or small, or even some you wish to not even display at all. This is accomplished using Filters.

43. Attribute-based styling
<PropertyIsEqualTo> <PropertyIsNotEqualTo> <PropertyIsLessThan> <PropertyIsGreaterThan> <PropertyIsNull> <PropertyIsLike>
A Filter is very simple. It creates a conditional statement that checks against each feature rendered in the Rule. If that conditional is found to be true, the feature is rendered according to the Symbolizer. If not, it isn’t. The filters are relatively self-explanatory. Each has a condition, an attribute, and a value.

44. Attribute-based styling
Filters apply to Rules, not individual symbolizers
<ogc:PropertyIsEqualTo> <ogc:PropertyName>name</ogc:PropertyName> <ogc:Literal>Thisland</ogc:Literal> </ogc:PropertyIsEqualTo> ...
Condition. Attribute. Value. Note that Filters are applied to Rules. That’s worth repeating. They are applied to Rules, not Symbolizers, not FeatureTypeStyles, Rules. This means that a filter is applied to all Symbolizers in a rule. If you want a Filter to apply to only one of your symbolizers, you must remove all the other symbolizers and put them into a different rule.

45. Zoom-based styling Display at certain zoom levels
<sld:MinScaleDenominator>1000</sld:MinScaleDenominator> <sld:MaxScaleDenominator>10000</sld:MaxScaleDenominator>
Zoom levels are when things really start getting interesting. We instinctively know that as the zoom level changes, features should look different. Points should get larger or smaller, labels should display or disappear, lines get thicker or thinner, etc. You can add zoom-based rules that only will render at specific zooms.

46. Zoom-and-attribute-based styling
This gets messy: M filters at N zoom levels = M x N rules!
But this gets messy. Although attribute based styles and zoom based styles together make for a dynamic and thrilling map, the snag is that your SLD will grow uncomfortably large. With, say, 10 filters and 16 zoom levels, and with each rule being, say 20 lines, we’re looking at over 3000 lines of SLD code. What a great map, but what a headache.

47. Alternatives to coding by hand (yay!)
Now for the headache medicine. Congrats, you’ve made it this far. Let’s look at some alternatives to coding SLD by hand.

48. uDig
Some of you may be familiar with uDig, which has rudimentary graphical SLD editing capabilities. The SLD it generates, however, can be rather verbose (for example, I notice that it automatically generates a rotation parameter…for circles). But it’s a great tool for generating the basic SLD, which you can then tweak by hand. This is how I did most of these examples.

49. Styler
Styler is a great new tool that some of the folks at OpenGeo have been developing. It’s based on GeoExt, and it’s a web application where you point, click and style. It’s not fully featured yet, but it’s still pretty awesome. If you’re interested, I’ll be doing a demo theatre later this afternoon which will show this.

50. CSS to SLD
I think this may be one of the most exciting developments yet. Here is an add on to GeoServer that one of my colleagues has put out that allows for styling maps via CSS. You type in CSS, and SLD is generated. Notice how compact the CSS is compared to the SLD.

51. Questions?
This was a whirlwind overview of SLD, and there is much more that could be said. Remember, styling is an art as much as anything else. And you are all designers now. Does anyone have any questions?

52. <Presentation xmlns=http://2009. foss4g. org/>. <Name>
<Presentation xmlns= <Name> <Title> <Literal>Styled Layer Descriptor (SLD)</Literal> </Title> <Subtitle> <Literal>or How I Learned To Stop Worrying and Love XML</Literal> </Subtitle> </Name> <Presenter> <Name> <Literal>Mike Pumphrey</Literal> </Name> < > </ > <FinalWords> <Literal>Thanks!</Literal> </FinalWords> </Presenter> </Presentation>
Thanks for listening. Good luck!