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.
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
VE’s quadkey tiles and tilecache
Since my company acquired a real life Virtual Earth server; a hefty beast with a few TBs of data for just .nl, I decided to dive into VE. The people from Microsoft produced some excellent documents explaining how the tilescheme of VE works.
The original idea was that we could insert our own data into the server, but that seems to be difficult. So I decided to see if TileCache could do the honors. We already deploy TC in various projects and the nice bit is that the generated cache can be used outside VE, for instance with OL and/or google maps.
Of course it is possible to use OpenLayers to add your own data on top of VE, but OL doesn’t support the 3D view and AFAIK neither does it do birdseye. To show your own data in VE you need to serve the tiles using a quadkey construction. The logic of a quad key is very easy: At the lowest zoomlevel divide the world in 4 parts: 0, 1, 2, 3 (left top, right top, left bottom, right bottom) so a tile called 0.png would be in the left top at zoomlevel 0. In the next zoomlevel divide the four tiles in four parts again. And so on and so on. Stealing from msdn site:
So it is immediately clear that file 12020.jpg is at zoomlevel 5 and somewhere at the north-eastern hemisphere, actually it’s in .nl. Tilecache however works with x,y,z so you need to recalculate the quadkeys to/from xyz system. Taking into account that VE (0,0) is top left whereas TC uses bottom left for (0,0).
Tilecache has three components: client (which retrieves the data), service (which serves the tiles) and cache (which stores the tiles). I first wrote a cache which stored all tiles in a flat quad-file structure. This way you could put the entire cache online and VE could automatically place the tiles at the correct place. However as long as the cache is not complete and put online the data is not accessible by VE. Also all TC’s cachemanagement features are gone as well. So I decided to write a VETMS service instead, which takes quadkeys and turns them into any of the supported backends, be it WMS, Mapnik or whatever. This way it is easy to put your WMS data in VE. This code has been sent as a patch to the TC list so hopefully in the next TC release you can serve quadkey-tiles as well.
Whilst I was at it, I wrote the last bit: a VE-client which retrieves the tiles from a VE server and serves them as TMS, WMS-C or any other of the supported services. However since this is legally not allowed I’ve chosen to not release the code.