Click here to view the embedded video.

However modern browsers have the <canvas> element. This element allows for the manipulation of single pixels within this element. So I figured if I could encode the building-dates in a PNG and use canvas to display only those pixels which represent a building older than the given date it should be possible to time-slide through the buildings. Fortunately the fancy new mapping library Leaflet.js has a canvas tile layer build in. The BAG data is already available through EduGIS, so I only needed it to encode the data differently in the PNGs.

The encoding is very simple: per pixel there are 4 values available: red, green, blue and alpha. Since I only needed to encode 200-odd values I used just the red value. The years before 1850 are encoded as groups, since the data is so sparse, after 1850 each year is individually encoded. This means that from 1850 onwards the red value increases with 1. The client retrieves the encoded PNGs as normal tiles and look like this:

The image appears grey because I kept the green and blue values of the PNG the same as the red. This image is loaded into canvas and the imageData is retrieved using ctx.getImageData(0, 0, 256, 256) and stored as a jQuery data object on the canvas. This is important, since for visual effect we will manipulate the imageData on the canvas and we want to keep track of the original values. Once the imageData is attached to the canvas the colors are being calculated. It will take the original values, compares them to the current year and will decide whether or not to show the pixel and in which color.

Since only the grey tile is needed, the actual sliding through time is really fast because it doesn’t need to retrieve more data. With 4 bands of 255 values each you can encode an insane amount of data into a PNG, readily available through canvas for direct manipulation. Apart from time sliding, is detailed representation of DEM data an obvious use case.

However a map consists of more than points. So I wrote a simple Perl script to transform the coordinates of a GeoJSON into Dymaxion. It should find any coordinate pairs in Point, LineString, Polygon, MultiPoint, MultiLineString and MultiPolygon features and replace the pairs with dymaxion ones. These new pairs do not make a lot of sense in normal GIS software, but exporting them to SVG will give you a nice Dymaxion map. GeoJSON is not a common format (yet!?) but it is easy to create form a shapefile using ogr2ogr.

So the steps to follow are:
1 convert your input shapefile to json:
ogr2ogr -f GeoJSON processed.json input.shp

2 dymaxionify your json:

./dymyx.pl

3 load the json in qgis

qgis output.json

4 export the map as SVG

unfortunately I don’t know a comandline for that, but if you use the print composer tool, and compose a map you can save that as SVG. There might be easier ways, but haven’t found them yet.

For example I ran the 50m-coastlines and created a new dymaxion coastline SVG as seen here

Note: it doesn’t handle encoded characters as it should aka a bug

Click here to view the embedded video.

The Surface has been hanging around in our office for a while and we’ve done lots of interesting small and big projects for it. However they’ve been pretty fragmented and to show what we could do with the Surface you had to use several applications which had many similarities, which was confusing. So we decided that it was time to create an application which would show all our new ideas and developments. Looking for a nice name we came across ‘kõik‘ which both means everyone and every(thing), which is pretty much sums up what we want to achieve: an application which can be used by everyone and shows everything we do.

It was originally designed for landuse planning. Planners need to be able to move and zoom a map, but also annotate on it. The trouble with touch devices is that there is no difference between drawing and dragging, unlike keyboard/mouse (drawing is left mousebutton and dragging middle for instance). Having to press a button somewhere on the Surface to enable/disable drawing was too confusing, people tend to forget that they pressed them and in what modus they are now.

Having a physical object on the table turned out to be much easier to use and remember. If there was ‘the’ object on the table, you could draw and if you want to move the map, you just lift the object and move the map. Having established the object as the drawing-toggle, I then moved all drawing related interaction to a menu activated and related to the object. Currently you can choose the color and line thickness and whether you want to draw a line or polygon or you want to edit existing features, undo/redo actions and add new drawing layers.

(Image taken from the presentation I’m giving at foss4g 2010)

I’m involved in EduGIS and one of the nice things about this project is that we have hundreds of map layers. However that begins to pose a problem for us; to produce a decent speed for classes full of schoolkids using it at the same time we are using tiling.

We currently use TileCache; a very nice and quick open source tilecaching program. However we keep adding layers and we need those to be quick when students are using them, but we don’t have the capacity to prerender (seed) everything, nor to do this on the fly. Since we mostly have dutch data, served at dutch students, we figured that we only need to seed a certain set of tiles; the entire country for the higher levels and the rural areas a bit deeper and the urban areas even deeper.

So I came up with the idea to create a desktop application to make it easier to create a complex seed that does more zoomlevels for certain areas and less for others.

Thanks to generous development time invested by Christian there is a first alpha available around foss4g at googlecode

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.

Click here to view the embedded video.

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.

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.