Lately, I have been working on adding support for the **TIME **attribute for GeoServer in WMS GetMap requests via an improvement of the ImageMosaic raster store:

`http://yourserver/geoserver/wms?REQUEST=GetMap&...&TIME=2009-12-12,2009-12-13&...`

You can get some more details on the GeoSolutions blog.

Ciao a tutti,

Supporting a project such as GeoServer requires a great investment of time and resources. Organizations that support it are faced with the problem of finding funding. As founder of my own company, I often find myself in the position to seek funding for supporting GeoServer and I obviously tend to prefer large contracts to small ones. This seems perfectly reasonable, however I do recognize that in the long run this approach may cause some missed opportunities. Large funding usually focuses on large developments, but they leave aside common glitches and bugs, i.e. isolated features that are not working properly or could be improved relatively easily. To counter this, supporting organizations must invest surplus money and resources from other contracts into tackling these problems, since it is difficult or inefficient to chase money to address each small issue separately.

As a specific example, I have lately seen people struggling to get the ImagePyramid extension working, and I know it would be relatively easy to improve things (in that it would not need a lot of funding) but none of our current clients needs this functionality, so the work never gets done.

With this in mind, I have come up with the following idea: once someone, be it a user or a support organization, recognizes an issue/missing feature that no one else wants or has funding to fix, we should try to describe the problem/feature somewhere (such as on this blog), provide a Point of Contact (POC) for the work and then ask the community for an Expression of Interest (EOI) to check whether there is enough momentum/desire to fix/implement. Perhaps the POC should write the proposal having already scoped out the work or maybe the scope should wait until we know that there is enough interest. Another topic where I would see some interest is in whether the process should be completely transparent or not regarding who gives the funding as well as who spends the funding gathered. I would be interested in feedback on all of these suggestions.

To test his idea, I would like to invite anyone who might be interested in providing a bit of funding to improve the support for the ImagePyramid extension in GeoServer to express your interest to me. Specifically, I am talking about automagic import from GDAL retile, improved stability and performance, and/or automagic pyramiding as a GeoServer/GeoTools utility.

If you are interested you can drop me an email at simone.giannecchiniATgeo-solutions.it.

Ciao, Simone.

After a nice showing at the FOSS4G Tokyo and Osaka conferences we decided the time had come for a new GeoServer language users mailing list.  Taking advantage of the fact that GeoServer just got accepted to OSGeo incubation the new list is on the OSGeo infrastructure, at http://lists.osgeo.org/mailman/listinfo/geoserver-jp The mailing list is a resource for those who would like assistance in all things GeoServer, but prefer to discuss in Japanese.  This marks the sixth language mailing list for GeoServer.  We’re hoping soon the community gets a translation of the new UI, and some Japanese docs as well.

It’s official!  We are pleased to announce that GeoServer has been accepted into incubation at the Open Source Geospatial Foundation (OSGeo).  Putting GeoServer under the same roof as all the best geospatial projects in the open source world is a great advance for the project.  While GeoServer is not yet an official OSGeo project, just getting accepted in to the incubation process is a firm indicator that we are on the right track.  The process makes sure that we meet all of OSGeo’s standards for a diverse community, a robust governance structure, and clean code that others can rely upon.  We believe GeoServer has all of these, but additional validation from a third party like OSGeo signals to the world that it is so.  Thanks to the incubation committee and the board for approving our application, and to Richard Gould for serving as our mentor.  And of course to the whole GeoServer community for taking us here.

It has been a long time coming but it is finally here. GeoServer 2.0 has been officially released and is available for download. The 2.0 release marks a major milestone for the GeoServer project. A special thanks to all the developers who worked hard for this release, all the users who contributed bug reports, and for those who provided feedback by testing out the 2.0 release candidates.

So what is new in 2.0? The first new feature that people will notice is a completely new web administration interface. Based on the Wicket framework the new user interface provides a much more integrated and streamlined application for configuring GeoServer. Wicket makes developing ajax enabled applications trivial by doing all the hard work for you.

One of the powerful features of Wicket for the developer is extensibility. Wicket allows one to plug-in components dynamically. This means that developers can now easily write plug-ins and extensions for the GeoServer UI. And some have already done so. Francesco Izzi and the developers from the geoSDI project have contributed a plug-in for configuring the GeoServer security sub system. Special thanks for the great contribution.

The 2.0 release also hails the home coming of the “complex features” branch and true support for application schemas. Led by Ben Caradoc-Davies and Rini Angreani, developers from CSIRO have made this functionality available in the core of GeoServer. Special thanks to them and to AuScope for funding the work. Check out the documentation for more information about getting started with application schemas.

New features has not been the only focus of 2.0. Much work has also gone into scalability and performance in order to ensure that GeoServer continues to improve not only in terms of new features, but also that it continues to get faster.

Much of this work came in preparation for the WMS Shootout at FOSS4G in Sydney this year. Great thanks goes out to Andrea Aime for not only representing GeoServer in this benchmarking exercise, but also for the countless number of hours he has poured into improving GeoServer performance and robustness.

As with any release many minor features and bug fixes have gone into 2.0. Be sure to check out the GeoServer Past Present Future talk given at FOSS4G that provides an overview of what else has gone on this year in preparation for 2.0.

Download 2.0 now and try it out. Please help us to continue to improve GeoServer by reporting any issues you encounter on the mailing list and bug tracker.