Though I admit the name made me a bit scared, Andrea Aime pointed out a really nice use of some of our favorite platforms in the ‘WarViews’ project.  No, it’s not some geolocated remote missile camera, it’s a project by the International Conflict Research (IRC) group at a Swiss university that attempts to show more clearly the link between geography and conflict.

It complies several GIS datasets of conflict, and shows them on a static map built with OpenLayers, as well as a really nice use of GeoServer’s Google Earth time support to demonstrate the events over time.   I just wanted to point out their great work to everyone, go and have a play with what they’ve built.  It does a great job of showing how you get multiple output options with GeoServer, and can point users to appropriate clients that take advantage of different features.  If another researcher wanted the actual GIS data they could easily point at the WFS and get the raw GML or Shapefiles of the data.

We are happy to announce the second release candidate of GeoServer 1.6.0. You can download the release from SourceForge.

As usual this release candidate brings a heap of bug fixes, with a few minor improvements. Output formats such as KML, SVG, and GeoRSS have been tightened up fixing a few minor bugs. Backend issues such as PostGIS bounds reprojection and Oracle permissions have also been addressed. For a complete list check out the change log.

There are also a few notable improvements to mention. The first being a “strict” request parameter which allows clients to turn on WFS XML validation on a request by request basis. This provides a nice debugging tool for clients to use for validating WFS requests. Also worth mention is the ongoing work and improvements to the experimental Versioning WFS protocol.

With any luck this will be the last release candidate before the official 1.6.0 release. You can help us out by downloading it and trying out. Please report any issues encountered in the bug tracker.

Check out the two Geoserver-provided images below:

­ They may look very similar, but they have two important differences. First, the scaling of the second map is better for conveying the data. The second and more important difference you won’t be able to see unless you view this page’s source. The markup that produced Exhibit A involved the burdensome URLs you may be used to:

<img src="http://geo.openplans.org:8080/geoserver/wms?service=WMS &request=GetMap &version=1.1.1 &format=image/png &width=256 &height=108 &srs=EPSG:4326 &layers=topp:states &styles=population &bbox=-138.4239531951185,19.168145657378737,-53.27731780488149,55.15955634262126" />

Exhibit B, on the other hand, uses a far more concise URL for the image source:

<img src="http://geo.openplans.org:8080/geoserver/wms/reflect? layers=topp:states&width=256" />

How is this possible? Exhibit B uses the new WMS Reflector, written by Justin DeOliveira and augmented by Arne Krepp for 1.6.0 for RC1. The URL asks the reflector (wms/reflect) to display the feature “topp:states” (layers=topp:states) and that the width should be 256 pixels (width=256). The rest of the parameters are filled in either by sensible but overridable defaults–such as format=image/png–or with values calculated on the fly. The bounding box, for example, was inferred from the bounds of the content instead of being explicitly defined.

­

Less Pain­­

The WMS Reflector is designed to make it easier to play around with Geoserver without having to waste time tweaking cumbersome URLs. Before, writing a WMS request by hand was almost impossible, since you had to manually make sure that the ratio between the width and height parameters was the same as the ratio for the bounding box. You also had to know what a spatial reference system is, what version of WMS you wanted to use, and so on.

None of this should be weighing on the user who just wants to get Geoserver to show them a map. The WMS Reflector frees them from this kind of micromanagement. As seen in Exhibit B above, all you need to do is supply either a heig­ht or a width attribute and the rest–the bounding box, the other dimension–are automagically tailored to the data.

Overriding the Defaults

With the WMS Reflector handling the sizing and bounding box issues, it’s easier to play with Geoserver’s different output formats. The default request returns a PNG image of a map. But the following URL gets you a PDF

­http://geo.openplans.org:8080/geoserver/wms/reflect?format=application/pdf&layers=topp:states

Once again, with the Reflector, the URL contains just what needs to be said, and no more. You can even use the Reflector to quickly make navigable OpenLayers maps using the format=application/openlayers­ option.

­http://geo.openplans.org:8080/geoserver/wms/reflect?format=application/openlayers &layers=topp:states&height=300

If you are interested in learning more about the WFS Reflector and the parameters it supplies and derives, take a look at Arne’s documentation, which provides more details and examples.

