<AttributeMapping>
    <targetAttribute>er:material</targetAttribute>
    <sourceExpression>
        <linkElement>
            if_then_else(equalTo(MaterialCode, 'rock'), 'gsml:RockMaterial', 'gsml:Mineral')
        </linkElement>
    </sourceExpression>
</AttributeMapping>

Another common example is replacing null values with an xlink:href to a URI representing missing values:

<AttributeMapping>
    <targetAttribute>er:startDate</targetAttribute>
    <sourceExpression>
        <linkElement>if_then_else(isNull(START_DATE), toXlinkHref('urn:ogc:def:nil:OGC::missing'),
                         'gml:TimeInstantPropertyType')
        </linkElement>
    </sourceExpression>
</AttributeMapping>

Read more about app-schema polymorphism support: polymorphism.

1. Read the OGC SLD 1.0 specification. At 100+ pages, it can be a bit dense.
2. Read the SLD schema. Because, really, who doesn’t love interpreting schemas?

Failing those, the would-be map stylist is usually out of luck, needing to eke out an understanding of styling by asking on mailing lists and doing web searches.

When I was learning SLD, I wanted simple examples that I could understand and edit. I wanted screenshots. I wanted to know which line of code did what. I wanted to look up styles as if they were in a recipe book. But this type of reference didn’t exist at the time.

The SLD Cookbook is that reference. It is a “practical reference” to show how map styling works. It is not designed to be exhaustive, and it won’t tell you about every possible edge case. But it also has no SLDs that are hundreds of lines long, a strong hurdle to comprehension.

Want to know how to style a simple point? Look at the example, download the SLD (and the shapefile that generated the screenshot too, if you’d like), and read the details. See which line of code accomplishes what, so if you want to make the points blue instead of red, you’ll know what line to change (line 8 in this case). Want to see how to make a style where lines are styled differently by data attributes? Or by zoom level? Refer as necessary. Even those experienced with SLD may find the examples useful.

There are a few examples mixed in that leverage extensions to GeoServer/GeoTools (polygon fill hatching, labels that follow lines) but for the most part, the examples are perfectly valid according to the SLD 1.0 specification.

I’m sure that more examples can and will be added in time. I’ve already received some very good feedback from others, and some styles will likely be optimized. But every example, every screenshot, and every SLD was tested in the most recent version of GeoServer.

So take a look, and get styling! I hope you enjoy. Special thanks goes out to Geonovum, who funded this project. I personally appreciate it.

Today I’m going to show you how to achieve those effects dynamically using what we call geometry transformations. Geometry transformations are yet another extension to SLD in order to make it more powerful. (Another example of SLD an extension that GeoServer has implemented is dynamic symbolizers.) Standard SLD allows the user to specify a <Geometry> element in each symbolizer, but its contents can only be a <PropertyName>; this allows a user to choose a different geometry should a spatial table contain more than one. With geometry transformations, GeoServer allows you to specify a filter function as well, which can transform the geometry. (You may want to refer to my previous post on filter functions.)

Let’s look at an example. Say we have a building layer, rendered with a plain gray fill:

We can add a twist to this plain map by adding a drop shadow beneath the buildings layer. To achieve this we will offset the buildings a bit, fill them dark gray, and then paint the standard buildings layer on top of it. The style looks like:

      <FeatureTypeStyle>
        <Rule>
          <Title>Shadow</Title>
          <PolygonSymbolizer>
            <Geometry>
               <ogc:Function name="offset">
                  <ogc:PropertyName>the_geom</ogc:PropertyName>
                  <ogc:Literal>0.00004</ogc:Literal>
                  <ogc:Literal>-0.00004</ogc:Literal>
               </ogc:Function>
            </Geometry>
            <Fill>
              <CssParameter name="fill">#555555</CssParameter>
            </Fill>
          </PolygonSymbolizer>
        </Rule>
      </FeatureTypeStyle>
      <FeatureTypeStyle>
        <Rule>
          <Title>Polygon</Title>
          <PolygonSymbolizer>
            <Fill>
              <CssParameter name="fill">#CCCCCC</CssParameter>
            </Fill>
            <Stroke>
              <CssParameter name="stroke">#000000</CssParameter>
              <CssParameter name="stroke-width">0.5</CssParameter>
            </Stroke>
          </PolygonSymbolizer>
        </Rule>
      </FeatureTypeStyle>

