About the roadmap

This roadmap represents the current vision for the future of the GeoServer Project. This is not a set plan, nor is it a company promising you some feature list that we can make a false demo for you and implement after you plunck down $75,000. This is an invitation to join a movement towards greater software independence, and a vision of what can easily come to be if we work together. This map is by no means set, indeed for now this represents a reflection of the community. We work to decide things by consensus, and flow where there are resources to accomplish changes. If you want to see any of these move faster, then you can work with the community, and provide resources, and we will work with you to make it happen.

The way we write new code has evolved from branches to a more modular system. Developer can do new work in an 'unsupported' module, and when it comes up to snuff it becomes integrated with the core. Working in this way allows us to enable more innovative work occur while maintaining a high degree of stability on the main code path. And when needed developers can also branch and later bring their code home, but our hope is that most work won't need to branch.

Short Term Projects (finishing spring 2008)

These projects are currently funded, and being performed by core developers. You can expect to see them in the code base in the coming months. If you are working on something that should be added to GeoServer soon, let the list know, and we can schedule it in for release.

Visual SLD editor

This will be a pure ajax editor, probably built on openlayers and ext. It will allow anyone to visual compose what the map should look like, in a (hopefully) intuitive graphical user interface. This should be available as an independent application and as a part of GeoServer's web admin.

Thematic SLD mapping

This hopefully will integrate with the visual SLD editor, but is another branch of ongoing work by the Ominiverde crew. It consists of a server side component to calculate the various intervals requested by the user, based on the dataset, plus an openlayers based gui to let users select the various colors, as well as number and types of intervals. The server side is a nice use of RESTlet to make an API that serves up the portions of SLD needed, as well as the calculations done by GeoTools on the intervals. This is a nice example of reusing something originally developed for uDig on the desktop for the web.

JTileCache is becoming GeoWebcache

Chris Whitney's Summer of Code project was a great success, and has found additional life as a rebranded GeoWebcache, which should launch soon. It is a pure Java tile cache, with JCS as the backend. It is quite fast, and should have a 0.5 release soon. We hope to integrate with GeoServer soon after that.

Rest Configuration API

Work has also been happening on a programmatic configuration api built on REST principles. Soon we should have an API that allows remote services to add and configure shapefiles and geotiffs. And it should hopefully expand in the future.

KML enhancements

GeoServer's KML support is being enhanced. The first goal is to make it so it can be crawled by Google's Geo Search, see Exposing to Geo Search for the initial thoughts. This will mean that all open data served by GeoServer will show up on their search index. The second improvements are for super overlays, both rasters and vectors, to give the streaming effects that are standard for Google Earth, but not for third party network links.

WCS 1.1

GeoServer is working in the OGC's OWS-5 to make GeoServer the reference implementation of WCS 1.1, it's mostly done on trunk, and continues to be tested and improved as the CITE tests are developed.

Better docs

Yes, oh, yes. We are finally going to spend some time really improving the documentation, hopefully making some screen casts, and just making GeoServer more friendly and accessible, especially for new users.

H2 datastore

Currently one can work with shapefiles directly, but they weren't really built for lots of transactions. It'd be much more secure to have a real java database embedded in GeoServer. With this in place one could upload a shapefile, but it would be stored in the database, and could then be exported out as a shapefile as well. H2 looks like the current best starting point, as it has full ACID compliance, and performs much more quickly than Derby, the old front runner.

ECW, MrSID, JPEG2000, ect. through GDAL

Work from last summer is finally being completed, to get the more advanced compression raster formats available through GeoServer. They leverage GDAL to do the work, but at a very low level, which should lead to some nice performance. This is done by GeoSolutions, but they have many priorities, so if you want to be sure that these will be released in the short term we encourage you to get in touch with them.

HTML ImageMap support

Mauro Bartolomeoli has made a great community contribution to do html image maps as an output format, we're hoping to get this fully incorporated in to GeoServer and to provide some good examples and samples of it.

GeoView preview replacement

Now that we've got some OpenLayers developers closer to GeoServer we're working on using it to fully replace our map 'preview' stuff, with a real mapping application that can add multiple layers instead of just a bunch of links that one can click on. It should hopefully be the basis of more functionality exposed directly through the javascript map.

Security Improvements

As the security framework settles in to place we'll start improving it as funding comes in, the first improvements will likely be layer/featureType level control over security. We hope to get it working against more backends and the like.

Medium Term Project (finishing summer 2008)

3-D, 4-D, n-D Coverage Support in WCS

The main thrust of the Geo-Solutions team has always been to exploit the more advanced capabilities of the WCS, particularly it's ability to return certain bands and dimensions for further analysis, instead of returning just the 2d image. Very few WCS's have this capability, and no open source implementations do (afawk), so it should be a huge step forward. They are currenlty working away in GeoTools land, see: [GEOTOOLS:Multidimensional Georegistered Grid]. Indeed 95% of this work will take place in GeoTools, since it will still just use the WCS interface in GeoServer.

