Page 1 of 1
GeoServer: A Geospatial Server for Everyone
Justin Deoliveria
Developer, GeoServer
jdeolive@openplans.org
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' (
http://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 (
http://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
(
http://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 (http://geoserver.org) to find out
more about what is happening. Or send a message to
the mailing list (geoservers-users@lists.sourfceforge.net)
to voice an opinion about
what features and
improvements they
would like to see in the
coming future.