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

We were supposed to have two normal and one developer edition but it wasn’t very clear which one was which so we picked one and carried it to our office. This turned out to quite tricky, this thing is heavy and doesn’t have any clear handles. In the end we carried it by holding the projection-surface …

Once setup we had to fiddle a bit to get the powercable connected and find the proper (two) powerswitches. Once it booted it prompted us an EULA we had to accept. However the Surface is designed to be a standalone machine completely controlled by touch but before the touch was working we had to accept the EULA, which was only accessible by touch … hm

You need to accept to start touch, and you need touch to accept

So we had to plug in a mouse, but apparently we hadn’t chosen the developer edition since no usb ports where visible. The manual explained that we need to open up the side of the table to access the ports. After two screws and a bit of force we managed to open up the side and it gave us full access to all normal PC ports.

The surface insides

It asked us to create an admin account and once it was setup it gave us the choice to login as that admin or as TableUser, since we had no clue what the password for TableUser was, we logged in as admin.  After a bit we were shown a fresh Vista desktop with a few shortcuts. The most obvious for us was the calibration tool. We calibrated our table and started a touch application. It failed to run complaining that the filtergraph was not found at the location specified. We neither had knew what a filtergraph was, nor what the location specified was.  This got us stuck for quite a while, the manuals didn’t help and the online site with information was only accessible by invitation and due to some miscommunication(?) we were not (yet) invited.

Digging into things like registries, hidden folders and binary blobs we finally discovered that there are two versions of the calibration tool. One which does a background-light calibration and one which does a per camera calibration. We had run both, but we failed to notice that the latter had to run 5 times (5 cameras in the surface). Once we had done so the different surface programs ran without errors and without effect.

Pretty annoyed we banged our fist on the table and that seemed to have effect. It turned out that putting a lot of force on the table gave results, indicating a calibration issue. Having no idea how to finetune the calibration we started to experiment with different ways of touching. The current consensus is that it is designed for ubergeeks who never see the sun and are pure white; touching the Surface with a finger doesn’t give a result, wrapping the finger in white tissue suddenly does …

The 'attract' application

Hopefully we will figure out soon how to tweak the calibration and otherwise we need to buy a set of white surgical gloves to hand out to users