And the result is:

The filter function takes the geometries and offsets them by (0.00004, -0.00004). Geometry transformations occur against the original geometry, which in this particular case is in EPSG:4326, so the values of the offset are also in units of lon/lat.

You can find more examples about this functionality in the geometry transformations section of the User Manual. You can also get creative by looking at the currently available set of filter functions. Also remember, if you want a function that’s not there, it is possible to add new ones; drop by on the developer mailing list and we’ll provide you with directions.

If so, welcome to the club. One thing few people know is that both SLD and WFS filtering capabilities can be extended by using filter functions. A filter function is just like a programming language function, it’s something that takes arguments and returns some result. For example, “sin(toRadians(45))” will compute the mathematical sin of 45 degrees, and “strSubstring(“hippopotamus”, 0,  5)” will return “hippo”.

The concept of filter function is standardized, but functions themselves are not, so once you start using them you’re tied to a specific server. However they often provide the level of flexibility that you just need in order to get some work done. The good news is that GeoServer already contains tens of them, from number and date formatting, to geometry manipulation, math, string wrangling. So far we just never found the time to document them, but things have changed and we have now quite a complete reference along with some examples.

Let me show you a simple example of using functions. Say we have a contour map, each isoline has an elevation, and we want to show it on the map. Unfortunately the elevation is stored as a floating point, resulting in a less than pleasing output of “150.0″ or sometimes “149.999999″ when we know the elevation accuracy does not go beyond the meter. To get nice labelling we can use the “numberFormat” filter function to force an integer representation instead (along with some VendorOptions):

<TextSymbolizer>
  <Label>
    <ogc:Function name="numberFormat">
       <ogc:Literal>#</ogc:Literal>
       <ogc:PropertyName>ELEVATION</ogc:PropertyName>
    </ogc:Function>
   </Label>

  ....

   <VendorOption name="followLine">true</VendorOption>
   <VendorOption name="repeat">250</VendorOption>
   <VendorOption name="maxDisplacement">150</VendorOption>
   <VendorOption name="maxAngleDelta">30</VendorOption>
</TextSymbolizer>

Notice how the the ELEVATION field is formatted as an integer number following the simple formatting pattern provided (for a full reference see the the Java DecimalFormat documentation):

I hope you’ll find interesting and clever uses of the existing filter functions to improve the way you work with GeoServer. Next time I’ll show you my favourite one, which is also a new feature in GeoServer 2.0.1, called “geometry transformations”. Stay tuned to learn more about it.

En respuesta a la creciente demanda de información e ímpetu de colaboración de usuarios de habla hispana, hemos creado un grupo de discusión para la comunidad hispano-hablante donde puedes comunicarte con otros usuarios de GeoServer en español y discutir cualquier tema relacionado con el proyecto. Si quieres involucrarte activamente en el desarrollo de GeoServer puedes inscribirte en la lista de desarrolladores (en inglés).

We’re also looking for users to contribute documentation in Spanish, así que si quieres ayudar a escribir documentación en español dejanos saber.

The New York City streets data set has an attribute field called trafdir which specifies the flow of traffic on one-way streets:

W – (“with”) One-way in the direction of ascending street numbers
A – (“against”) One-way in the opposite direction of ascending street numbers

With this in mind, all that is needed is an SLD with two rules, each rule drawing an arrow pointing in appropriate direction specified by the trafdir attribute. Since arrows are included in most fonts, this can be accomplished using text symbolizers. And since the text label is oriented relative to the lines themselves (due to labels that can follow curves) the arrows will automatically be properly aligned with the road.

Here is one of the SLD rules. The other rule is identical, except for the attribute value and the specific character used.

