At least that is the theory Martijn tries to work with.

The age in days for OpenStreetMap nodes

You can see a clear pattern emerging here, apparently there are areas which get mapped in a short period of time and never touched again. The white squares just didn’t have any nodes in it, so they contain no data.

The version of OSM nodes

It is more difficult to see patterns here. Whereas with age in days the number gives you an instant grasp of the meaning, the version number is less obvious. We probably need to do a statistical analysis of version numbers in OSM. This way we can attach some (relative) meaning to the average version number.

The red circle is the final location of the node and the path is the order of changes. You can see that the first changes were much more rough than the last ones.

I also did the same for an entire way, where the way itself is shown in blue and the versions of the nodes are shown next to the nodes.

The trouble is that it is currently quite difficult to get the full (spatial) history of an area in OpenStreetMap. Once we find a way to do so I hope to generate more and play a bit with different visualization styles and methods.

To visualize these tracks I used Processing, ‘an open source programming language and environment for people who want to program images, animation, and interactions.’  There are lots of plugins to read different data formats, an interesting one for this project is the gpx library. The plan was to render the tracks of each person in a different color, tracks which happened at the same time should be drawn at the same time. This way you can see which people are at the same time at the same location. Each track would fade out in time, leaving a thin line for past tracks.

To do this on a track-basis however turned out to be quite difficult for my limited knowledge of Processing and the time I had available. So instead of using the gpx module I created a flat table with all locations sorted by time. Each row of the table contains lon,lat,color-id,time. The program iterates through all 42000+ rows and draws the locations as a dot. The size of the dot depends on how ‘old’ the point is. The last 200 points are drawn with a diminishing size, creating the worm-like effect in the animation. Note that it doesn’t take into account the actual time between points, just if it is next in line.

A few tweaks were added: Holland in unprojected lat-lon looks odd to dutch people, so I implemented a simple projection library to reproject the points to a semi-RD (dutch projection). Also I wanted to dynamically zoom to the action (not everything was happening in Amsterdam). I did this by calculating the minimum and maximum X and Y for the last 200 points. I wanted the location of our office building to be in view all the time, to provide a point of reference.

The source code can be found here if you are really interested. There are three files: Table.pde as written by Ben Fry for his book Visualizing Data, Soprojection.pde, written by Steven Fruijtier at my request and Drawing.pde is hacked together by me. This is a very crude and brute-force approach to render a series of tracks, so please use it with care. Since it needs to recalculate each point for each frame it tends to become slower as it advances through the table.

Click here to view the embedded video.

We’re involved in both ESDIN and EGN and we decided to use the latter as a trial for the first. Together with our partners we’ve setup a series of servers to fulfill the needs of the projects. The main standard used is the latest WFS and GML versions, which have the annoying disadvantage that there are few clients available.

To be able to show nicely (as in not an XML file) that everything worked I was asked to build a webclient which would show a map and the data from the EGN service for that area. I figured that this was once again a good reason to look into the latest developments for OpenLayers. I quickly discovered that the released version (2.7) doesn’t support WFS 1.1.0 so I asked on the mailinglist if people already tried to implement it (and if not, pointers how to do so). Luckily people already did the work and created various patches for the support. (thanks tschaub, bartvde and others)

The most important patch is the one which implements protocols for WFS: ticket 1648 and its wfs.patch The main disadvantage of this patch was in my case that it tried to minimise the number of requests to the WFS server (which in general is a good thing). It requests all the features which are within twice the size of the viewport and it doesn’t request new features when you zoom in. However our server is limited to 10 features per request this results in very interesting behavior. For a starter all the 10 feature could be outside your viewport and also very funny is that shown feature might dissappear when you move the page too much (it requests new features in that case and the first 10 might be outside the viewport). A second patch, on ticket 1830, provided a more aggressive feature update: each zoom action triggers a new request and I set the request-boundingbox-ratio to 1, meaning only those feature within the viewport are requested. This means that every action triggers a new request, which is heavy on the server.

However this is just a reference implementation and hopefully for actual implementations they remove the 10 feature limit. For those interested the reference implementation can be found at http://research.geodan.nl/egn

Unfortunately today was slightly less successful, apparently quite some presenters couldn’t make it after all and three of the talks I was looking forward to weren’t there. SO hopefully the BOF on openlayers and extjs will be better. Interesting projects to look into at home so far are: QGIS-mapserver and Mapfaces.

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_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.

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!

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.

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