By georeferencing, or attaching our data to coordinates, we assert the geographic location of each object in our data. Once our data is georeferenced, we can call it geospatial. Georeferencing is done according to the fields in the data and those available in some geospatial reference source.

The simplest example is when a data field actually matches a field in some existing geospatial data. This data field is often an ID number or name. This kind of georeferencing is called a table join.

tract,date,mean_temp
014501,2010-06-01,73
014402,2010-06-01,75
014703,2010-06-01,75
014100,2010-06-01,76
014502,2010-06-01,75
014403,2010-06-01,75
014300,2010-06-01,71
014200,2010-06-01,72
013610,2010-06-01,68

"String","Date","Integer"

Orthorectify

Finally, if our data is an image or grid (raster), we can match up locations in the image with known locations in a reference map. The registration of these pairs and subsequent transformation of the grid is called orthorectification or sometimes by the more generic term, georeferencing (even though that applies to a wider range of operations).

1. Add a basemap, to be used for reference:
   1. Add the OpenLayers plugin. Navigate to Plugins | Manage | Install Plugins; select OpenLayers Plugin and click on Install.
   2. Navigate to Web | OpenLayers plugin, and select the basemap of your choice. MapQuest-OSM is a good option.
2. Obtain map image:
   1. I have downloaded a high-resolution image (c1/data/original/4622009.jpg) from David Rumsey Map Collection, MapRank Search (http://rumsey.mapranksearch.com/), which is an excellent source for historical map images of the United States.
   2. Search by a location, filtering by time, scale, and other attributes. You can find the image we use by searching for Newark, Delaware.
   3. Once you find your map, navigate to it. Then, find Export in the upper right-hand corner, and export an extra high-resolution image.
   4. Unzip the downloaded folder.
3. Orthorectify/georeference the image with the following steps:
   1. Install and enable the Georeferencer GDAL plugin.
   2. Navigate to Raster | Georeferencer | Georeferencer.
   3. Pan and zoom the reference basemap in the canvas on a location that you recognize in the map image.
   4. Pan and zoom on the map image.
   5. Select Add Control Point if it is not already selected.
   6. Click on the location in the map image that you recognized in the third step.
   7. Click the Pencil icon to choose control point from Map Canvas.
   8. Click on the location in the reference basemap.
   9. Click on OK.
   10. Add three of these control points, as shown in the following screenshot:
       
   11. Start georeferencing by clicking on the Play button.
   12. Enter the transformation settings information, as shown in the following screenshot:
   
4. Now, start georeferencing by clicking on the Play button again.

Once your image has been georeferenced, you should see it align with the other data on your map. You can alter the layer transparency under Layer properties | Transparency:

QGIS will sometimes do an On-the-Fly (OTF) projection of all the data added to the canvas on the project CRS (defined under Project | Project Properties | CRS). You will want to disable OTF projection in the projects you intend to produce for web applications, as all layers should have their own spatial reference independently defined and transformed or projected in the same CRS, if needed.

Setting CRS

When geospatial data is received with no metadata on what the spatial reference system describes its coordinates, it is necessary to assign a system. This can be by right-clicking on the layer in Layers Panel | Save as and selecting the new CRS.

Transformation and projection

At other times, data is received with a different CRS than in the case of the other data used in the project. When CRSs differ, care should be taken to see whether to alter the CRS of the new nonconforming data or of the existing data. Of course we want to choose a system that supports our needs for accuracy or extent; at other times when we already have a suitable basemap, we will want operational layers to conform to the basemap's system. When a suitable basemap is already available to be consumed by our web application, we can often use the system of the basemap for the project. All major third-party basemap providers use Web Mercator, which is now known as EPSG:3857.

You can project data from geographic to projected coordinates or from one projection to another. This can be done in the same way as you would define a projection: by right-clicking on a layer in Layers Panel | Save as and selecting the new CRS. An appropriate transformation will generally be applied by default.

There are some features in CRS Selector that you should be aware of. By selecting from Recently used coordinate reference systems, you can often easily match up a new CRS with those existing in the workspace. You also have the option to search through the available systems by entering the Filter input. You will see the PROJ.4 WKT representation of the selected CRS at the bottom of the dialog.

The layer style is configured through the Style tab in the Layer Properties dialog. The Single Symbol style is the default style type, and it simply shows all the geographic layer objects using the same basic symbol. This setting doesn't provide any visual differentiation between objects other than their apparent geospatial characteristics. The Categorized and Graduated style types provide different styles according to the attribute table field of your choosing. Graduated, which applies to quantitative data, is particularly powerful in the way the color and symbols size are mapped to a numerical scale. This is all accomplished through the Layer Properties | Style tab.

To configure a simple graduated layer style to the data, perform the following steps:

You will now see the following output:

Perhaps the lower temperatures to the north of the city are related to the historical development in other parts of the city.

Labels can provide important information in a map without requiring a popup or legend. As labels are automatically placed by the software (they do not have an actual physical position in space), they are subject to particular placement issues. Also, a map with too much label text quickly becomes confusing. Sometimes, labels can be easily rendered into tiles by integrated QGIS operations. At other times, this will require an external rendering engine or a map server. These issues are discussed later on in this chapter.

To label the address points in our example, go to that layer's Layer Properties | Labels tab. Perform the following steps:

Obtaining data for a basemap is not a trivial task. If a suitable map service is available via a web service, it would ease the task considerably. Otherwise, you must obtain supporting data from your local system and render this to a suitable cartographic format.

A challenge in creating basemaps and keeping them updated is interacting with different data providers. Different organizations tend be recognized as the provider of choice for the different classes of geographic objects. With different organizations in the mix, different data format conventions are bound to occur.

OpenStreetMap (OSM), an open data repository for geographic reference data, provides both map services and data. In addition to OSM's own map services, the data repository is a source for a number of other projects offering free basemap services.

OpenStreetMap uses a more abstract and scalable schema than most data providers. The OSM data includes a few system fields, such as osm_id, user_id, osm_version, and way. The osm_id field is unique to each geographic object, user_id is unique to the user who last modified the object, osm_version is unique to the versions for the object, and way is the geometry of the object.

By allowing a theoretically unlimited number of key value pairs along with the system fields mentioned before, the OSM data schema can potentially allow any kind of data and still maintain sanity. Keys are whatever the data editors add to the data that they upload to the repository. The well-established keys are documented on the OSM site and are compatible with the community produced rendering styles. If a community produced style does not include the key that you need or the one that you created, you can simply add it into your own rendering style. Columns are kept from overwhelming a local database during the import stage. Only keys added in a local configuration file are added to the database schema and populated.

High quality cartography with OSM data is an ongoing challenge. CloudMade has created its business on a cloud-based, albeit limited, rendering editor for OSM data, which is capable of also serving map services. CloudMade is, in fact, a fine source for cloud services for OSM data and has many visually appealing styles available. OpenMapSurfer, produced by a research group at the University of Heidelberg, shows off some best practices in high quality cartography with OSM data including sophisticated label placement, object-level scale dependency, careful color selection, and shaded topographic relief and bathymetry.

To obtain the OpenStreetMap data locally to produce your own basemap, perform the following steps:

Here's an example of the OSM data overlaid on our other layers with a basic, single symbol style:

When classes of geographic objects are unnecessary to visualize at certain scales, the whole layer scale dependency can be used to hide the layer from view. For example, in the preceding image, we can see all the layers, including the geocoded addresses, at a smaller scale even when they may not be distinctly visible. To simplify the information, we can apply the layer scale dependency so that this layer does not show these small scales.

At this scale, some objects are not distinctly visible. Using the layer scale dependency, we can make these objects invisible at this scale.

It is also possible to alter visibility with scale at the geographic object level within a layer. For example, you may wish to show only the major roads at a small scale. However, this will generally require more effort to produce. Object-level visibility can be driven by attributes already existing or created for the purpose of scale dependency. It can also be defined according to the geometric characteristics of an object, such as its area. In general, smaller features should not be viewable at lower scales.

A common way to achieve layer dependency at the object level using the whole-layer dependency is to select objects that match the given criteria and create new layers from these. Scale dependency can be applied to the subsets of the object class now contained in this separate layer.

You will want to set the layer scale dependency in accordance with scale ratios that conform to those that are commonly used. These are based on some assumptions, including those about the resolution of the tiled image (96 dpi) and the size of the tile (256px x 265px).

Labels are commonly separated from the basemap layer itself. One reason for this is that if labels are included in the basemap layer, they will be obscured by the operational layer displayed above it. Another reason is that tile caching sometimes does not properly handle labels, causing fragments of labels to be left missing. Labels should also be displayed with their own scale dependency, filtering out only the most important labels at smaller scales. If you have many layers and objects to be labeled, this may be a good use case for a map server or at least a rendering engine such as Mapnik.

The best way to cache your basemap data so that it quickly loads is to save it as individual images. Rather than requiring a potentially complicated rendering by the browser of many geometric features, a few images corresponding to the scale and extent to which they are viewed can be quickly transferred from client to server and displayed. These prerendered images are referred to as tiles because these square images will be displayed seamlessly when the basemap is requested. This is now the standard method used to prepare data for web mapping. In this book, we will cover two tools to create tile caches: QTiles plugin (Chapter 1, Exploring Places – from Concept to Interface) and TileMill/MBTiles (Chapter 7, Mapping for Enterprises and Communities).

You will need to pay some attention to the scheme for tile storage that is used. The .mbtiles format that TileMill uses is a SQLite database that will need to be read with a map interface that supports it, such as Leaflet. The QTiles plugin and GDAL2Tiles.py use an XYZ tile scheme with hierarchical directories based on row (X), column (Y), and zoom (Z) respectively with the origin in the top-left corner of the map. This is the most popular tiling scheme. The TMS tiling scheme sometimes used by GeoServer open source map server (which supports multiple schemes/service specifications) and that accepted by OSGeo are almost identical; however, the origin is at the bottom-left of the map. This often leads to some confusing results. Note that zoom levels are standardized according to the tile scheme tile size and resolution (for example, 256 x 256 pixels)

Generating and testing a simple directory-based tile cache structure

We will now use the QTiles plugin to generate a directory-based ZYX tile scheme cache. Perform the following steps:

1. Install QTiles and the TileLayer plugin.
   • QTiles is listed under the experimental plugins. You must alter the plugin settings to show experimental plugins. Navigate to Plugins | Manage and Install Plugins | Settings | "Show also experimental plugins".
2. Run QTiles, creating a new mytiles tileset with a minimum zoom of 14 and maximum of 16.
3. You'll realize the value of this directory in the next example.
   
4. You can test and see whether the tiles were created by looking under the directory where you created them. They will be under the directory in the numbered subdirectories given by their Z, X, and Y grid positions in the tiling scheme. For example, here's a tile at 15/9489/12442.png. That's 15 zoom, 9489 longitude in the grid scheme, and 12442 latitude in the grid scheme.

You will now see the following output:

Create a layer description file for the TileLayer plugin

Create a layer description file with a tsv (tab delimited) extension in the UTF-8 encoding. This is a universal text encoding that is widely used on the Web and is sometimes needed for compatibility.

Note

Note that the last six parameters are optional and may prevent missing tiles. In the following example, I will use only the z parameters, zmin and zmax, related to map zoom level.

1. Add text in the following form, containing all tile parameters, to a new file:

   title credit url yOriginTop [zmin zmax xmin ymin xmax ymax]

   • For example, mytiles me file:///c:/packt/c1/data/output/tiles/ mytiles/{z}/{x}/{y}.png 1 14 16.
   • In the preceding example, the description file refers to a local Windows file system path, where the tiled .png images are stored.
2. Save mytiles.tsv to the following path:

   [YOUR HOME DIRECTORY]/.qgis2///python/plugins/TileLayerPlugin/layers

   • For me, on Windows, this was C:\Users\[user]\.qgis2\python\plugins\TileLayerPlugin\layers.

     Note

     Note that .qgis2 may be a hidden directory on some systems. Make sure to show the hidden directories/files.

   • The path for the location to save your TSV file can be found or set under Web | TileLayer Plugin | Add Tile Layer | Settings | External layer definition directory.

Preview it with the TileLayer plugin. You should be able to add the layer from the TilerLayerPlugin dialog. Now that the layer description file has been added to the correct location, let's go to Web TileLayerPlugin | Add Tile Layer:

After selecting the layer, click on Add. Your tiles will look something like the following image:

Note

Note the credit value in the lower-right corner of each tile.