Geo-referencing and Tile-cutting Raster Imagery

Just as there are many different formats in which vector spatial data may be represented: Well-Known Text (WKT), Well-Known Binary (WKB), Geography Markup Language (GML), and Keyhole Markup Lanuage (KML), to name but a few – so too are there many different formats of raster spatial data.  In fact, almost any image format can be used to encode raster spatial data – since each pixel in an image naturally corresponds to an X,Y location in a raster grid. Any regular BMP, GIF, PNG, JPG, or TIFF image file can therefore be used to store spatial data, so long as the real-world coordinates corresponding to the pixels in each corner of the image are known (and thus the coordinates of each other pixel in the image can be determined). The process of assigning coordinates from a spatial reference system to a raster image is known as geo-referencing.

Some dedicated spatial raster formats, such as GeoTIFF, encode coordinate metadata along with the image data in a single file. However, the raster images used by Open Street Maps, Bing Maps, and Google Maps don’t use GeoTIFFs – they are formed from a series of 256px x 256px tiles saved as regular PNG and JPG images. The metadata describing the geographic extent of each tile is encoded entirely in the filename, which, in Bing Maps, uses the quadkey numbering system as described here.

For example, the following tile shows the Bing Maps road map style tile for quadkey 031311, retrieved from


Knowing nothing but the quadkey number, 031311, and the formulas in the MSDN article linked above, I can calculate that the exact geographic extent of features shown on this tile lie from longitude of –5.625 to 0, and latitude between 52.4827802220782 and 55.7765730186677. Like all Bing Maps tiles, they are projected using the Spherical Mercator projection.

Here’s another tile – this time 120200223:


Once again, I can immediately determine from the quadkey that the extent of this tile has longitude ranging from 0.703125 to 1.40625 and latitude from 52.4827802220782 to 52.9089020477703.

The quadkey system is quite beautiful in its simplicity and efficiency. There are, of course, some limitations with this sort of tiling system – all raster data must be represented using the same projection, and every tile must be regularly-sized, for example, but these limitations are offset by the ease with which it’s possible to place any tile at any zoom level at the correct position on the map with minimum amount of coding.

Preparing Custom Tiles

To get your own raster data into Bing Maps (such as a digitized map or floor plan), you need to prepare a series of individual quadkey tile images following the structure outlined above. Applications such as Safe FME and Microsoft MapCruncher provide the ability to prepare raster images for use as background tile layers in Bing Maps (or Google Maps), or you can write your own script to do so. The process is generally known as “tile-cutting”, and the steps are described below:

1.) First, start out with a source image. Here’s John Snow’s famous map of the Cholera outbreak that occurred in Broad Street in London, 1854:


2.) Georeference the image, by assigning coordinates to corresponding pixel positions in the image. If the image is not already in the correct projection, it might need to be warped to bring features into line with the Mercator projection as used by Bing Maps. The image below shows the interface provided by Mapcruncher for placing reference points in the source image (left hand pane) and Bing Maps (right hand pane):


3.) The geo-referenced, transformed image must then be cut into a series of 256px x 256px tiles at different levels of magnification, numbered according to quadkey. For example, the tile below shows a single tile from zoom level 16 of the above image (quadkey 0313131311122330):


4.) Finally, create a tilelayer that references the set of quadkey tile images. Assuming that the tiles are all saved in the same directory, this is as simple as adding the following lines of javascript. the Bing Maps v7 control will expand the {quadkey} placeholder to the appropriate quadkey filename for each tile request:

// Define the tile source
var tileSource = new Microsoft.Maps.TileSource({
  uriConstructor: '{quadkey}.png'

// Construct a tile layer based on the tile source
var tilelayer = new Microsoft.Maps.TileLayer({
  mercator: tileSource,
  opacity: 1.0,
  visible: true,
  zIndex: 1

// Place the layer onto the map

The result

Once the tilelayer is added to the map, whenever a part of that tilelayer comes into view Bing Maps will automatically request and stitch together the appropriate tile images and overlay them at the appropriate position on the map.

The screenshot below shows the result of overlaying Jon Snow’s Cholera map onto a modern day map of London using Bing Maps’ default road map style using the steps described above. Notice how well the roads that cross the edges of the tile layer line up – John Snow was not only the father of epidemiology, but also a highly talented cartographer:


This entry was posted in Bing Maps, Spatial and tagged , , . Bookmark the permalink.

7 Responses to Geo-referencing and Tile-cutting Raster Imagery

  1. rbrundritt says:

    It’s also pretty easy to create a web service that cuts the tiles dynamically using .NET drawing tools. Johannes wrote an article on this a long time ago but I can’t find it for the life of me.

  2. alastaira says:

    You’re jumping ahead of me, Ricky – that’s gonna be another post!

  3. Both MapCruncher, Globalmapper even gdal is great for small raster images, the issue is when you want to take this to the next level and tile out a large section of high res aerial imagery. It is super slow to tile out and your file system dies very quickly when you start making folders with 100,000 tiny images.
    I’ve had good success with storing tiles in Azure blob storage (actually pretty cheap as you can access directly without needing a web instance running) or stored in my SQL Server 2008 database as binary.
    What I havn’t found however is a good tiling engine. Funny that non spatial tiles are well supported in Microsoft’s photo tools, HDView plugin is the best, actually writing the little tiles to 50MB (or custom size) zip files ready to upload.
    Love to know if anyone has had really good success with large tileset production and serving.

  4. alastaira says:

    Yes – good point John – although I didn’t mention it explicitly, this article was aimed at the beginner and intended to provide an introduction to the theory and broad process involved in creating custom tilesets from relatively small, simple images rather than an in-depth discussion of performance of different approaches for large tilesets 😉
    However, that would be a *very* useful discussion to have – I myself have a situation at the moment when I’m trying to cut tiles covering an area approximately 60km across by 50km high. If my calculations are correct, to cover that area at zoom level 19 will require 1.3 million tiles…
    The underlying data used to create the tiles comes from a database query, which, currently, takes about 200ms to execute. i.e. I can create a whopping total of 5 frames per second. If I’m ever to get this dataset produced before I grow a long, grey beard, I think I might need to rethink the approach! (or else, throw a *lot* more hardware at it!)

  5. Ben Drake says:

    Great post alastaira! I just wanted to make you and your readers aware of a commercial solution which, in addition to providing access to imagery, can process GeoTiffs, large or small and store them in SQL Server. See One customer has over 50 million tiles stored as BLOBs and indexed spatially for fast access. The underlying technology is a derivative of Bing Maps for on-premises use.

    Full disclosure: I’m part of the Vexcel team which develops and supports the product.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s