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.

The Open Planning Project is pleased to announce that they have hired long time GeoServer community member and contributor Gabriel Roldán as a software developer and solutions consultant.  He will remain based in Spain, and hopefully should help raise awareness and cooperation with other Spanish open source projects and organizations.

Gabriel first started on GeoServer in 2003, as one of the first outside contributors.  He did the integration of gt2wms to add WMS support to GeoServer, with a nice core rearchitecture to allow more services.  He also started the ArcSDE module and added SVG output to GeoServer.  We are very excited to have him soon working full time on GeoServer.

One concern in this is that TOPP developers are dominating the community, which is not desired at all.  Thankfully there are more contributors coming on all the time, indeed some were talked about in the last post.   But none of the new ones are yet on the Project Steering Committee, which sets the direction and makes major decisions about the future of GeoServer. It is likely that Gabriel will step down from the PSC, at least until there are enough other members that TOPP doesn’t have a majority.  Which is to say, please continue to get involved, and your hard work will be rewarded by a position on the PSC.  We want the community to truly drive this project, TOPP sees itself as a steward to help make a truly open, sustaining project that benefits all.

One thing we’ve wanted to do with this blog is use it as a forum to allow people to follow what’s going on in the world of GeoServer without having to dive in to hundreds of messages per month on the lists. I’ve been blogging long enough to know that I should never make promises about how often posts will come, but I will say that more of these will come in the future.

The most exciting things to me are a few new contributions that are becoming community modules, with their authors joining the community. The first one to bubble up has been adding support for GeoServer to create an html image map, there were several discussions on the lists, with a couple different approaches developed simultaneously. The result is that Mauro Bartolomeoli is in the process of putting his code in to a community module, there is a wiki page describing it, and the code is currently attached to the jira issue tracking it. We hope to get the code in svn and get a plugin release relatively soon. This feature enables users to make a map with tooltips and pop-ups and the like, having it directly composed by GeoServer. Since it is html that is returned this can scale a lot better than returning features and having pure javascript display them.

The other contribution in the works is some great stuff by the Ominiverde team, focusing on styling and a RESTful service for SLD. No wiki page or code yet, but they sent an email to the list describing the work, with a link to a test live service. This should be the basis of a nice thematic mapping gui based on openlayers. The cool thing is it will leverage code from uDig, to enable all the nice work they’ve done there, but in a web environment.

The other thing I’ll mention here, that I think hasn’t spread very widely, is that the latest version of GeoNetwork includes an embedded GeoServer. This is being used as a base map on top of which other layers can be added. The integration is still pretty minimal, GeoServer is basically just providing a nicer base map. But there is some work coming soon to do a tighter integration, so that users will be able to upload a shapefile or geotiff through GeoNetwork and have it automatically available through GeoServer as WMS and WFS or WCS, picking up all the service metadata properly. Andrea Aime is currently in Rome, discussing this with developers and users at the GeoNetwork conference this week, where he also gave a workshop on GeoServer.

There’s much more happening, on a variety of fronts, but we’ll save it for another post.