­

­

Though they’ve been with us for awhile, I realized the other day that some new developers in the GeoServer community never got introduced properly.  They started working for The Open Planning Project (TOPP) a couple months ago, and have been working on some great stuff since then.  Their primary goal is to combine TOPP’s two main software projects - GeoServer and OpenPlans, a free (and ad free) collaborative platform providing wikis, email lists, task trackers and blogs, built entirely on open source software.  It’s been evolving nicely lately, so feel free to try it out and give feedback.

But the part that should be of great interest to this crowd is that the newest tool is going to collaborative mapping, allowing groups to do wiki type editing on maps, and eventually to be able to make and improve new base layers.  This will be built completely on GeoServer and OpenLayers, with the new versioning WFS improvements.  This should push the bounds of GeoServer and bring stability to the new features.  We’ve just put up an early demo, which lets you create and edit pop-ups, and also comment on them in a sidebar.  The base map on the demo is also all served by GeoServer, with a huge debt of gratitude to the Portland’s TriMet, who shared the SLD files from their new map (which we should do a full post on soon, as it’s some great work).

Tim Coulter and Sebastian Benthall are the ones who have done most all the work on the front end, building the application on top of OpenLayers.  Eventually we hope to turn it in to a more generic tool for others to make similar maps.  They’ve been working against a nice specification from TOPP’s great interaction designer, Mouna Andraos, which should evolve to full on wiki editing (current target just tracks history).  Eventually we should have some nice blog posts on how they’ve gone about building a new application on top of OpenLayers.

On the backend David Winslow and Arne Kepp have been taking the lead, and thus have been more active on the GeoServer lists and irc’s.  They’ve stood up the GeoServer for it, and are putting in the hooks and improvements to have OpenPlans utilize it as a backend, including making a module that can authenticate OpenPlans users, a REST API to create new layers on the fly, and caching improvements so it will perform better.

Arne has done a great job tackling more of the sys admin side of setting things up and deploying, and adapting TriMet’s SLD’s to the new york data set.  In the process of doing that he’s had some promising experiments with Varnish to do extremely fast tile caching.  Following up the caching angle he’s now working to improve and incorporate JTileCache, Chris Whitney’s Google Summer of Code project, as a community module that can drop in to GeoServer.   He reported on IRC today that he’s got response times from it down to under 2 milliseconds, about as fast as TileCache under mod_python.  Arne’s also helped out on the REST configuration interface, and done some nice bug fixes and improved the WMS reflector, which will get blogged soon.

David has become the resident REST and RESTlet expert, starting with a REST User Management API to query and create users on the new security subsystem based on Acegi.  After that he’s taken on the lead coding up the REST configuration API, which will replace the incredibly hacky ‘alternate for reloading the catalog’ to enable programmatic manipulation of GeoServer.  Recently he refactored his work to make it easy to plug in alternate output formats, starting with html and json, and soon xml.  He’s also done some nice bug fixing, improving KML output with the lookAt tag to zoom in to the data automatically, and tweaking the pop-ups to be easier to click on.  David also took the read on hooking the security sub system up to the OpenPlans way of authenticating, which he will hopefully blog soon, as it’s a nice example of how to use the tools in GeoServer to work with an existing security system.

We are pleased to announce GeoServer 1.6.0-RC1 is available for download (try direct from sourceforge if that link isn’t working). Since beta4 the team has has closed over 60 issues, tightening up every single detail. This is easily the most solid first release candidate that we’ve ever issued, as we are wanting to have as few release candidates as possible. So if you have not upgraded to the 1.6.x series then now is the time to do so, to ensure that any problems that may arise get fixed as quickly as possible, before 1.6.0.

The 1.6.x series is a major leap forward from 1.5, with major leaps in performance, WFS 1.1 support, and the new ‘versioning’ WFS. There is also much better support for Google Earth and Google Maps/Virtual Earth/Yahoo! Maps, leveraging better integration with OpenLayers. There is also a new integrated security subsystem, built on Acegi, to provide role-based access control to GeoServer resources. But the real reason to upgrade to 1.6.0 is a ton of bug fixes, all the rough edges are getting sanded down, so that most all features ‘just work’, no matter what you throw at them. So please download and let us know how it goes.