Developer, GeoServer
[email protected]
If asked to sum up GeoServer in a single sentence one could say that it is 'an open source server for publishing geospatial data'. However this definition hardly does justice, as there are a variety of different aspects to the project. Depending on where one is sitting, GeoServer can look like something different.
To the geographer it is a system which provides mapping functionality. To the data provider it is a technology used to publish geospatial data onto the World Wide Web. To the programmer it is a Java Enterprise (J2EE) web application deployable into any J2EE application server. To the standards body it is the implementation of a number of open web standards such as Web Feature Service (WFS) and Web Map Service (WMS).
THE GEOSERVER PROJECT
The GeoServer project was started in 2001 by The Open Planning Project (TOPP), a small non-profit company based out of New York. The initial target for the project was to enable access to the data behind maps, to utilize it for analysis and modeling. However it evolved quickly. At around the same time the Open Geospatial Consortium (OGC), an organization made up of industry experts who define geospatial web services, published the Web Feature Service (WFS) specification. WFS defined the protocol of a web service for serving geographical data in vector format. TOPP felt that while an open source implementation of WFS applied directly to their needs, it could also have an immediate value to other organizations as well. This in turn could help to improve spatial data infrastructure in the United States.
Since then GeoServer has grown significantly. GeoServer 1.0 was released in October of 2003. That month Source- Forge tracked approximately 500 downloads of the GeoServer package. In August of 2007 GeoServer 1.5.3 was released, with the number of downloads for that month at approximately 8500. As the download count and general activity around the project grew, so did its community of users and developers. It is the strength of this community which has made GeoServer a success. The project has always been open not only in terms of source code, but also in terms of process. Management of the project has always been delegated to the wider community and not driven solely by the agenda of a single organization. While it is true that TOPP has been the primary source of funding for day to day maintenance, the project is managed by the greater community made up of individuals from a number of organizations. The Project Steering Committee (PSC) is made up of experienced developers and users from six different companies spread world wide.
It is this type of open process that has led to the contributions and development which have made GeoServer what it is today. GeoServer 1.0 was mainly the work of TOPP funded by the OGC to implement the WFS specification. Shortly after the 1.0 release, a programmer working for a Spanish commercial company implemented WMS support with funding from the Basque government. GeoServer 1.2 saw a contribution from Refractions Research, a Canadian based company well known in the open source world for developing PostGIS. Refractions built a data validation engine and also developed a web based administration tool. In 2005 GeoServer saw the addition of a Web Coverage Service (WCS) and full raster support, a contribution made by an Italian company known as GeoSolutions.
SUCCESS STORIES
One of the biggest GeoServer success stories has been The Office of Geographical and Environmental Information of the state of Massachusetts. known as 'MassGIS' (https://www.mass.gov/mgis/). They are using GeoServer to serve base map data for the entire state of Massachusetts. Saul Farber, a technical lead at MassGIS Web Services, is also an active GeoServer developer. Saul's interaction with the project really shows the power of a successful open source community. He started off as a normal user who decided that GeoServer could potentially be a good fit for his organization. After a few months of being active on the mailing list and submitting patches, Saul was granted full GeoServer commit status. Currently he sits as a member of the Project Steering Committee and is regularly submitting improvements and bug fixes. This is the perfect model of how an every day user can become part of the community and have a voice in project management and overall direction. A various number of other organizations are also using GeoServer in production systems. The Great Lakes Commission (https://www.glc.org) is using GeoServer to publish data on their Great Lakes Information Network. They have made a variety of layers available including elevation/ bathymetry, hydrography, geodetic control, cadastral, transportation, administrative /governmental boundaries, and orthoimagery. Landgate (https://www.landgate.wa.gov.au/) maintains the Western Australia State's official register of land ownership and survey information and is responsible for valuing the State's land and property for government interest. They are currently using GeoServer to serve their data as WFS and KML, including layers with building footprints, acid sulphate soil risk, bush fire services districts, apiary sites, cadastral,forest disease risk areas, public drinking water source areas, and more.
It is these 'real world' uses that validate GeoServer as a true competitor in a GIS world dominated primarily by proprietary software. Beyond the advantages that come with being purely open source, GeoServer comes out ahead of the proprietary counterparts in a number of other areas as well. Being built on open standards like WFS and WMS means that any service offerred by GeoServer speaks an 'open' protocol. The benefit of such a protocol is that any organization wishing to implement it can do so. This means that any client that supports the protocol can talk to any server that also supports it. The upshot of this interoperability is that GeoServer can communitcate with a variety of clients, both proprietary and open source. This gives the end user a choice instead of being locked into a single solution based on software which communicates over a propreitary or closed protocol.
ENHANCEMENTS
Something that users have continually commented on is the ability of the GeoServer project to quickly adopt new innovations and technologies in the web mapping world. GeoServer was one of the first products to provide KML output with Google Earth and Maps. Which to this day remains superior to any other servers capability of producing KML. Shortly after the Web Map Service Tiling recommendation was released, GeoServer implemented tiled rendering for WMS. Formats like GeoRSS and GeoJSON, which have been increasing in popularity, were implmeneted shortely there after. This type of rapid feature support pays tribute to the agility of the project and its ability to stay on the cutting edge. The best part of all is that users gets these features for free, instead of having to pay a fees that come with proprietary software packages.
While new and exciting features are always the focus of development, so is constant work on improving system stability and performance. The GeoServer 1.6.0 release came with some significant performance enhancements. A talk at the 2007 Free and Open Source for Geospatial (FOSS4G) conference, presented benchmarks of GeoServer against other WMS software. To the surprise of much of the audience GeoServer came out as being a faster than the competition.
GEOTOOLS
Being written purely in Java, GeoServer has a strong relationship with other open source Java based GIS projects. Much of the 'hard work' that is done inside of GeoServer such as reading and writing of various spatial data formats, coordinate system transformations, and rendering are provided by other libraries. Many of the GeoServer core developers are also active developers and contributors on these other projects. The most notable of these is Geotools, which predates GeoServer by a few years. Geotools is a general purpose GIS toolkit which provides much of the functionality that is fundamental to any GIS.
Geotools is an extensive library. For those readers who may be familiar with open source GIS toolkits in the C world, Geotools is the equivalent of PROJ, GDAL, and OGR all lumped into one. Support for geographic coordinate system transformation is very complete, including shifts between spheroids and datums. The library also provides the low level drivers for a wide variety of spatial data formats. The list of supported vector formats is extensive and includes many file based formats like ESRI Shapefile, Geographic Markup Language (GML), MapInfo (MIF), Vector Product Format (VPF), and GPS Exchange (GPX). In addition is support for spatial databases such as Post- GIS, Oracle Spatial, MySQL, DB2, and ArcSDE. A more recent addition to the toolkit has been raster support. This includes common formats like Geotiff, World Image, Ascii Grid, Network Common Data Form (NetCDF), and USGS DEM (GTOPO30). Furthermore are tools for building image mosaics and pyramids for high performance raster access. Currently under development are the drivers for the Enhanced Compression Wavelet (ECW) and Multi-Resolution Seamless Image Data (MrSID) formats, which are geared toward efficient access of extremely large volumes of raster data.
JTS
At the heart of Geotools and GeoServer lies the Java Topology Suite (JTS). JTS is the core geometry engine used for representing geometric objects and the relationships among them. It contains robust implementations of all the spatial predicates including intersection, containment, and touching to name a few. The term 'robust' in this context is used literally. The implementations of the various spatial predicates handle all corner cases involving 'strange' coordinates which often lead to failures in other libraries and implementations. This property of robustness is something that is unique among similar products, both proprietary and open source. So much so that a C++ port of JTS was created. Named GEOS, it serves the same function to many GIS applications which are written in C.
LIBRARY INTEGRATION
The relationship to other open source projects is not limited to geospatial. GeoServer makes use of a number of other open source libraries. The most notable being the Spring Framework, a full-featured framework for building Java applications. Over the last few years Spring has become one of the most widely used frameworks in the Java world, particular in the enterprise. Anyone who has done any non-trivial Java enterprise programming can attest to the fact that the components of a J2EE application can become quite complex. JSP, JMS, JTA, and JDBC are just a few of the many technologies that can make up a single application. One of the advantages of Spring is that it simplifies all of that. Spring provides support for the wide variety of Java enterprise technologies while at the same time providing an abstraction on top of them. This in turn provides a much simpler programming model for building applications which does not require a programmer to learn the entire J2EE stack.
GeoServer was not always based on Spring. The move to Spring occurred in 2006 and was driven from the desire to make GeoServer less monolithic and move to a more component oriented architecture. The end goal of this was to lower the entry barrier for new programmers wishing to join the project. The idea being that a component based architecture would allow developers to get up and running quickly by extending GeoServer via simple and isolated plug-ins, rather then having to learn the inner works of the entire system. When evaluating various frameworks to use in the implementation of a new modular GeoServer, it became evident that something non-invasive would be needed. While application frameworks are nice in that they provide much base functionality out of the box, they also come with the price of having to implement a number of interfaces and routines used by the framework. If a wealth of code is already in place, as was the case with GeoServer, this price can be quite high. This non-invasive nature coupled with a very rich set of API's led the project to choose Spring. One of the biggest benefits of the move to Spring was a complete security subsystem. Called 'Acegi', it is a security framework which works seamlessly with Spring applications.
It supports a wide variety of authentication schemes such as basic and digest based authentication, LDAP, and more. To this day the issue of security has been largely ignored in the world of geospatial web services. Security remains a gaping hole in open source and proprietary products alike. While it is still in its infancy as part of GeoServer, Acegi has a lot of potential and is something that will be a focus of development in the future.
Also among the popular libraries used by GeoServer is Freemarker, an open source 'template engine'. A template engine is a tool which takes data, runs it through a series of rules and logic (the template), and produces a presentation of that data based on those rules. One of the problems with open source software like GeoServer is that sometimes an application can be too generic. It may provide 95% of the functionality a user requires, but is missing that last little bit. The answer to this dilemma is a template. A template puts the control in the hands of the end user by allowing them to specify what the presentation of the data should look like. One of the more popular uses of templates in GeoServer is with KML, the data format used by Google Earth and Maps. The KML format has the notion of a 'placemark', which is used to signify the location of some object.
A placemark also provides a description of whatever is at that location. The description can be anything from raw text, to an image or graphic, to some HTML. The contents of a placemark description are something that is unique to that specific dataset so it makes sense to have the user design the template themselves. Creating a template is as easy as opening a text editor like Notepad, writing the template which follows a simple markup syntax similar to HTML, and saving the file to a special location. The user developing a template has the full power of the Freemarker library at their disposal allowing them to perform tasks from simply filtering attributes to creating some elegant HTML.
FUTURE
The future for GeoServer continues to look bright. With the community and interest around the project continuing to grow 2008 should prove to be a great year with some exciting new developments on the horizon. People can expect continued work on the versioning extensions for WFS. Data versioning has always been something only available with expensive 'high-end' solutions like Oracle and ArcSDE. The prospect of providing versioning out of the box with GeoServer is a constant source of excitement among users. Also of much anticipation is the integration of an embedded transaction aware tile cache. Codenamed 'GeoWebcache', this feature will address the static limitations of conventional tile caching when working with data that is constantly being updated. These are a few of the many innovations that have yet to come. Readers are encouraged to visit the GeoServer home page (https://geoserver.org) to find out more about what is happening. Or send a message to the mailing list ([email protected]) to voice an opinion about what features and improvements they would like to see in the coming future.
