CASA Blog

There was a very good turn out from CASA at the CUPUM 2009 conference,
University of Hong Kong. It was an excellent conference, so many thanks to
the organisers.

A wide range of current CASA research was presented. Kiril Stanilov spoke
about how concepts from urban morphology can be used to improve the
representation of urban form in CA and ABS models (Figure 1, Figure 2). Sofia do Campo
presented advances in sustainability impact assessment for land-use and
transportation integrated modelling in Lisbon.

Joel Dearden described his research with Alan Wilson in using novel 3D
visualisation techniques to explore urban retail phase transitions. And
finally, Duncan Smith presented on using real-estate data to map
polycentric office and retail development in Greater London.

Please contact the authors with any comments and questions on the research.

Conway’s Game of Life

 http://www.casa.ucl.ac.uk/richard/demos/planet/GameOfLifePlanet.html

The way this was created was as follows:

Step 1 - Create the Planet Mesh

I’ve defined my axes with x to the right, z up and y into the screen. This is slightly unusual, but maps to the ground plane which was originally XZ.

for z=0 to numZ-1     for x=0 to numX-1           ax=x/numX*2.0*PI-PI;           az=z/numZ*PI-PI/2;           cx=radius*cos(az)*sin(ax);           cy=radius*cos(az)*cos(ax);           cz=radius*sin(az);           coords[x][z]=new Point3D(cx,cy,cz);

The mesh of points can be wrapped around in the x direction, but not Z, so we need an extra line of points at the South pole. I’ve also taken the radius to be 1.0 as using the unit sphere simplifies a lot of the graphics calculations that follow.

This gives you the following result:

Planet Mesh

Step 2 - Spin the World

Next I added an animation thread that increments ‘A’, the angle of rotation of the planet. In the rendering code for the mesh I rotate the points to spin the planet around the poles. The interesting thing here is that you don’t need the Y coordinate as there’s no projection, so that saves a few operations.

xp[i]=radius*(xpoints[i]*cos(A)+ypoints[i]*sin(A)) //yp[i]=radius*(xpoints[i]*sin(A)-ypoints[i]*cos(A)) zp[i]=radius*zpoints[i] 

The back faces have been removed by using the direction between the surface normal and the viewer. Any face pointing away from the viewer is not drawn.

Step 3 - Add the Game of Life Simulation

I already had an implementaion of this in Java, so I just pulled it into the project. The following wikipedia article contains everything you could every need to know about Conway’s Game of Life:

http://en.wikipedia.org/wiki/Conway’s_Game_of_Life

Then it’s just a case of running the ALife simulation and linking the output to the cells in the planet mesh. The grid used for the Game of Life simulation and the mesh making up the planet are the same size, so there is a simple one to one relationship.

Game of Life Planet

Step 4 - Lights

To improve the realism, I added some lighting using Lambert’s cosine rule. The direction of the light is [-1.0, 0.0, 0.0] which makes the intensity calculation straightforward. The light is assumed to be far enough away that the direction of the light is constant over the whole object. The planet is a unit sphere centred on the origin, so the normal to the surface patch is just a ray through the origin and the centre of the patch. I’ve actually taken the top left corner to save having to calculate the centre point, but it doesn’t make much difference to the effect.

According to Lambert’s cosine rule, the intensity of the patch is proportional to the cosine of the angle between the surface normal and the light. We use the dot product of the two vectors to get the cosine of the acute angle between them. As both vectors are already normalised beforehand, we don’t have to normalise them ourselves.

In this view, any game of life cell that is ‘on’ is drawn in blue, while any that are ‘off’ are white. The white colour uses the diffuse lighting while the blue is drawn as emissive so you can see the patterns as they go around the dark side of the globe. I’ve also added a line at the 0 and 180 degree longitude positions so you can see the planet rotating.

Here is an image of a “Gosper Glider Gun” about to shoot gliders at itself from around the other side of the planet. The applet link below contains a number of the more common patterns.

Gosper Glider Gun http://www.casa.ucl.ac.uk/richard/demos/planet/GameOfLifePlanet.html

It’s actually a stacked bar chart rather than a traditional population pyramid, but the image below shows male/female population by age for all the output areas in England. The red thematic overlay is total population for every OA, which can be clicked to get the age group breakdown shown in the popup window.

