This tutorial is designed for a beginner and is easy to follow. The steps she uses are:

1. Creating and editing data with QGIS
2. Designing SLDs with uDig
3. Serving maps with GeoServer
4. Creating a custom OpenLayers application
5. Posting to the web

The introduction mentions the benefits of using open source and also, interestingly, discusses the pros and cons of making a “mash-up” versus serving one’s own data.

Once again, we see Penn State as a proponent of open source GIS. Have you looked at their Master of Geographic Information Systems program lately?

As previously mentioned, GeoServer now provides support for Oracle Georaster, custom database layouts for image data and polymorphism.

Have you ever wondered what geographical area an EPSG code covers? A new feature has been added to showcase the different projections visually, by showing a map of the projection’s area of validity in the same CRS. Here are three examples of this: EPSG:2964, EPSG:3032, EPSG:22184.

To add to this, we have also added a default style preview in the layer publishing configuration.

The rendering subsystem has been improved to include parameter substitution, meaning you can pass parameters down from a GetMap request into your SLD for dynamic styling purposes.

The ability to do geometry transformations, included in GeoServer 2.0.1 without much fanfare, now has been completely documented.

Building image pyramids just got easier: gone are the times where you had to manually build each level mosaic and configure the main property file by hand. The current pyramid extension can do this for you provided it is given a suitably configured directory set. See the pyramid tutorial for more details.

Finally, this release of GeoServer implements the GetStyles optional WMS method allowing a user to retrieve the definition of all styles attached to a specific WMS layer, see the following link for an example:
http://demo.opengeo.org/geoserver/wms?request=GetStyles&layers=topp:states&service=wms&version=1.1.0

Thanks to everyone who have worked hard over the past few months adding features and fixing bugs, in order to make this release happen. As usual, we encourage you to download, try it out, and provide feedback on the users mailing list.

<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.

GeoServer will soon be able to handle raster/image data in customized JDBC database layouts. This is useful for special use cases or existing image databases, offering the freedom of choosing individual table layouts, provided the needed data and image meta information is available.

Because of this new feature, GeoServer will be able to serve Oracle GeoRaster files. This new functionality is due to improvements to underlying GeoTools imagemosaic-jdbc module.

For those who aren’t familiar, the imagemosaic-jdbc extension enables storing tiles and pyramids into a JDBC database. This is useful for building and storing an image SQL database from scratch, following a predefined table layout. See the image mosaic tutorial for more information on how this works.

The default GeoServer configuration already provides some help in this regard: it is already possible to limit the resources used by a single request by setting the maximum amount of features returned in a WFS request and by setting the maximum time and memory allowed for a WMS request. That is not enough, however, as it is still possible for the service to be bogged down by a large number of requests.

The control flow community module was developed to enable an administrator to impose limits on the total amount of work GeoServer may execute in parallel. With control flow, it is possible to limit the number of GetMap requests that will ever be served concurrently or to limit the number of requests that a single user may run in parallel. This simultaneously improves resource consumption, fairness, and performance.

Because it is a community module, you’ll only be able to find control flow in nightly builds. I recommend everyone running a public GeoServer instance look into the documentation, install it, and reap the benefits of increased resource control. I’ve actually been running it for over two months without issue on a relatively busy server (up to 60 thousand requests per day), resulting in greater up-times and fewer failed requests. Let us know how it works for you—if the module becomes popular we plan to turn it into an official extension that will be available in official releases.

In the last couple weeks I’ve seen a few different opportunities, so thought I’d post them here:

• The Global Biodiversity Information Facility (GBIF) is looking for a consultant to provide “the development of geospatial services for species related data” which will be “offered as OGC web services provided by GeoServer”.  There is also a listing for a client-side developer who would consume GeoServer services in an OpenLayers, GeoExt, or Flash–based client.

• On Twitter, I came across a company searching for a “Senior GeoServer Developer” who has at least a year of experience with GeoServer and is a “proven contributor and committer” on the project.

• The World Bank put up a job post seeking a developer to help them with core programming and deployment for “Haiti Data Dissemination Web Portals” to be built on the GeoNode project, which is based on GeoServer, Django, and GeoExt.

• With a bit of searching on Monster.com, I found a post for a developer with Java and GeoServer experience to help on a “Weather Data Analysis Capability” project.

If anyone else is looking for people with GeoServer expertise please email and I can add them here or do a job post in the future—or just add other listings in the comments. I’m also pretty sure a number of the core contributing companies behind GeoServer are on the lookout for new hires.  Though they don’t yet have a ‘jobs’ section on the site, I wanted to give a shout out to GeoSolutions and their great-looking redesigned website, as I know they’ve been growing and on the lookout for great people.

UPDATE: I also meant to mention that my organization is looking for a Salesperson and a Director of Marketing to help sell the OpenGeo Suite, which has GeoServer at its core and funds all our time on the project.

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.

With this in mind, I’ve been working on an extension to GeoServer allowing styling of map layers with a CSS-type syntax. This work follows in the footsteps of tools like Cartagen and Cascadenik which both apply a CSS framework to map styling.

To see how a CSS map style would look, compare the “simpleRoads” SLD from the data directory that ships with GeoServer:

<?xml version="1.0" encoding="UTF-8"?>
<StyledLayerDescriptor version="1.0.0"
  xsi:schemaLocation="http://www.opengis.net/sld StyledLayerDescriptor.xsd"
  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">
  <NamedLayer>
    <Name>Simple Roads</Name>
    <UserStyle>
      <Title>Default Styler for simple road segments</Title>
      <Abstract>Light red line, 2px wide</Abstract>
      <FeatureTypeStyle>
        <Rule>
          <Title>Roads</Title>
          <LineSymbolizer>
            <Stroke>
              <CssParameter name="stroke">
                <ogc:Literal>#AA3333</ogc:Literal>
              </CssParameter>
              <CssParameter name="stroke-width">
                <ogc:Literal>2</ogc:Literal>
              </CssParameter>
            </Stroke>
          </LineSymbolizer>
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

with the equivalent CSS style:

/* @title Default styler for simple road segments
 * @abstract Light red line, 2px wide
 */
* {
  stroke: #AA3333;
  stroke-width: 2px;
}

CSS styles are fully converted to SLD before GeoServer uses them for rendering, so the resulting SLDs can be migrated directly to other GeoServer instances, even if they don’t have the CSS extension installed. Filter functions, zoom-based styling rules, and geometry transformations are also available.

You can download the CSS extension from the nightly build server and add it to your existing GeoServer instance (2.0.0 and later only). Installation instructions are available in the CSS tutorial. All the features of the CSS extension are documented in the CSS section of the User Manual. I encourage everyone to check it out!

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.

Let’s have a look at an example. Below is a map drawn by GeoServer that is reprojected to a projection that happens to sit across the dateline, the usual “edge” of the map. As you can see the reprojection is not doing a good job where the dateline is crossed:

Polygons crossing dateline change before improving the renderer

However, GeoServer now has what is called advanced projection handling. With this enabled, the dateline wrapping is properly handled and, in addition, the map repeats in a continuous fashion:

Polygons crossing the dateline with advanced projection handling

For more information, including how to turn on this (optional) feature, please see this post from GeoSolutions.