n-D imageio plug-ins for HDF, NetCDF, and GRIB1

The final Google SoC project is actually a GeoTools project, but will have an immediate win on the GeoServer front. Plugins for multidimensional raster data sources will be done by Daniele Romagnoli, which will work with the new WCS support. He worked with GeoTools last summer, working on integrating GDAL with ImageIO, which should also be released relatively soon.

New Configuration System (and remove STRUTS/JSPs)

The hardest code to maintain in Geoserver is the Configuration System and its GUI. This needs to be replaced with something that makes this task easier - including allowing individual modules to have their own configuration system. This could also include putting in the UDIG/Geotools Data Catalog system. There are many interested people in doing this - unfortunately no one actually wants to put the time in to do it. Wicket and Tapestry seem to be two frameworks that fit in well with our design goals, making it super easy to maintain the gui, and for modules to be added with their own config system. Struts2 is another one we are considering, it's becoming struts 2.0 and works on the same principles as struts. Another potential one, though its a long shot right now, is the recently open sourced Google Web Toolkit.

AtomPub implementation

Though there's no specific funding for this lined up we're pretty sure something should come to fruition in the next 6 months. This should provide an interface for viewing and editing features that is much easier for programmers to work with than WFS-T. We're hoping to follow the lead of FeatureServer, as they've done some great restful work that we can borrow, and it'd be great to have compatible implementations.

Longer Term Project/Dreams

These are projects that are not currently funded, but that we as a community have thought about and many people have said they'd very much like to see. Feel free to add anything that you'd like to see.

Processing (WPS or RESTful)

One of the things GIS types like is to do all kinds of analysis and spatial operations. We hope to build a framework for 'operations' that would live in GeoTools and could be used by uDig as well. In GeoServer we hope to have WPS and REST interface to allow people to access the processing operations. This should not be all that much work, we've just not heard of anyone actually interested in contributing code or funding the work.

Configure on arcgis/udig/gvsig and export to GeoServer

It would be great if we could allow users to easily convert existing projects to GeoServer, to have an 'export to GeoServer' button in leading open source and proprietary software. The biggest win is probably conversion to SLD. This is trivial with uDig, since it uses SLD natively. Not sure what's needed for gvsig, I think they are working on SLD export. For esri stuff I found some deegree code that converst from AVL to SLD, which is java so we could maybe just use. Then there is arcmap2sld, which looks like it works pretty well. At the very least we should include it in some SLD tutorials. Eventually it'd be great to work on a tool that directly exports a map from the esri desktop to GeoServer.

"Hibernate" Datastore

Once the [New Feature Model] - that allows for complex features - has been completed, a hibernate (or other object-relational mapping technology) datastore could be developed that allows Geoserver to be directly integrated into an exisiting infrastructure.

SVG Output Improvements

Soon most browsers will natively support SVG display. This opens up a wide range of opportunities if geoserver can generate "nice" SVG output. The current SVG support is either streaming with no advanced styling and quite fast, or quite slow, but with full use of SLD. We'd like to get a fast and style conscious SVG renderer.

Better Support for DataStores

There are several "well used" datastores - PostGIS, Oracle Spatial, ArcSDE, DB2, and Shapefile. Getting good module maintainers is important to get Geoserver uptake.

Open Source ArcSDE

Enough pieces are falling in to place to make it so GeoServer could serve as an open source equivalent to ArcSDE, an extremely powerful piece of GeoSpatial Middleware, spatially enabling databases, managing users and their editing capabilities, doing caching, and linking different datasources. See Open Source ArcSDE for some more ideas.

Tile Processing on EC2/S3

Would be cool if we had a really easy way to defer all tile processing to amazon's ec2, that could fire up a bunch of instances at once and process the tiles incredibly quickly.

Platform for a Public Commons of Geographic Data

See: Platform for a Public Commons of Geographic Data

We hope to present a decentralized plan of action, that a variety of community members can take up. This focuses on the broader strokes, but there are many, many small opportunities within it all. Helping with debugging and individual features within the bigger projects, or working on different aspects to make GeoServer even stronger. We just want to have this up to show that there are ways to really get invovled, and to show that when it all comes together we will have something incredible. You can also view a more detailed roadmap on our jira task tracker , and we will try to integrate this document and the individual tasks in the future. Please put up comments and feedback on the roadmap, the direction is shaped by you!

See Also:

• 1.4.x
• GeoCollaborator
• GeoServer Modularization — toward a pluggable web GIS framework
• SLD Editor
• Tiling