GeoServer

GeoWebCache is finally out in the open and announced on freshmeat.net and other pages. This should really have happened a long time ago, and there are many reasons for why it didn’t, but I am very excited about the current momentum.

GeoWebCache, is a tile cache, meaning it acts as a proxy between the client and the WMS server (GeoServer) and stores the image. If another client requests the tile it can respond in milliseconds, regardless of the complexity of the tile. It is different from a regular HTTP proxy, such as Squid, in that it interprets the parameters and matches them to the best tile supported by the configuration.

It is currently not as mature as say Tile Cache, but has the advantage that you do not need a webserver with Python support. It can either be run in Tomcat, alongside GeoServer, or as a standalone server using Jetty (no binaries are available yet, but we will make them soon).

We have not been sitting still since releasing 0.6.0 either. Based on a customer request we have already added native support for Microsoft Virtual Earth’s quadkey scheme. This is currently available in the repository, and we’ll probably push it out in a new version soon, after looking into whether we can do the same for the Google Maps API.

Looking to version 0.7.0 and beyond we will start working on integrating GeoWebCache more tightly with GeoServer. Some key features are

• Automatic configuration based on what layers are available . This will obviously have some limitations, since there are important parameters that the user will have to make some decisions on.
• Update events, so that when the data changes on the backend GeoWebCache will automatically purge the affected tiles and (optionally) reseed them.
• A nice RESTful API that we can program an easy to use JavaScript client against.

There are some internal structures that should still be simplified, and now that the basic structure has solidified we’ll gradually start adding tests.

Want to see it in action? http://sigma.openplans.org has been using GeoWebCache for over two months (and uncovered some bugs in the process). We look forward to upgrading the site with something that is really pretty to look at, probably soon.

Please sign up to the mailing lists if you are interested, we’d love to hear back from you so that we can fix bugs, improve the documentation and stake out the general course.

The GeoServer team is excited to announce that GeoServer 1.6.0 has been released. There are a host of advances from 1.5.x, and many GeoServer users have been testing the release candidates and giving us great feedback, so this final release should be very stable. Foremost among the improvements is a huge performance increase in the rendering of maps (WMS), bringing GeoServer speed that matches the fastest mapping engines in the world. The other big focus has been on tightening everything up, as we’ve been getting more and more feedback from production deployments of GeoServer (which we’ll highlight soon in this blog).

The most cutting edge new feature is support for ‘versioning’ as extensions to WFS-T. This allows users to edit geographic data as if it was a wiki or in a version control system like svn. You can check out the preliminary demo, though we’re working on a more intuitive user interface. The start of that can be seen on our New York annotation demo, which also has a base map served by GeoServer. Right now only PostGIS can support versioning, but we’re hoping to find funding to hook it up to the native versioning in ArcSDE and Oracle Spatial.

There are also a number of other new features, including WFS 1.1 support, which adds reprojection when accessing raw data, as well as the ability for queries to return the number of results expected before getting the full results. We’ve also added a new integrated security subsystem, built on Acegi, to provide role-based access control to GeoServer resources. There is also improved connectivity to Google Maps/Virtual Earth/Yahoo! Maps, leveraging better integration with OpenLayers as well as bug fixes for our Google Earth support.

Also added is the WFS datastore, enabling GeoServer to serve as a Cascading WFS and a Component WMS (also known as a Feature Portrayal Service). Another cool improvement is our WMS reflector, which makes it a lot easier to experiment with map rendering through the browser. There are countless other improvements and fixes, in all over 400 issues were handled for the 1.6.0 release.

Stay tuned for the 1.6.1 release, we’ve already got a bunch of improvements lined up for it that we’ve held off on to get 1.6.0 absolutely stable. Thanks to everyone for all your hard work on this one, it’s a great step forward for this community, and the future is looking quite bright. And just to give the link one more time, the release can be downloaded from geoserver.org.

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.

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.

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.

So it’s been way too long since we posted anything on this blog other than release announcements.  Which is not as it should be, since there’s been a ton happening in the GeoServer community.  I’m going to try to catch up with a lot of the various news in the next week or two, but wanted to just mention things here, which should force us to actually blog about them in more depth soon.

The first big category is the FOSS4G conference.  The conference team did an amazing job, so first just want to thank them for all their hard work.  From the GeoServer perspective it was easily our best conference yet, with a number of talks from developers and users.  In coming posts I’ll highlight the talks more, with links to check them all out.  The conference is definitely the highlight of the year for those of us working on the project, because we get to meet so many excited users.  Both those that we’ve seen on the lists before, and people who have just been happily making use of GeoServer and had no reason to get in touch with us.  We also get invaluable feedback on the features users actually care about.

After the conference we had a successful ‘code sprint’ - most projects sprinted on Friday, but the hard-core GeoTools team followed up working through the weekend.  Thanks goes out to Refractions for hosting us, giving us space to work away.  We worked on the biggest elephant in subversion - the new feature model that allows us to deal with complex types.  Its had many years of effort, many failed branches, and just became a scary task that seemed like it might never be done.  But Justin worked for months preparing for the sprint, where we moved almost everything to use the new way.  Initially uDig will see the results of the work first, but it was some nice implications for GeoServer - serving up set schemas from arbitrary data - when someone comes up with a bit of additional funding/time.

In other news we’ve been getting some great contributions of late, which I’ll write about soon.  The Open Planning Project, the primary maintainer of GeoServer, is also working on some exciting stuff, including mapping integration with the other main project - OpenPlans.  The end result should be a really nice user interface for groups to make annotated maps, with full wiki-like editing, about the issues they care about.

The GeoServer team is pleased to announce the availability of the latest stable release, 1.5.4.

This release mostly cleans up stuff for Google Earth and Maps.  Generated maps now line up perfectly on Google Maps, with a fix to the projection code.  This allows us to replace the Google Maps overlay demo with OpenLayers, so it works with GMaps, Yahoo! Maps and Virtual Earth.  Google Earth will now zoom to the exact location of the dataset, and has further support for ‘time’ elements.

There are additionally a few improvements for Oracle users, including proper Shapefile output, and the ability to run in an Oracle Application Server.  Also new is Arabic rendering support and fixes for serving additional content through GeoServer.

Full changelog is located here.

This release is based off the brand new GeoTools 2.3.5 stable release.

Thanks to all the users and contributors who helped out with testing and feature suggestions, this project would not be possible without all of you.