Is it better to burn out, or to fade away?
Last week we, the Mapbuilder PSC, have decided to gracefully terminate Mapbuilder. We found that other webmapping projects (notably OpenLayers) had passed us in userbase, developbase and finally also in features. We decided that the answer of the ageold question is to burn out. We’ve sent out an announcement that we have reached the end of life of Mapbuilder. It is a sad day…
Dark skies are looming over me
But in general I think this is a good thing and OpenLayers will grow even faster, it is a great package after all.
Tilecache seeding for .nl in 900913
For the new EduGIS webmapping client we are using mapbuilder 1.5, openlayers 2.6 and TileCache 2.0.1. We have around 30 layers containing data for the Netherlands. To seed the tilecache for these layers takes quite some time, especially if you do not give the proper bounding box.
Tilecache_seed.py, the simple seeding client that comes with TileCache, takes the following parameters:
tilecache_seed.py <url> <layer> [<zoom start> <zoom stop> [<bbox>]]
The url parameter apparently doesn’t matter, it just uses local python. The layer is the layer you want to seed. Optionally you can limit the number of zoomlevels which you want to tile and the bbox of the area to be tiled. If you leave these out it will default to the entire world and all zoomlevels.
For .nl in google-projection I’ve used these parameters:
python.exe tilecache_seed.py "http://url.to.tilecache/TileCache.py?" layer 1 18 "350988,6571138,827965,7133714"
This will generate 2870400 tiles on zoomlevel 18 and it takes some time (think days). It is probably more useful to seed until level 17 or maybe even 16 and tile everything else on the fly.
OSGeo conference in .nl
Yesterday was the dutch (mini) conference on open source geospatial software, organized by osgeo.nl. I was too late to join the technical workshops, but the talks turned out to be fun as well. The different talks mainly showed of projects which somehow worked with open source. The most interesting talk for me was probably the one by Dirk Frigne of DFC. He showed of Majas, a new application they have been developing for the past two years. Majas is a browser based vector editor (amongst others) which supports snapping etc. They started developing it before OpenLayers existed and are now considering to write OpenLayers into Majas as their map renderer.
Apart from having good vector editing capabilities it has a nice architecture which resembles Mapbuilders MVC. From what I’ve seen it has the potential to become a widget framework around OpenLayers, what Mapbuilder tried to become and mapfish is currently trying. In Capetown they will talk further on integrating with OpenLayers, so to be continued.
There was an interesting discussion on what it meant to ‘do’ open source. Just using it was found to be not enough, you need to contribute your code and preferably also make the source code of your project available. The discussion went on for a while on whether or not we needed more legislation to force open source into the public sector. (Bad idea IMHO) At the end there was a smart remark on the sorry state of OSS, we are needing/using legislation to get people to use open source software. The guy stated that we needed to work on our marketing, so people want to use it, I totally agree on that!
OSGeo got into GSoC ’08
I just received an email from Google inviting me to take part in The Google Summer of Code(tm) 2008:
Earlier this year the Mapbuilder community came up with some GSoC ideas and by kind permission of the Openlayer community did a joined ideas list with OL. I volunteered to Mentor a few of those. The Openlayers/Mapbuilder/Mapfish ideas list is part of the umbrella entry of OSGeo.
This message means that we made it to the GSoC, apparently over 500 organisations/projects applied and only 175 made it. I’m happy we are one of those and I hope we get some enthusiast students who will extend OL/MB/MF in ways beyond our dreams, or at least more or less as the ideas describe.
Venus on windows
For Planet Essener I needed planet-software. Venus seemed to be easy to setup so I downloaded it. Somehow firefox produced a 0 byte zip file and also the tgz contained a 0 byte file inside. Wget-to-the-rescue solved it however.
Venus is written in Python and for windows you need to install the python-windows extensions. There is a very useful test script included in the Venus release that will tell you what you need to get extra filters and theme-engines running. This produced a series of errors and the more software I installed for the extensions the more errors occurred.
They looked like this:
======================================================================
ERROR: test_apply_filter (tests.test_apply.ApplyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Documents and
Settings\steveno\workspace\venus\tests\test_apply.py",
line 100, in test_apply_filter
splice.apply(self.feeddata)
File "C:\Documents and
Settings\steveno\workspace\venus\planet\splice.py", lin
e 122, in apply
output = open(output_file).read()
TypeError: coercing to Unicode: need string or buffer, NoneType found
They all had a reference to a file in them. Since I had installed it in My Documents I figured that there was a problem with spaces in the path. (I realized this only after I sent a mail to the list). Installing it in c:\venus solved it. Later I got this mail from James Holderness who gave me a solution for the spaces:
I’ve had Venus running on Windows in a path with spaces. What I did was use
the 8.3 compatibility filenames everywhere in config.ini. For example, if
you need to refer to a path at \program files\venus you’d use path
/progra~1/venus. Also before running planet.py, I’d do “cd \progra~1\venus”
which ensured that my current directory was also space free. I think that
was all there was to it.
Once it is installed it is very easy to configure. I even managed to create a tag-filter so we can filter out personal posts from the various blogs 
Using TileCache to connect VirtualEarth and ArcIMS
For the upcoming EagleOne disaster exercise we want to overlay WMS layers on top of Virtual Earth. Already we know how to overlay WMS images on top of VE using TileCache. However this approach uses the 900913 projection. Sometimes you have a WMS server which does not support 900913 and you’re not able to change that.
So here enters the cascading mapserver: UMN Mapserver, and possibly others as well, can function as a cascading mapserver. This means that it acts both as a WMS server, to you, and a WMS client, to another WMS server. This way you can use it to reproject images.
By using both TileCache’s new VMTMS service to serve QuadKey-Tiles and UMN Mapserver reprojecting cascading capabilities I was able to access an ArcIMS server which served epsg:28992 WMS through a WMSconnector and show this data tiled and cached in Virtual Earth. I drew a schema of this:
As you can see two open source components are used to connect two incompatible closed source components; it’s the duct tape of the GIS world
TileCache on 64bit windows
At work we have a nice new server, which contains a smaller version of Microsoft’s Virtual Earth platform. This machine is still a hefty beast: dual quadcore with 16GB memory and about 8TB of harddisc space. Since there’s still a few TB free we decided that it would be a nice machine to serve up VE-compatible tiles using TileCache, hence my work on VE compatible TileCache classes.
This proved to be much harder then I expected. The problem is that it runs Windows Server 2003 x64, a 64bit OS. Obviously since it is a MS product it already has IIS installed and TileCache doesn’t perform well on IIS. (A side note, I just found this article by Vish and it seems that it might perform after all). So I decided to install Apache alongside it and the necessary Python and mod_python as well. Being a 64bit OS I wanted to install 64bit software.
Apache isn’t available as 64bit binary, neither is mod_python. Only python had a 64bit binary for download. So I installed apache 2.2, python 2.5 (64bit) and checked if they both worked and they did. Mod_python proved to be more difficult so I googled for 64bit mod_python and discovered this article which explained how to compile a 64bit python. There were some problems with it not finding python.exe and some DLLs but that could be solved by adding c:\pyton25 to the PATH environment variable and putting the DLLs in the same directory.
So now I had a 32bit Apache 2.2 (working) a 64bit Python (working) and a 64bit mod_python ready to work. However when I configured Apache to use mod_python it failed with a weird error that %1 was not a valid application. Some more googling revealed that python on a 64bit windows does weird things, or 64bit windows does weird things with python 
Since 32bit Apache already worked I decided to go for 32bit Python as well which together with 32bit mod_python works flawlessly. So if you want to run TileCache on 64Bit windows: just go for the 32bit versions of the software and hope you’re not stuck with an Itanium.
‘Proof’ of TileCache running on 64bit Windows, the 6.82GB RAM usage is baffling since the machine isn’t doing anything