GeoServer: Uniting the GeoWeb and Spatial Data Infrastructures Justin Deoliveira The Open Planning Project United

States of America jdeolive@openplans.org Abstract While SDI initiatives have slowly been making more and more data accessible, the emerging 'geoweb' has greatly increased the amount of spatial data available. Google's Earth and Maps products have opened up spatial information for non-gis professionals. While the uptake of these products has led to an increase in the amount of spatial data on the web, 'real' spatial data still remains elusive. GeoServer's goal has always been to make geospatial information as accessible as possible. In the past this has amounted to delivering solid implementations of open standards on top of robust support for a variety of spatial data formats. However as the more consumer-oriented geoweb emerges, so do new ways of exposing geospatial data. Much GeoServer development of the past year has been focused on providing support for these new geoweb-oriented technologies. The primary goal being to bridge the gap between the good data provided by SDI's and the quickly growing popularity of web mapping and the geoweb. This paper will focus on some of these recent features. This includes support for KML which allows GeoServer to serve data directly to Google Earth and Google Maps. GeoRSS which provides an easy way to overlay GeoServer data into map mashups with Google Maps, Yahoo Maps, and Microsoft Virtual Earth, in addition to pure open source platforms like OpenLayers. As well as the continuing research and development surround the Versioning Web Feature Service protocol which moves GeoServer closer toward the implementation of a 'geowiki'. Introduction Building a Spatial Data Infrastructure (SDI) is a hard problem. Realizing the model of sharing and collaboration among the organizations which participate in a SDI is easier said than done. There are numerous obstacles and challenges that stand in the way. Perhaps at the forefront is the issue of cost-benefit. Obtaining and maintaining good data is an expensive and time consuming process. Sharing this data often defeats the purpose of gathering it in the first place as high-quality data often gives an organization an edge in the market place. In cases where sharing of data is not an issue, more often then not it such a low priority that the effort simply diminishes. Data is used to drive the decisions which solve problems. Once a problem is solved any remaining effort is considered overhead. In a 2006 article, Paul Ramsey refers to the 'operational/analytical divide'. In an article entitled Why SDI's Fail Ramsey writes: I call this problem the "operational/analytical divide", because it happens everywhere, from accounting registers to airline reservation systems. The needs of the people operationally working with the data do not align with the needs of the people driving up analysis to decision makers.

Also of relevance are the technical challenges involved in building the systems to support an SDI. By definition the components of an SDI are loosely coupled. More often then not connected via an internet connection. By nature these types of distributed systems are vulnerable to issues of reliability and quality of service. This makes implementing them hard. These are examples of the issues that make the entry barrier of participating in a SDI a tough one to overcome. This results in implementing an SDI being too expensive or just an outright failure. While organizations work long and hard to solve these problems, companies like Google and Microsoft have come up with their own solution to deliver data to the masses. A solution that addresses many of the problems inherent in a SDI. The end result has been an explosive increase in the amount of data and maps we find available on the web today. While this is generally considered to be a good thing it fails to address the issue of quality over quantity. More data on the web does not necessarily mean more good data on the web. While the numerous small datasets seen popping up everywhere may suffice for the average user who just wants to put a map on their web page, it does not cut it for analyst or scientist who needs to do real GIS work. There still remains a hole in that there is a remarkably small amount of high quality data available on the web today. The problem lies in the divide between SDI initiatives which strive to provide high quality data through a model of sharing, and the consumer oriented geospatial web in which the focus is streamlining the process of publishing data. Tools like GeoServer can help solve this problem. The ability to both consume and publish data in a wide variety of formats make GeoServer ideal for pushing data out to the wider web. In essence GeoServer is the link between a SDI and the rest of the world. The Early Days. The GeoServer project was started in 2001 by The Open Planning Project, a non-profit company based out of New York. The initial target for GeoServer was to be the first open source implementation of the Web Feature Service (WFS) specification. WFS is one of the many standards published by the Open Geospatial Consortium (OGC), an organization made up of industry of experts who publish specifications for open geospatial web services. The WFS specification defines a web service used to publish geospatial data in vector format. Since its inception GeoServer has been closely tied to OGC web services. In 2002 GeoServer became an implementation of the OGC Web Map Service (WMS). WMS is a standard which describes how to publish maps in image format. 2005 saw the arrival of the Web Coverage Service (WCS), a web service for publishing data in raster or coverage format. Today GeoServer is the reference implementation of the WFS 1.0, WFS 1.1, and WCS 1.1 specifications. It also a fully OGC compliant implementation of the WMS 1.1 and WCS 1.0 standards. A primary directive of the GeoServer project has always been to make geospatial data as widely available as possible. Providing a robust and reliable implementation of open standards has been crucial in achieving this goal. Equally important has been the effort to support as wide a variety of data storage formats as possible. Since its birth GeoServer has been closely tied to the Geotools project, the underlying toolkit providing much of the GIS functionality used in GeoServer. Among other things Geotools provides the drivers for a variety of different spatial data formats ranging from vector file formats such as Shapefile, GML, and VPF, to relational databases such as PostGIS, Oracle Spatial, and MySQL to raster formats such as GeoTIFF, GTOPO30, and ECW.