Clickable Age Map

This map is a variation on the original clickable OAC map and was built using a new version of the GMapCreator which contains the clickable technology. Traditionally, maps like this have been built using a server and database to translate the click on the client into a geographic area using point in polygon and then sending the query data back to the client. This method doesn’t scale when you have limited server resources and are looking to handle high numbers of hits, for example with the Mood Maps that we’ve been doing recently. An alternative solution is to build feature coded tiles and let the client handle most of the work displaying the data. Using this system, there is a second set of tiles, one of which the client downloads when the user clicks on a point. This allows the client to work out which feature has been clicked and request the data for that area as an xml file.

The hard part is designing a system which can allow people to design the popup window without having to resort to programming. In the example above, the graph was created using Google Charts via the GMapCreator’s user interface. All that was needed was to choose the data fields from a list and to select the chart type. The URI string to create the chart comes from an xslt transform applied to the xml data. This transform is automatically created by the GMapCreator interface, which also allows the rest of the popup window to be designed using a simple html editor.

CASA is running a series of workshops that focus on good research practice. The aim is to stimulate discussion and broaden participants� exposure to new ideas and literature.

The workshops are intended for CASA PhD students but everyone is welcome to attend.

The next session with Professor Sir Alan Wilson�entitled Academic entrepreneurship: the GMAP Story will be held today at 5pm in the SPLINT room, Pearson Building.

The slides from this session are available to download here.

It’s actually very easy to get data from a shapefile onto OpenStreetMap using OpenLayers and the GMapCreator. The example below shows the social cohesion data from Mark Easton’s BBC blog

The working OpenLayers/OpenStreetMap map can be viewed at the following link: http://www.maptube.org/maps/BBC/MarkEaston/communitycohesiondata.html�

This page was generated using the GMapCreator and a custom template that I created�for OpenLayers. The resulting map page could be�completely Google free if required, but this one includes the Google map, satellite, hybrid and terrain layers as options, along with the OpenStreetMap Mapnik and Osmarender base layers.

The prototype GMapCreator template can be downloaded from the following link (right click on it and use ’save as’ to save the file):

http://www.casa.ucl.ac.uk/richard/GoogleMapCreator/GMC_OSM_template.html

The file is loaded into the GMapCreator�from the�‘Edit’�menu and the ‘Use Custom HTML Template’ option. All suqsequent maps will then use this template until the option is turned off.

Using Sketchup to create models is free and exceptionally easy to do.�The only thing lacking in the free version are the import and export options which are found in the Pro version.�This appears to limit its usefulness in creating�assets which can be used outside of Sketchup, �but often overlooked is the Ruby scripting interface. As an experiment to see how easy it is to export models, a Ruby script was written to export to Microsoft’s X File format. While we’re aware that this is deprecated in DX10, code to load this format will be around for a long time to come and just about every professional art tool has the ability to load this format. The results of this experiment are shown below:

The conversion isn’t perfect, as you might notice that the palm tree is inside out and materials and texture coordinates aren’t handled yet. As a first attempt at exporting geometry it shows that there is a relatively simple export path from sketchup and Google warehouse into 3rd party software.

Having written a program earlier to pre-create�a tile pyramid for Google Maps which was then used to put synoptic observations onto the map, the next stage of the plan�was to use the same tile drawing code to render tiles on the fly. The new architecture�is a tile caching and creation architecture where requests are made to a tile cache which can either return a previously cached tile or draw a new one and cache it on the fly.

The code is designed to work with things other than weather data, so the drawing of the tiles is handled through a TileCreator class which is extended to make a WeatherTileCreator class which is then used by the tile cache for creating new tiles. The results are shown below:

�

The tile divisions are shown by the black lines and the amount of time taken to draw the tile is shown in blue in the top left. Although the timings are heavily dependent on what is drawn on the tile and the amount of data, this shows that it is possible to use this type of system for data that can’t be pre-created. For example, weather data that changes every hour, or mood maps that update in true real-time.

This example was written in C# using an IIS server and a generic handler for making the requests to the tile cache. The drawing of data onto the tiles was done in a naive way where every piece of data was checked for intersection with the tile rather than using a spatial index, so this example could be made to run a lot faster.