Raspberry Pi Pico Tips and Tricks

Sunday 26 January 2014

Delivering maps on a web page. Some (very) basics.

The following post is a portion of the Leaflet Tips and Tricks book which is free to download. To use this post in context, consider it with the others in this blog or just download the the book as a pdf / epub or mobi .

How do maps get presented on a web page?

Vectors and bitmaps.

This is a pretty large topic and as you will probable know, there are a lot of alternatives for viewing maps on the internet. But ultimately they all need to put a picture on a screen. There is more than one way to do this, with the largest difference being the presentation of the image on the screen being either a vector image or a bitmap.
Vector graphics use a technique of drawing an image that relies more on a description of an image than the final representation that a user sees. Instead of arranging individual pixels, an image is created by describing the way the image is created. For instance, drawing a line would be accomplished by defining two sets of coordinates and specifying a line of a particular width and colour be drawn between the points. This might sound a little long winded, and it does create a sense of abstraction, but it is a powerful mechanism for drawing as there is no loss of detail with increasing scale. Changes to the image can be simply carried out by adjusting the coordinates, colour description, line width or curve diameter. This is the technique that is commonly used with d3.js when generating a map from geojson or topojson data.
A bitmap (or raster) image is one that is composed of lots of discrete individual dots (let’s call them pixels) which, when joined together (and zoomed out a bit) give the impression of an image. Bitmaps can be saved in a wide range of formats depending on users requirements including compression, colour depth, transparency and a host of other attributes. Typically they can be identified by the file suffix .jpg, .png or .bmp (and there are an equally large number of other suffixes). This is what will be presented by by most of the major online map service providers such as GoogleMicrosoftOpen Street Map and others when a map appears in your browser.
Setting aside satellite / aerial imagery (which is the result of a photograph being taken of a geographic location), maps are not made by users drawing bitmaps of locations. The information is stored as data that is more akin to vector information. A road will be an array of geographic points that are joined up and given a name and other descriptive data. But presenting that information on a web page in that format can be slightly problematic. There are browser compatibility and formatting issues that can make the process difficult and the end result inconsistent. However, pretty much every browser will render a bitmap on the screen without any trouble. So online map providers generate bitmaps from their vector data which they can use to provide a simple consistent interface for presentation.
The only problem with supplying bitmaps of geographical information is that to get a high level of resolution for an area, you have to have a really large image. This would be difficult to handle in a browser and a tremendous burden on download time. The solution to this is to break up the bitmap into smaller sections called tiles.

Map tiles and zoom levels

Before we get serious about showing you some tile goodness, please be aware that the reproduction of Open Street Map data is made possible under the Open Database License, and if using their map tiles, the cartography is licensed as CC BY-SA. For more information on the Copyright and License obligations please visit their page here.
To break a picture of a map up into small manageable sections (tiles) the tile server that produces the tiles will distinguish between different levels of zoom and for each level they will have a different set of tiles that correspond to different locations on the map. Since the (almost universal) standard for tile size is 256 x 256 pixels, at zoom level 0 the entire world is encapsulated in a single 256 x 256 pixel tile.

Zoom Level 0. © OpenStreetMap contributors
With every subsequent increase in zoom level there is a doubling of the resolution available and therefore an increase in the number of tiles by a factor of four.
So at zoom level 1 there are four tiles…
Zoom Level 1. © OpenStreetMap contributors
At zoom level 2 there are 16 tiles…
Zoom Level 2. © OpenStreetMap contributors
Etc, etc.
I’m sure you can appreciate that each increases in zoom level has the consequence of substantially increasing the number of tiles required. When we get to zoom level 18 there would be a requirement to have over 68 billion tiles (actually 68,719,476,736). The good news is that at the higher zoom levels there are a significant number of tiles that show nothing of interest ( I would be interested in knowing how many 256 x 256 tiles of blue sea there would be) and because tiles are only rendered when someone actually views them, the number of tiles that are produced at the higher zoom levels is a lot less than the theoretical number required. In fact as of 2011 there were only just over 617 million tiles at zoom level 18 rendered meaning that less than 1% of the potential viewable tiles at that level had ever been requested.
Calculations on the Open Street Map wiki give the theoretical volume of data required if all tiles up to zoom level 18 were rendered as 54 Terabytes of storage. But by judicious use of rendering only those required tiles, they report the volume required for storage as of January 2012 as just over 1.2 Terabytes.

The description above (and heaps of other stuff) is in the Leaflet Tips and Tricks book that can be downloaded for free (or donate if you really want to :-)).

No comments:

Post a Comment