Embracing the GeoWeb. With the arrival of major players such as Google, Microsoft, and Yahoo, the landscape of the geospatial world has changed. Google, armed with a friendly exchange format, a powerful desktop client, and an easy to use API for building web applications has successfully provided a way for users who know nothing about GIS to create maps. They have successfully marketed web mapping to the average consumer. The upshot of which has been an increase in the amount of geospatial data on the web. Central to this revolution is the notion of the 'geoweb'. Wikipedia defines the geoweb as: The Geospatial Web or Geoweb is a relatively new term that implies the merging of geographical (location-based) information with the abstract information that currently dominates the Internet. This would create an environment where one could search for things based on location instead of my keyword only i.e. What is Here?. While perhaps not an authoritative term and something that is being defined as it emerges, the geoweb really just amounts to geospatial data on the World Wide Web. Along with services which allow people to ask questions based on location. Being able to determine the fastest route from your house to school. The ability to find the closest super market to your house. These are a few of the many applications of a geospatial web of information. At the heart of this web are the data formats and protocols used to publish and consume data. Formats such as Keyhole Markup Language (KML), and Geographic Markup Language (GML) which are used to markup geospatial data. Formats like GeoRSS used for the syndication of geospatial content. The Atom Publishing Protocol (AtomPub) which is a protocol used to publish geospatial data as web resources. All of these technologies play a role in the implementation of the geoweb. GeoServer has been quick to adopt these technologies and the new ways of exposing geospatial information that come along with them. In 2007 support for both KML and GeoRSS as output formats for the GeoServer WMS were added. Geographic JavaScript Object Notation (GeoJSON), a simple lightweight vector format, was added to the GeoServer WFS. Support for these technologies and formats is yet another part of achieving the GeoServer vision. They provide alternative ways for pushing data out to the wider web that go beyond the audiences targeted by OGC web services. Google Earth. In 2005 Google released a virtual globe program called Google Earth. A program providing a view of earth satellite imagery draped over a 3D sphere. Almost as impressive a feature as providing a view of the entire Earth at high resolution, was the ability to superimpose ones own data into that view. Allowing users to quite easily view their data in the context of a virtual earth globe. The key to this feature is KML, the XML format supported by both Google Earth and Maps used to markup geospatial information. KML employs a simple geometry encoding model similar to GML. Coupled with a complete set of styling constructs make it a good format for geospatial data. An easy way to put data on a map and the growing popularity of hand held GPS devices has lead to a boom in the web mapping world. Georeferencing photos from a family vacation, sharing a favorite hiking path with a friend, and tracking a trip around the world are a few of the many applications of KML. While KML is quite handy for these types of smaller applications, it does not suit those who must serve any substantial amount of data. Furthermore are those who already have data in a different spatial format. In order to put this data onto a Google map it must first be converted to KML. Even then it is problematic to have to maintain data in two different formats. The answer to this problem is a tool which can convert from a native format to

