WMS / WFS server: am I crazy to write my own?

I’m kind of “do it yourself”, but I want to make sure that I’m not going to do this, trying to bite off more than I can chew.

I am writing a browser-based display application that should be able to run standalone (without an Internet connection) on the end-user machine. That is, the application is some kind of server, which in many cases will be installed on the destination machine, and the browser will point to some URL of the local host in order to access it.

I will use MapLayers on the client side, and on the server side there will be a bunch of user-specific logic specific to the application, such as handling click events on the map in specific user ways, creating various user objects on the map at certain times, etc.

For the "business logic" of the server part, I am happy with paste / webob with python. This is a simple infrastructure that allows me to easily introduce all this user logic.

I thought that the client will communicate with two servers: the paste / webob business logic server and the server for servicing WMS and WFS card elements. So I looked at MapServer and GeoServer to process parts of the map and ... I'm not happy.

I am not happy because I do not want to install and worry about the "beast" on client machines. For MapServer, I really don't want to install a full-blown web server like Apache, and have to deal with CGI, PHP, and MapScript. For GeoServer, there is a (potentially) installation of Java and handling the various complexities of setting up and administering GeoServer.

Part of this is simply the learning curve problem. If I can avoid this, I'm not particularly interested in learning the intricacies of MapServer or GeoServer. I installed GeoServer, pointed out some of my data and was able to use the MapLayers preview built into the good GeoServer web addon to view my data. But when I tried to use the data to actually use my own MapLayers webpage specified in GeoServer, I broke GeoServer. The fact that I could crash the server by simply sending some supposedly malformed requests from the client was completely unexpected for me. And I could look into the GeoServer logs to try and figure out what I did wrong, but ... I really don't want to spend a lot of time on this.

So, I am considering introducing parts of the WMS and WFS interface, simply using the existing paste / webob server. In fact, it may be that I only need WMS, since I can process vector objects through a simple user protocol that I do to transfer data to the client, which can then create and manipulate objects directly using OpenLayers.

I looked at the specifications and message examples for WMS (and a bit less in WFS). It seems not so difficult to simply implement this protocol, especially because in this case I have full control over the client - I do not like that I can work as a shared WMS server or WFS server; I just have to make my own OpenLayers client happy.

Two main features that I need for a WMS server:

  • To provide tiles from the store of pre-processed tiles that I created ahead of time (I will close the tiles using the data of OpenStreetMap and mapnik as a delay mechanism, and I will store and access them using the usual Google Maps style naming scheme, which expects OpenLayers)

  • You have the opportunity to modify the versions of these fragments on the server, where certain data is stored locally on top of the tiles. For example, I can have, say, 10,000 points on one layer and 10,000 polygons on another level, and when the user activates these layers, I will serve the same basic tiles, but while I serve these fragments, I will make these additional functions on top of them, and I’m probably implementing a simple caching scheme to keep these surface snippets for some time.

So my question is: although I know that there are existing tools that do these things (MapServer, GeoServer, TileCache and others), I really feel that this works less for me just to answer some simple WMS messages, and do it for additional redrawing on their tiles in python, making sure that everything is designed correctly, etc. I do not need to attract attractive wide streets or anything else for these overlays, just simple lines, badges and possibly shortcuts. It is really cool and simple to have only a python solution.

I believe that if I ever need to expand support for the WMS / WFS protocol or do a more complex overload, I can just insert MapServer / GeoServer at this time.

Are there pitfalls here, I am not considering?

+6
paste geoserver mapserver wms webob
source share
3 answers

Mapserver is very easy to configure and learn. Implementing any kind of rendering will require much more effort, and you are likely to find many unexpected traps.

mapserver cgi should be enough for your needs. If you need a very specific setup, then a map file can be useful.

I think it would be interesting if you could create a clean JavaScript application and save yourself from installing a web server (and map server). If you just need to view the mosaic from the tile, perhaps you can only do this with JavaScript (generate an html table with a cell for each tile). You can visualize points or polygons using JavaScript, using the canvas, and perform basic coordinate transformations to translate geographic points into pixels. I think Openlayers has this functionality.

EDIT: I just checked and Openlayers you can view local fragments and you can display kml and some other data. So, I think you should try Openlayers.

+1
source share

No need to have wms / wfs. You need a tile implementation. Basically, you should have some kind of central service or desktop service that generates tiles. After creating these fragments, you can simply convert them to your "no-real-webserver-architecture" file system. You can create a directory structure that matches /{xasket/{y}/{z►.png and call it from javascript.

An example of how openstreetmap can be found here: http://wiki.openstreetmap.org/wiki/OpenLayers_Simple_Example

+1
source share

You may like featureerver: http://featureserver.org/ . It has its own WFS. I am using it right now.

0
source share

All Articles