March 18
Geoserver – a migration story!! – Part 3 – and so the Geoserverization begins…
Posted by AjayOk, 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)