<Rule>
  <ogc:Filter>
    <ogc:PropertyIsEqualTo>
      <ogc:PropertyName>trafdir</ogc:PropertyName>
      <ogc:Literal>W</ogc:Literal>
    </ogc:PropertyIsEqualTo>
  </ogc:Filter>
  <TextSymbolizer>
    <Label>
      <ogc:Literal>&#x2192;</ogc:Literal>
    </Label>
    <Font>
      <CssParameter name="font-family">Lucida Sans</CssParameter>
      <CssParameter name="font-size">18</CssParameter>
    </Font>
    <Fill>
      <CssParameter name="fill">#a4bdc5</CssParameter>
    </Fill>
  </TextSymbolizer>
</Rule>

This trick was figured out by Jordan Anderson, author of Ride The City, who goes on to say:

“Probably the most challenging thing was getting the correct balance between street name labels and arrow labels (which are on two different layers). I became intimately familiar with all the new labeling options and made use of spaceAround, maxDisplacement, and Repeat to get something close to the right balance.”

Looks pretty good to me. Thanks Jordan!

I was recently turned on to Swivel, a website that allows you to upload, visualize, and share data. The main page provides a list of some of the more recent data collections and, like so many great websites, my response to many of those graphs was interest piqued that I never knew I had.

I looked into the process of getting data on Swivel, and saw that one of the ways of uploading data was via a hosted CSV file. And this was noteworthy, since with the release of GeoServer 1.7.3, CSV is newly available as an output format.

So, thinking of our perennial favorite, the topp:states layer (USA Population), I found my hosted version of GeoServer 1.7.3, and built the following request:

http://MYGEOSERVER/wfs?service=wfs&request=GetFeature&typename=topp:states&outputformat=csv

As a refresher (or for those whose eyes glaze over at long GET requests), let’s briefly go over this:

service=wfs – Specifies a WFS request, so we should be getting back XML, not images.
request=GetFeature – Asks for actual feature data from a layer, as opposed to information about that data (like in a GetCapabilities request).
typename=topp:states – This specifies the layer to apply the request to, in this case, “topp:states”, the “Hello World” of GeoServer.
outputformat=csv – This specifies the CSV output format.

Anyway, I flexed my fingers and pasted the above link into Swivel’s upload page. In a few seconds, Swivel returned with a preview of the tabular data, to make sure that it was uploaded correctly (and to check things like delimiters and titles).

Swivel appears to have gotten everything right on the first try, so I continued on. Next it asked me about title names, and to verify the data types on the columns (text/numbers/etc).

Once again, Swivel appears to have needed no steering. The next page asked for information about the data set. (And I know when adding layers to GeoServer, we never skip this step, and always fill out the Name/Title/Abstract, right?)

Then came to obligatory signup page (a smart thing to put at this step and not at the beginning, I might add) and then a long wait. Finally, I was presented with the ability to decide which columns to set as the graph. I wanted to go for public transit usage as a function of total population (basically a graph of PUBTRANS/PERSONS vs. STATE_NAME) but Swivel didn’t provide for mathematical operations that I could find, , so I contented myself with a simple population graph.

The small point to make is that GeoServer can natively interact with many different applications, often in whimsical and unexpected ways. The larger point is that our data is more than just dots on a map. A robust data set, full of attributes and good metadata, can tell us stories, and the visualizations make the stories come alive. After all, it’s the story that’s really important, not the data, when it comes down to it.

(If you link up your GeoServer to Swivel and come up with some nifty visualizations, please send us the links, so we can see what you’re up to!)

The data

OpenStreetMap provides instructions on downloading their data.  The full data set is a large file, currently about 4GB when compressed and about 100GB when uncompressed.  (You can download sections of the data set as well.)  This data is an XML-based data format that GeoServer cannot read natively.  PostGIS is the optimal way of storing such a large volume of data when using GeoServer.  Luckily, there is a converter that allows you to load the OpenStreetMap data into PostGIS called osm2pgsql.  This program is a package available on Debian-based distributions (such as Ubuntu), and is also available as a binary on Windows.


Run the following command:

osm2psql -E 900913 -d osm planet.osm

This will process the XML information and load the data into a PostGIS database called “osm”. The -E defines the projection of the source data, which in this case is 900913, the projection used in Google Maps, and the default for OpenStreetMap.

If successful, the database will contain the following tables:

planet_osm_line
planet_osm_point
planet_osm_polygon
planet_osm_roads

Making sense of the data

OpenStreetMap’s data can be a bit confusing.  For a first time user like myself, just trying to figure out their naming convention was challenging.  They do, however, have a wonderful map key hidden away in their wiki.  This page is a lifesaver.

There are two different tables that contain line data, planet_osm_line and planet_osm_roads. The former includes railroads, subways, and other linear information.  The latter is made up exclusively of roads.  The planet_osm_point table has a range of data: subway stations, shopping centers, universities, and even brothels. Lastly the planet_osm_polygon table has, but is not limited to, parks, bodies of water, and even buildings in certain urban areas.

Styling

On my map I grouped the roads into three major groups; residential, secondary, and limited-access (highways).  To achieve this grouping I used the following SLD filters.

I then styled the map to distinctly display the three groups of roads, and also varied their widths depending on the zoom level.  This was the most time-consuming part of the process, as I needed to create and evaluate styles for each zoom level.  The final SLD is very large, but is available for those interested.

Final touches

Since the purpose of this map was to create a viable base layer that anyone can incorporate into their mapping projects, performance was a concern.  To address this, I used GeoWebCache, a tile cache mechanism built into GeoServer.  The GeoWebCache documentation has details on this process.

The finished (?) map

The finished product can be found at http://demo.opengeo.org/openstreetmap.

Feel free to link to this map.  Use this OpenLayers code to get started.  This map is a work in progress.  Future enhancements will include adding public transportation systems, railroads, buildings, and more. If you have any feedback on this map please email me at iwillig at opengeo dot org.

With GeoServer, PostGIS, OpenLayers and the OpenStreetMap data set, it is possible to build high-quality, professional-looking maps, allowing you to take control of what data you present, define your own mapping aesthetic, and free yourself from having to use commercial map layers.

Labels on lines have rendering challenges that points and polygons do not. This is because lines can curve. Not officially, of course, but lines can be a collection of line segments, which meet at their edges but can be rotated with respect to each other. The default behavior for a label is to appear parallel to the orientation of a line. However, this can cause problems when the label resides along a curve, as the label will not follow it. In some extreme cases, the label can appear only marginally connected to the line, which minimizes the effectiveness of the label! Clearly, there was room for improvement.

This improvement was sponsored by TriMet, the Portland, Oregon area transportation agency that uses GeoServer in their Trip Planner. Lead GeoServer developer Andrea Aime tackled this task with his usual aplomb, and GeoServer now renders labels that follow curves. Below is worth two thousand words:

This new road labeling is only in versions 1.7.1 and later. Currently this functionality is not turned on by default, but is instead must be enabled in GeoServer. One way of doing this is to edit your web.xml file inside the WEB-INF directory. Stop your GeoServer instance, and insert the following code block:

<context-param>
<param-name>USE_NG_LABELLER</param-name>
<param-value>true</param-value>
</context-param>

In addition, you also need to edit your SLD to include a VendorOption inside your TextSymbolizer. Add the following line:

<VendorOption name="followLine">true</VendorOption>

Restart your GeoServer, and you’re all set!

For me, the ability for GeoServer to output curved line labels is a huge step forward. There’s something about these labels that make the map seem so much more professional. Special thanks to TriMet for sponsoring this awesome new feature. Have you tried it out yet?

I have been playing lately with some remote sensing data for the geoSDI project specifically the emissive subdataset coming from the  MODIS sensor on-board the TERRA satellite. A small sample dataset can be found here. Its gdalinfo is here below:

