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.

BruTile @ the Surface

Once we got the basics running I tried to edit the XAML to make it look better. This turned out to be harder than expected. The surface has once again its own default designs, which in my opinion are worse than the WPF standard designs. The default look is grey and square. So I wanted to change it to something more akin to our other touchtable applications: white and round. However Paul used a ScatterView component to display the layerlist and the geodan logo. He had read that one can just drop components in a ScatterView, without the need to embed them in ScatterViewItems. This is true, but it is a nightmare for the (non-initiated) designer. What happens is that the grey-square design of the ScatterViewItem is drawn beneath any layout you come up with for your own item. This is a very puzzling behaviour, although not entirely unexpected once you know that the ScatterViewItem exists.

Once I solved this issue I could seriously try to change the layout of the ScatterViewItems. Here however real glitches appeared. We use rounded borders and dropshadows for our items. As you can see below there are (at least) two issues:

Rounded border on the Surface don't work

The dark rectangle in the top of the image is actually a shadow of  a ScatterViewItem which for some reason doesn’t start below it. However this makes it easy to see the first glitch in the rendering. As you can see there is a thin dark line near the edge, which makes a weird square corner at the corner. This shouldn’t be there and when you resize the ScatterViewItem down, the shadow becomes darker (as it should have been in the first place) and the line is not visible anymore. If you don’t use rounded corners on the shadow the line is still there, but harder to notice because it is exactly following the edge of the shadow.

The second annoying glitch I’ve found is the gap between the border and the content. If we zoom in a bit on the layercontrol you can see there is a pixel space between the border and the content:

A gap between border and content

So far I haven’t been able to eliminate the pixel wide gap. It doesn’t look bad in our application right now, but in general it is bad that there is such an uncontrollable gap. So I have the feeling that the Surface people are not a big fan of borders in general and rounded border specifically.

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 spend quite some time calibrating, recalibrating and reading documentation from the invite only Microsoft site without any effect. In the end Vista asked us to install an update and to reboot the Surface. When it was rebooted we ran the ‘Surface Shell’ application from the Desktop and suddenly it worked!!

The Surface, or at least our version, comes with a set of code examples. We tried several to see how well it works and found out that especially the Grand Piano demo is a crowd drawer (mainly due to the sound probably). The Piano is a limited set of piano keys in perspective view. ‘Pressing’ a key results in a tone, just like a real piano

Playing piano on a Surface

The sensitivity of the Surface is well balanced. The Surface doesn’t notice fingers which are hovering just above the surface and you don’t need to apply any pressure to get noticed once you touch it. We’ve built our own table using a similar FTIR technique and we had quite some problems getting that balance right. Also the Surface is using 5 camera’s where we used just one as such it’s resolution is better as well.

It has additional logic in the interpretation of the camera feeds. It has three different types of touches it can recognize: finger, blob and tag. From each type it gives a location, an orientation, an id and in case of the tags a value.

Surface information of a finger

The difference between a blob and a finger is the size and shape of the touch, for instance a small square object is seen as a blob and a larger oval object is seen as a finger. Furthermore the earlier white-only bias of the Surface we experienced is now changed to a no-black bias. This gives some interesting results; a black/orange marker on the surface is recognized as a single finger at the tip of the marker;

Fingers come in strange shapes

The Surface feels pretty responsive, but using the Data Visualizer you notice that the position of the touch as interpreted by the Surface lags behind the actual touch. In the demos it is not noticeable but we found a similar lag very annoying on the DiamondTouch. On that table we managed to get rid of the lag and hopefully we can do the same here.

There is the famous demo of the telephone on the Surface, where it gets recognised and you can drag and drop data. We tried it and noticed that it doesn’t like android phones; it just doesn’t see the phone. An (ancient) windows mobile phone however does get recognised for what it is: a blob;

Android on the Surface

Obviously the Surface doesn’t automagically recognize phones or any other object. The table comes with a set of fiducials which you can stick on objects. These fiducials get recognised as tags with a value and using that value you can do fun stuff in your software.

Update

I discovered that while it doesn’t respond to hovering fingers, it does notice hovering areas the size of a hand. Which is slightly annoying since in normal use you easily have your hand hovering just above the surface while one or more fingers touch it. It might be possible to filter this unwanted behavior in real applications, because the hand shows up as a blob instead of a finger.

The movie, voiced over by Geodans own Barry White

So we came up with a Wii-mote based game which is both simple and fun, at least we hope. You are presented with four maps in sequence. Each map has various cables and tubes hidden under streets and parks. You point the Wii-mote at the screen and a ’searchlight’ appears which allows you to look underground. Somewhere on the map there is a breach which you have to fix. Once you find the breach, you need to dig a hole using your Wii-mote. Once you have created a deep enough hole you need to fix it. This is done by hammering the broken tube until it is fixed, again with the Wii-mote. The time it took to find and fix all 4 breaches is your score.

We use an opensource library which allows to connect the Wii-mote to XNA and build the game with XNA. My task was obviously to help to design the game and do the in-game graphics. Since we only had a week time we opted for a simple style. To create the four background maps I selected four towns on a map and traced them in Inkscape to get a simplified and colorful version. Next I draw a few cables (yellow) and tubes (blue). Finally I selected 20 points where a breach could occur.

Animation showing the original map and the final map

To dig and to fix the player has to make either a dig or a hammer motion with the Wii-mote. We use the accelerometer to determine if the player is digging/hammering hard enough. He has to do it 4 times and the progress is shown as a simple animation:

Fixing animation

I hope to have a movie of people playing the game soon.

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.