Though it’s a bit overdue, we finally got around to updating the GeoServer Roadmap. There’s a lot of activity going on, and we generally have a good sense of what should be completed in the next three months, with more and more vague ideas on what may be further out. I still want to work some more on the long term / dream section, as I’ve had some more fun thoughts recently. But there should be a lot of great work in the next few months, which is exciting. Highlights include online SLD editing, integrated tile caching, security improvements, a better ‘preview’ application, and more. The thing I’m most excited about is the REST configuration service, which should make it much easier to add data programmatically, and is how we’re going to integrate with GeoNetwork Open Source.
The best part of updating the roadmap is looking back at what we hoped to accomplish and seeing what we succeeded in. This time is a bit of a softball, since we are late on updating so the ‘short term’ ones were supposed to be finished several months ago. But we aimed to do quite a bit, and most of it has come to pass. GeoServer 1.6.x is just about to go to 1.6.0, with not only a new security framework, WFS 1.1 and versioning WFS, but also great increases in speed and reliability. KML support has improved a lot, and is only getting better, as we have some more funded work to make it stream large datasets really well. The new output formats - GeoRSS, 8bit PNGs, and GeoJSON are now all released and performing well. And we’ve got a new security system and backend for geocollaboration. The prototype for a GeoServer 2.0 was built, and feels ready to move on, though unfortunately it has not moved much past a prototype phase. The only short term goal that was not completed was ECW, MrSID and JPEG2000 support, but those are actively being worked on right now, and we expect at least one pretty soon. Thanks to everyone for all their hard work, things are really coming together in to a great product, and the future looks even brighter - we’re truly only just getting started.
We are happy to announce the third release candidate for 1.6.0. You can grab it from SourceForge.
That coveted 1.6.0 release is getting closer and closer and we are almost there. The previous release candidate brought out some performance related issues. A memory leak issue and a problem with filter parsing leading to stack overflows. These have been fixed along with some other minor bugs addressed as well. For a complete list of all the good stuff check out the changelog.
Special thanks to everyone who tried out RC2 and reported issues. You can continue to help us get the official 1.6.0 release out by trying out this release candidate and reporting any issues in the bug tracker.
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.
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 height 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
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
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.