KML on the fly. GeoServer is one of these tools. GeoServer can convert from any of the data formats it supports natively to KML. Therefore as long as GeoServer is configured to publish a dataset, publishing it as KML is achieved automatically at no additional cost. This provides the ability to simply point Google Earth at GeoServer and watch as data is streamed in and rendered onto the Earth. There are a number of advantages to serving KML with GeoServer. Filtering of data based on the area being viewed in Google Earth is done on the server side where any indexes on the native format can be utilized. This is important in order to achieve acceptable performance. Also of note is GeoServer's ability to dynamically detect when a user is attempting to view too much data. This can happen quite easily as soon as the user switches to a global zoom. In these cases where Google Earth must process large amounts of data, performance degrades drastically. If the transfer is taking place over an internet connection it can be simply unusable. However in cases such as these GeoSever will automatically switch to serving KML as a prerendered image. The result of which is that Google Earth does not have to process mass amounts of data. As soon as the user zooms back into a location in which an acceptable amount of data can be processed GeoServer will switch back to serving KML normally. KML provides a variety of styling options which control how it is rendered by Google Earth. Colors, line widths, and labels are a few of the many. GeoServer supports full styling of KML by leveraging existing support for the OGC Styled Layer Descriptor (SLD) specification. SLD is a standard which describes how to style layers published by a WMS. When GeoServer is configured to serve a WMS layer a SLD is specified which controls how the layer is styled. SLD is a complete and comprehensive specification which supports many different styling, filtering, and scale dependent rendering options. When producing KML GeoServer reuses the rules specified in an SLD to create the equivalent KML styles. The end result is that KML rendered in Google Earth looks the same as a normal map looks rendered by a GeoServer WMS. This is a quite significant feature. Creating a map is easy. Creating a map which looks good is harder. Creating a map which looks good and different scales is much harder. People invest a lot of time into determining how a map should be styled and which styling options make a map look the most aesthetically pleasing. Having to do this work twice is unacceptable. There are many other features of GeoServer support for KML. The 'Super Overlay' feature is used to create 'region-based' KML which in conjunction with a tile cache can lead to efficient tile based rendering of raster data in Google Earth. Another interesting feature is the ability to control KML output by utilizing the GeoServer template engine. By creating a simple template it is possible to create KML place marks and labels which are customized to a particular dataset. The GeoWiki. One of the technologies of the web that has become extremely popular over the last few years is the wiki. A wiki provides an easy way to create and edit data directly on a web page. This in turns provides an effective way for people to collaboratively author content online. This can ultimately lead to the formation of a community around the content. The most notable wiki based community is Wikipedia. The fact that in this very article the author has used Wikidedia as a cited reference is a testament to how well received and successful the idea has been. As the geoweb is the addition of geospatial to the web, the 'geowiki' is the addition of geospatial to the wiki. A geowiki is a tool which allows users to easily create and edit geospatial information directly on a map in a web page. Chris Holmes, one of the initial developers of GeoServer, coined the term 'cvs for the geospatial web' when describing his vision of the future for the project. In his blog he writes:

One way Ive been articulating where were going with GeoServer - cvs for the geospatial web. We give you a central location where you can do insert, update and delete on your data. There are a number of concepts that are fundamental to any wiki system. Not only must a wiki provide the ability to edit data, it must track and maintain a history of those edits. An important feature of a wiki is to provide a log of what content has changed. Furthermore, it is insufficient to show that simply there have been changes. It is necessary for a log to concisely indicate the exact content that has changed. To determine the differences between two states of the content. In a wiki environment this is known as a 'diff'. Another of the principal operations of a wiki or any authoring tool is the ability to undo changes. Allowing a user to revert content back to a state before a particular change was made. This is known as a rollback. In an environment in which content is edited in place online it is often the case that two users are editing the same content at the same time. For this reason it necessary for the wiki system to provide some sort of conflict resolution process. In many systems this amounts to a 'locking' mechanism in which content is locked while a user is editing. When this occurs other users are unable to change content. These fundamental operations can be lumped into the single concept known as 'versioning'. Much of the development on the GeoServer project over the last year has been dedicated to supplementing WFS support with the notion of these versioning constructs. The product of which has been the creation of an experimental extension to the WFS specification Versioning WFS (WFS-V). The WFS-V specification is a clean extension to WFS proper which adds support for versioning operations. Conclusion Technologies and innovations revolving around the emerging geoweb make the world of geospatial an exciting place. But it is important not to lose sight of what is important. No matter how good technology gets there is no substitute for good data. It is high quality data that makes high quality maps, not the tools. It is for this reason that SDI initiatives are of crucial importance to creating a true web of geospatial information. While often the two communities have separate goals and agendas, tools like GeoServer can help us to bridge the gap. References Holmes, C., 2007, Collaborative Mapping Redux

http://cholmes.wordpress.com/2007/06/25/collaborative-mapping-redux/
Ramsey, P., 2006, Why SDI's Fail

http://geotips.blogspot.com/2006/09/why-sdis-fail.html
Wikipedia, 2007, Geoweb

http://en.wikipedia.org/wiki/Geoweb
Copyright Notice As a condition for inclusion in the GSDI 10 Conference Proceedings, this work is licensed under the Creative Commons Attribution 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/us/. Any use of the work in contradiction of the Creative Commons License requires express permission by the authors of the article.