Community member Michelle Ballinger has put together a short tutorial on creating an open source web map using GeoServer.

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?

To meet the growing demand for a geospatial server that meets the open standards set by the Open Geospatial Consortium, the GeoServer community has worked hard to release the new GeoServer 2.0.2. This release includes almost 100 bugfixes and new features.

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.

Support for polymorphism is included in Geoserver 2.0.2. Why do we need polymorphism support in app-schema? Some complex attributes are polymorphic by nature, which means they can have different types for different features.

Before polymorphism was supported, attribute types had to be specified in the mapping file, so could not vary across features. With polymorphism support, filter functions can now be used to specify conditions when determining the encoded type.

For example:

If MaterialCode is “rock”, er:material should be encoded as gsml:RockMaterial, otherwise it should be encoded as gsml:Mineral.

This can be expressed in the mapping file like this:

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

With the soon-to-be-released GeoServer 2.0.2, there are some exciting new features, two of which I would like to mention here.

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.

Putting a public OGC server in production can be a daunting task.  Dynamic web GIS requests (be they WMS or WFS) consume significantly more resources than a regular web site, making the service quite demanding in terms of memory, CPU, and bandwith consumption. When a service becomes popular, requests start fighting for limited resources and put the hardware under considerable strain, possibly leading to failure due to lack of available memory.

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.