Geoserver - a migration story!! – Part 2 - Talking the architecture

The History behind it

Let me first tell you a story. In a place far far away, couple of million minutes ago, in the year AD 2001, a great entity , well a startup agency actually, called TOPP was looking into designing tools to make democracy and government more transparent, and with a flash came … .Geo server.

Allright enough of all that dramatization, in short the people from TOPP envisioned a geospatial web which led to Geoserver. Geoserver is based on the geotools project. In addition geoserver has a interconnected relationship with OGC, the Open Geospatial Consortium, Refractions Research – creators of PostGIS, OpenLayers and even Google.

Geoserver forms the beginning of the standardization in the GIS arena. It follows the WMS, WFS and WCS specifications to the letter, and forms the platform to develop GIS applications based on these specifications.

It’s design

At a high level view Geoserver essentially consists of many different modules that are actively interacting with each other. All these modules are connected using Spring IOC so that at runtime a module can make use of services provided by other classes.

Geoserver reads data in a wide variety of formats from PostGIS, OracleSpatial, ArcSDE to shapefiles and geotiff. It can also produce KML, GML, Shapefiles, GeoRSS, GeoJSOn and multitudes of other formats.

Geoserver essentially consists of two aspects – the configuration and data store aspect, and the rendering aspect. All configurations in geoserver are done through the admin interfaces and XML configuration files.

• The service.xml defines all service level configuration options. It defines parameters for WFS, WMS and ECS services.
• The catalog.xml on the other hand defines datasources, styles and namespaces. In addition geoserver introduces coverages and featureTypes that provide metadata information about raster layers and vector layers respectively.

Geoserver configurations consists of many different namespaces, to which featuretypes, datastores and styles can be associated. Namespace provides a way to logically group all the data in geoserver. Now digging deeper, we see FeatureTypes.

FeatureType represents each individual layer or feature that needs to be shown on the map. Another entity at the same level of a FeatureType is a Coverage. Coverage is usually created for raster layers and FeatureTypes represent vector layers. All FeatureTypes have a source of data called a DataStore.

DataStore is essentially a source of data for rendering of features. Geoserver supports many different data stores including Web Feature Server, Property files, Shapefiles and database based datasptres. CoverageStore is another entity at the same level as a DataStore but includes raster based data formats like ArcGrid, geotiffs, image mosaics, etc.

Every feature will have certain styles for rendering on the map. All styles for layers are configured using the Style entity. Styles are represented using SLD or Style Layered Descriptor files.

The rendering component follows the WMS, WFS and WCS specification and are uses geotools as the rendering API.

This concludes a very general architectural over view of geoserver. In future posts I will talk about other aspects of geoserver, the OGC specifications and some of the problems encountered on this grand geoserver experiment.

References

• http://geoserver.org/display/GEOSDOC/1+GeoServer+Architecture
• http://www.resc.rdg.ac.uk/twiki/bin/view/Resc/GeoServer

Tags: geoserver, gis