2

March 18

Geoserver – a migration story!! – Part 3 – and so the Geoserverization begins…

Posted by Ajay

Ok, so we spent the last two posts talking about  geoserver, why we chose it, and some general information about geoserver and it’s architecture. Now let me talk about the geoserverizing of our mapping service.

Mapping our way, in the old times …

I very fondly think back to the old days when we (as in my software development team) used to have our GIS functionality all packed up into a tightly coupled application. We initially began to develop our own WMS/WFS rendering server; since geoserver had not seemed a colorful alternative when my project came into existence oh a couple of years ago (it’s never polite to ask a project his or her age). Our project is a struts based application. So the model view controller that included the rendering code did provide us with some semblance of loose coupling. Here is a look at our application as it was

We use a Mapbuilder based client for our GIS mapping component. Our application handled a lot of the image rendering using geotools. We did all our rendering from using geotiff readers and writers to simple polygon rendering right in our handlers. The handlers would communicate with our layer classes which would use hibernate / plain SQL to talk to the database. It definitely looks modularized doesn’t it? But imagine what happens if you decide to add, a jar of actions doing all other things like managing accounts, managing logs and status boards, and even displaying beautiful charts of our data, none of which is even closely related to our GIS functionality. Imagine the confusion that could happen when the whole world is transitioning towards a service oriented infrastructures. This is exactly what happened.

A New revelation …

We were all fine and happy until one day we realized that our GIS mapping tool could be a potential source of money a.k.a marketable value. That is when we had a rethink about our mapping component and decided to move it out of its monolithic cage. We decided to set our GIS component free.

We had been following the happenings of the geoserver world quite closely for some time and decided it was an appropriate time to try to make the switch to geoserver. Now the only issue was the migration of all our layer and rendering functionality. This task was not really that easy for the following reasons and of course many more too.

  • Incompatibility of our jar files
  • All our styles were being rendered from the database
  • The sheer number of layers we had to transfer to geoserver, somewhere in the range of 200 layers.
  • We had some custom layers that could not fit in the geoserver framework
  • Pain of having to recreate our base maps as image pyramids.
  • Naming conventions used in geoserver.

The Geoserverization has begun…

But in spite of this we managed to go all the way and get geoserver up and running. The diagram below depicts how much more service oriented our application has become,  for our mapping functionality.

We now have a clear separation of code between our application and our geographic aspects. We were able to provide our users with a service oriented way to access our GIS mapping data, providing client independence and data independence.

The solution to our problems??

So how many of the problems we talked about before were really solved?

  • We definitely had huge problems with jar files especially since we were using older 2.4 geotools library. So we had no choice but to transitioning our application to geotools 2.5. Geotools 2.5 has added new way to do things many things as compared to 2.4. But we were able to get by this issue and were successful in doing the transitioning.
  • In order to accommodate the styles coming from the database, we used a feature of Mapbuilder that allows StyleList to be passed through the context document. This works very effectively for us.
  • The job of transferring the layers along with their configuration was made really easy by the fact that geoserver uses HTTP as the protocol, providing us with GET requests that were tapped using a very helpful tool called LiveHTTPHeader. We captured the requests being sent and created an ingenious tool that would read the layer list from the database and then send a complete series of GET requests to geoserver for each layer, with each request executing one particular task of the geoserver feature creation work flow. Now with the introduction of REST interface in Geoserver 1.7.3 we feel that we can migrate our tool to using REST to populate geoserver, which would make things much more efficient and simpler.
  • Lots of our custom layers are unfortunately still hooked into our main application, so we have been forced to use two server hitting URLs, one for all our generic layers and one for our custom layers. Although I feel that the plug-in mechanism in geoserver could prove to be a potential solution to this problem.
  • The basemaps were a pain to convert into image pyramids, but we did it and it works beautifully. Someone really clever once said, “No pain no gain”.
  • We have now also shifted to follow the naming convention as in geoserver, with the “namespace” prefix.

Suffice to say our migration has been largely successful, though some aspects of our application like the custom layers do need some thinking to completely separate it from our application, but we are on the road to make our mapping component a full feature web service, courtesy of geoserver.

In future editions of this series I will talk about the geoserver plugin mechanism and possibly WFS-T functionality that geoserver provides. In addition I might also talk about the new REST interface that geoserver 1.7.3 has introduced.

Until then, as my people say, alvida (goodbye)

Tags: , , ,

 
2

March 12

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

Posted by Ajay

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

Tags: ,

Copyright © 2010 “An Image of My Life” blog series All rights reserved. Theme by Laptop Geek.

Total hits: 38482