3 Crime Maps: Point collation

 

Quick update of the Placemark Clustering project: we’ll be doing user tests using the uk police crime map later this summer (discussed below) comparing it to a chloropleth grid (translation = head map based on grid, I explain further here)
In thinking about this I’ve hunted down some examples and I thought it would be interesting to name check 3.


No Collation: The first map is Oakland Crime Spotting (bottom inset in figure) that is very similar to San Francisco Crime mapping, reviewed here. Unlike the other two maps it attempts no point collation at all, I image the authors would argue that they deal with the problem by providing sophisticated filtering tools to reduce the point density. However, it doesn’t help if the user wants to get an overview picture of crime across the area the map covers.
Traditional Choropleth: Switching to the the UK, the Metropolitan Police (=London for non UK readers) offer a choropleth map based on wards and subwards (top left insert). I regard this as the traditional approach. Notably it doesn’t show actual figures for postcodes, only sub wards – a sub ward is a collection of postcodes. My problem with this is that almost no one knows the boundaries of wards and sub wards so its a strange way to split the city up. (Aside: in my experience, Londoners tend to split London up based on tube stations)
Point Collation: The UK police offer a national map which uses point collation (top right insert). This is the main one we’re planning to test as IMHO it isn’t an effective way to visualise the data (related post). It offers a finer grain of data – you don’t actually see the true location of the crime but it is collated down to the postcode level. In London, a postcode is roughly equal to a single street.

 

Deleting Blank Tiles

 

Creating raster tilesets almost invariably leads to the creation of some blank tiles – covering those areas of space where no features were present in the underlying dataset. Depending on the image format you use for your tiles, and the method you used to create them, those “blank” tiles may be pure white, or some other solid colour, or they may have an alpha channel set to be fully transparent.

Here’s an example of a directory of tiles I just created. In this particular z/x directory, more than half the tiles are blank. Windows explorer shows them as black but that’s because it doesn’t process the alpha channel correctly. They are actually all 256px x 256px PNG images, filled with ARGB (0, 0, 0, 0):

image

What to do with these tiles? Well, there’s two schools of thought:

  • The first is that they should be retained. They are, after all, valid image files that can be retrieved and overlaid on the map. Although they aren’t visually perceptible, the very presence of the file demonstrates that the dataset was tested at this location, and confirms that no features exist there. This provides important metadata about the dataset in itself, and confirms the tile generation process was complete. The blank images themselves are generally small, and so storage is not generally an issue.
  • The opposing school of thought is that they should be deleted. It makes no sense to keep multiple copies of exactly the same, blank tile. If a request is received for a tile that is not present in the dataset, the assumption can be made that it contains no data, and a single, generic blank tile can be returned in all such instances – there is no benefit of returning the specific blank tile associated with that tile request. This not only reduces disk space on the tile server itself, but the client needs only cache a single blank tile that can be re-used in all cases where no data is present.

I can see arguments in favour of both sides. But, for my current project, disk and cache space is at a premium, so I decided I wanted to delete any blank tiles from my dataset. To determine which files were blank, I initially thought of testing the filesize of the image. However, even though I knew that every tile was of a fixed dimension (256px x 256px), an empty tile can still vary in filesize according to the compression algorithm used. Then I thought I could loop through each pixel in the image and use GetPixel() to retrieve the data to see whether the entire image was the same colour, but it turns out that GetPixel() is slooooowwwww….

The best solution I’ve found is to use an unsafe method, BitMap.LockBits to provide direct access to the pixel byte data of the image, and then read and compare the byte values directly. In my case, my image tiles are 32bit PNG files, which use 4 bytes per pixel (BGRA), and my “blank” tiles are completely transparent (Alpha channel = 0). Therefore, in my case I used the following function, which returns true if all the pixels in the image are completely transparent, or false otherwise:

public static Boolean IsEmpty(string imageFileName)
{
  using (Bitmap b = ReadFileAsImage(imageFileName))
  {
    System.Drawing.Imaging.BitmapData bmData = b.LockBits(new Rectangle(0, 0, b.Width, b.Height), System.Drawing.Imaging.ImageLockMode.ReadOnly, b.PixelFormat);
    unsafe
    {
      int PixelSize = 4; // Assume 4Bytes per pixel ARGB
      for (int y = 0; y < b.Height; y++)
      {
        byte* p = (byte*)bmData.Scan0 + (y * bmData.Stride);
        for (int x = 0; x < b.Width; x++)         {           byte blue = p[x * PixelSize]; // Blue value. Just in case needed later           byte green = p[x * PixelSize + 1]; // Green. Ditto           byte red = p[x * PixelSize + 2]; // Red. Ditto           byte alpha = p[x * PixelSize + 3];           if (alpha > 0) return false;
        }
      }
    }
    b.UnlockBits(bmData);
  }

  return true;
}

 

It needs to be compiled with the /unsafe option (well, it did say in the title that this post was dangerous!). Then, I just walked through the directory structure of my tile images, passing each file into this function and deleting those where IsEmpty() returned true.

 

Bing Maps Control for Windows Phone 7 lagging

This is a video showing the Silverlight Bing Maps Control for Windows Phone 7 showing some serious lagging behaviour on my HTC 7 Trophy. As you can see the built-in Windows Phone maps app performs normally (note that it’s a native thing and doesn’t use the Bing Maps Control), but the two user apps, Map Mania and Slim Tanken, both show some serious lagging while pinching/zooming

http://www.youtube.com/v/kixSTJT99-g?f=videos&app=youtube_gdata