I’m excited to tell you about some changes to the GeoServer documentation. We are transitioning away from our wiki in favor of a new system. After much discussion, we are now using the Sphinx Documentation Generator.

Sphinx has many advantages over a wiki. The biggest advantage is that the content of the documentation is written in plain text (using a simple markup language called reStructuredText) and then “compiled” to become the finished product. With documentation now essentially just another part of the source code, it can be brought under version control. This means that we can, for the first time, have version-specific documentation, as well as the ability to allow for simultaneous editing, conflict management, and all of the other tools associated with version control.

While wikis have many advantages, a clear hierarchy is generally not one of them. (For example, one doesn’t read Wikipedia “from the beginning.”) And while search remains a feature of our documentation, Sphinx is geared towards the creation of text that can be constructed and read like a manual. Along this line, we can now create documentation in PDF, a feature that has been asked about for years.

We have soft launched the new documentation with the release of GeoServer 1.7.4. The old wiki is still live, and will remain so. But there is still much to be done, and you can help. The documentation is still very much a work in progress, and not all of the content from the wiki has been migrated. We’ve developed a guide to documentation that describes the ways that you can contribute. The most helpful way is to create content for empty or unfinished pages, and either submit a bug report with the content attached or commit the changes on your own. (If you are interested in getting commit rights to our documentation, please send an email to the GeoServer developers mailing list.) If you are aware of a page in the wiki that should be migrated to the new site, please let us know as well.

For GeoServer 1.7.4, the documentation download contains both HTML and PDF output. I encourage everyone to download, read, and make suggestions. For our part, we will continue to work to make GeoServer easy to learn, use, and understand.

The GeoServer Team is happy to announce the the release of GeoServer 1.7.4, the fifth stable version in the 1.7 series.

This release contains some new features, many having to do with improved map rendering options. We have introduced WMS decoration, which provides a framework for adding images such as compasses and legends to WMS requests using absolute, not spatial, positioning. The GetFeatureInfo request, often used when clicking on an OpenLayers map, now has a parameter that can be adjusted to allow for looser tolerance, eliminating the need to click precisely on the feature. GetFeatureInfo also now observes the filters in the SLD, so as to prevent displaying information about a hidden feature. (Thanks to SATA Hi-Tech Services, an Italian company specializing in data security solutions, for providing funding for the GetFeatureInfo improvements.) Those who work with labels on your map will be pleased to note that label conflict resolution (the selective display of labels to prevent visual collisions) can now be turned off if desired. Finally, we have the ability to generate custom legends for raster files via the GetLegendGraphic request.

And, as usual, a whole host of bug fixes (over 50!) have been incorporated into this release. Give it a try!

Development work on the 1.7 series will begin to wind down in favor of GeoServer 2.0, but we anticipate the release of 1.7.5 within the next two months.

I am happy to announce to everyone a sneak peak of the future of GeoServer. Behold the newest alpha release of GeoServer 2.0.

I first mentioned GeoServer 2.0 last August when the first alpha was released, but much work has been done since then. The most obvious and exciting new feature in GeoServer 2.0 is the new UI, based on the Wicket framework. The UI has been totally redesigned and updated to provide a greatly improved user experience. Take a look at some screenshots:

Front page

Status

Layer preview

Styles

Another happy announcement is a major workflow change for data configuration. The Submit -> Apply -> Save workflow, often bemoaned by users, has been eliminated, in favor of a simpler Save changes workflow, with changes automatically persisting. To me, that’s a 66.6% reduction in button clicks!

This is an alpha release (the most recent stable version remains at 1.7.3) and so it comes with a few caveats. It’s very new code, and not fully tested, so please don’t run it in a production environment. Features may also be likely to change as the code approaches stability. Also, running GeoServer 2.0 with an existing data directory will alter it such that it will become incompatible with existing stable versions. We have instructions on how to migrate back to 1.7.x, but it might be better to use the built-in data directory for now, or at least to back up your existing data directory first.

That said, we want everyone to download, try it out, and provide feedback, since it was partly in response to user feedback that the GeoServer Team upgraded the user environment. I hope you enjoy!

I received a note recently from a GeoServer blog reader who wanted to show off another project using GeoServer, which I am happy to present here.

The Marine Science Institute at UC Santa Barbara and Farallon Geographics have built a public, online mapping application enabling scientists and community members to help select marine environments that they feel should be designated for conservation, recreational, and/or commercial uses. It’s called the MarineMap Decision Support Tool.

You need to have a login to make edits, but anyone can view the layers that are already there. And there’s a good amount of info too, from water quality to estuaries to locations of popular surfing sites. These layers can be exported to Google Earth as well. The designers have also helpfully created a screencast showing how to use their application.

The site is based on GeoServer and OpenLayers. But what intrigued me was the pleasing desktop-styled application. It reminded me of GeoExt, and for good reason, since GeoExt is a framework for constructing web mapping applications combining the user interface components of Ext with OpenLayers. And sure enough, it turns out that Ext was used in this application.

I don’t know about you, but I think the folks at the MSI should join up with the GeoExt project; I’m sure everyone could learn a lot.

Here’s a neat trick for those working with road maps that want to indicate traffic direction by way of appropriately pointed arrows. With text symbolizers using font characters, this is actually a snap, provided your data includes information about direction.

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!