Files: EmissiveCampania.tiff
Size is 63, 156
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.2572235630016,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (13.742259882413393,41.506517193315830)
Pixel Size = (0.032872864093301,-0.009584951678830)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 13.7422599, 41.5065172) ( 13d44’32.14″E,
Lower Left ( 13.7422599, 40.0112647) ( 13d44’32.14″E,
Upper Right ( 15.8132503, 41.5065172) ( 15d48’47.70″E,
Lower Right ( 15.8132503, 40.0112647) ( 15d48’47.70″E,
Center ( 14.7777551, 40.7588910) ( 14d46’39.92″E,
Band 1 Block=63×65 Type=UInt16, ColorInterp=Gray
NoData Value=65535
Band 2 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 3 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 4 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 5 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 6 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 7 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 8 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 9 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 10 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 11 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 12 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 13 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 14 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 15 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535
Band 16 Block=63×65 Type=UInt16, ColorInterp=Undefined
NoData Value=65535

The goal was to build a simple RGB on the fly (WCS usage is als envisioned, hence we could not just build it offline) by using bands 11, 9 and 1 respectively.

The style I have used for doing this is reported here below, it is a nice guideline in case you want to do something similar with Landsat data as an instance and create a false color image from the oiriginal dataset ( I might blog about that as well sooner or later ).

<?xml version=”1.0″ encoding=”UTF-8″?>
<StyledLayerDescriptor
xmlns=”http://www.opengis.net/sld”
xmlns:ogc=”http://www.opengis.net/ogc”
xmlns:xlink=”http://www.w3.org/1999/xlink”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd” version=”1.0.0″>
<UserLayer>
<Name>raster_layer</Name>
<LayerFeatureConstraints>
<FeatureTypeConstraint/>
</LayerFeatureConstraints>
<UserStyle>
<Name>raster</Name>
<Title>A boring default style</Title>
<Abstract>A sample style for rasters</Abstract>
<FeatureTypeStyle>
<FeatureTypeName>Feature</FeatureTypeName>
<Rule>
<RasterSymbolizer>
<Opacity>1.0</Opacity>
<ChannelSelection>
<RedChannel>
<SourceChannelName>11</SourceChannelName>
</RedChannel>
<GreenChannel>
<SourceChannelName>9</SourceChannelName> >
</GreenChannel>
<BlueChannel>
<SourceChannelName>1</SourceChannelName>
</BlueChannel>
</ChannelSelection>
</RasterSymbolizer>
</Rule>
</FeatureTypeStyle>
</UserStyle>
</UserLayer>
</StyledLayerDescriptor>

Since we are here, I will also show another rendering we have set up which applies a user defined colormap to band 11 (emissive temperature) which ranges from blu to red. Here is the style:

<?xml version=”1.0″ encoding=”UTF-8″?>
<StyledLayerDescriptor
xmlns=”http://www.opengis.net/sld”
xmlns:ogc=”http://www.opengis.net/ogc”
xmlns:xlink=”http://www.w3.org/1999/xlink”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd” version=”1.0.0″>
<UserLayer>
<Name>raster_layer</Name>
<LayerFeatureConstraints>
<FeatureTypeConstraint/>
</LayerFeatureConstraints>
<UserStyle>
<Name>raster</Name>
<Title>A boring default style</Title>
<Abstract>A sample style for rasters</Abstract>
<FeatureTypeStyle>
<FeatureTypeName>Feature</FeatureTypeName>
<Rule>
<RasterSymbolizer>
<Opacity>1.0</Opacity>
<ChannelSelection>
<GrayChannel>
<SourceChannelName>11</SourceChannelName>
</GrayChannel>
</ChannelSelection>
<ColorMap extended=”true”>
<ColorMapEntry color=”#0000ff” quantity=”3189.0″/>
<ColorMapEntry color=”#009933″ quantity=”6000.0″/>
<ColorMapEntry color=”#ff9900″ quantity=”9000.0″ />
<ColorMapEntry color=”#ff0000″ quantity=”14265.0″/>
</ColorMap>
</RasterSymbolizer>
</Rule>
</FeatureTypeStyle>
</UserStyle>
</UserLayer>
</StyledLayerDescriptor>

and here is the result:

Enjoy,

Simone.