At the end of my previous post on this topic, I left you with this map of the area around the mountain of Blaven (Gaelic Bla Bheinn) on the Isle of Skye:

That concluded a three-part tutorial on using Ordnance Survey OpenData products in QGIS mapping software. (To go to the start of the series, click here.) This post, as promised last time, will deal with adding data from other sources. It’s a bit of a grab-bag of ideas—I’ll mention a few useful data sources, and various ways of importing those data into QGIS, and also describe how to import or create your own map symbols.

The major deficiency with the OS’s OpenData, from the point of view of a hill-walker, is that it lacks any portrayal of mountain paths and tracks. Fortunately, there’s another open data source available which goes some way towards remedying that—the OpenStreetMap project. Their data are free to use under the Open Database License, which requires that they be suitably credited.

To get some path data for the map above, I go to the OpenStreetMap website, and then drag and zoom to reach the area around Blaven. Then I click on the Export button at top left of the web page, which brings up a dialogue box at the left side of the screen featuring a prominent blue button marked “Export”. Above that, you can see a grey box marked up with the latitude and longitude limits of the map view you’re looking at, and the option to “Manually Select A Different Area”:

I click on the “Manual Select” option, adjust the box to select only the area around Blaven that I’m interested in, and click Export. (Selecting too large an area will generate an error message.)

My data are downloadable in the form of a file named map.osm, which I can save under a more memorable name (like blaven.osm) to somewhere in my QGIS data folders. Then I load it as new layer using Layer/Add Layer/Add Vector Layer…. When I’m asked which vector layer I want to add, I select “lines”, which will contain the path data I’m looking for (as well as some other stuff).

We can take a look at the content of this layer by double-clicking on its name to bring up the Layer Properties dialogue and looking at “Source Fields”:

It looks like “highway” is going to be the field we want to process. Now I move to “Symbology” and set up some Rule-based filters to associate markers with only the “highway” values I’m interested in—which turn out to be ‘track’, ‘path’ and ‘footway’. Like this:

I’ve set up my OpenStreetMap tracks to match my definition for Ordnance Survey tracks, and selected a grey dashed line for paths. (For a detailed tutorial on how to set up rule-based filters, take a look at Part 3 of this series, where I used them to set up different label styles for different kinds of named place.)

Here’s the final result (note that I have now added the necessary credit to the OSM data compilers):

It’s actually a better portrayal of the paths on Blaven than appears on Ordnance Survey maps. That’s sometimes the case—OSM path data is extremely variable from place to place, depending as it does on the work of volunteers either walking the routes or plotting them from public domain aerial photographs.

Now I’m going to add some symbols, but first I want to slightly tweak the position of feature names on the map. Firstly, I want the mountain names to be offset from the peaks they label (to make room for symbols to be inserted later). I double-click on the “NamedPlaces” layer to bring up its Layer Properties dialogue box, select “Labels” and then double-click the “Landform” filter to open Edit Rule. In that dialogue I select “Placement”, and then change the label placement to “Around Point” with an offset of two typographical points. (In fact, I could produce a complicated rule applying different offsets for different sizes of text, in the same way I created different sizes of text in the first place, as described in Part 3—but this simple adjustment will do as an example.)

I’d also like to get rid of that giant “Strathaird” label on the map, which is just a distraction, given that it’s not clear what feature it is intended to label. I can do this by selecting the “NamedPlaces” layer, and activating editing by clicking on the little picture of a pencil among the array of icons at the top of the screen. Then I also click on the icon for “Select Features by area or single click”.

Here they are, circled in this screen capture:

Now I can just draw a box round the offending “Strathaird” (at which point the labelled location appears as a little red cross in a yellow square), and hit the Delete key to remove it. Then I can toggle off the little pencil icon, at which point I’m asked if I want to save the changes I’ve made. (Use this facility sparingly—you don’t want to remove labels that you might need in future.) Finally, a click on the little hand icon (just above and left of the pencil in my screen-grab) restores the usual function of the mouse cursor.

Here’s the final result:

The mountain names are all moved above and to the right of the peaks they label. An unwanted consequence is a shift in the labels naming the two corries—there are multiple ways to fix that, either by introducing new placement rules, or by using the layer editing facility to actually drag the labels around to where they’re wanted. But it’s not a big deal in this case, and I don’t want to get too bogged down in additional detail at this point.

So let’s just proceed to adding some symbols from an external dataset. I’ve downloaded the complete dataset of Ordnance Survey triangulation pillars in GPX format from haroldstreet.org.uk. QGIS will recognize the *.gpx file format, so we can add the data as a new layer using Layer/Add Layer/Add Vector Layer….

Once the layer is added, I want to produce a suitable symbol for the triangulation points it marks. I double-click on the layer name listed in the Layers window so as to open its Layer Properties dialogue, go to “Symbology”, and change the Simple Marker from the default circle to a triangle. I set the size to 15 points, making it roughly the same size as my text, and colour it blue and white to produce a match for the Ordnance Survey symbol for a trig point.

The OS symbol has a dot in the middle, and I can reproduce this by adding another layer to my symbol, using the green plus sign that appears on the left above the settings menu, and adding a blue dot of appropriate size on top of the triangle. Here’s the final result—a triangulation pillar on the summit of Blaven:

The website haroldstreet.org.uk provides a whole load of other useful data, including a large selection of hill summits from various lists. It also provides a dataset of mountain bothies. If you find it useful you should consider giving a donation for its up-keep—the option is offered each time you download a file.

Because QGIS understands the *.gpx format used by GPS receivers, we can also import routes, tracks and waypoints from GPS devices. Below, I’ve added some colour-coded summit markers from various hill lists, and superimposed the route recorded on my GPS when I ascended Blaven:

Now it would be nice to mark the car-park at the foot of Blaven, where the walk started and finished. There are various ways of doing this. The easiest, if you have a GPS receiver and are at the location, is to record a waypoint and then import the relevant file into QGIS.

Another possibility is to find the location on Google Earth, and mark it with a “placemark”—a little coloured map pin, generated using the map-pin icon at the top of the Google Earth screen. You can then export this placemark in the form of a *.kml file, by right-clicking on the location in the “Places” list at left of screen and choosing Save Place As….

The file produced uses KML (Keyhole Markup Language) which is another file format that QGIS can import as a vector layer. The terms of service for Google Earth certainly appear to give permission to do exactly this, in section 1b. But the point at which a few coordinates turn into a “derived dataset” (to which Google might object legally) is not clear to me, so I’m not going to use that approach here.

Instead, I’m going to use the old fashioned method of just looking at a map to get a set of coordinates. Checking the “Coordinates” panel at the bottom right of the QGIS display, while moving the cursor over the map location of my car park, tells me it’s located at 156064,821604. These values are given in the coordinate system for this QGIS project—which is, in fact, the standard Ordnance Survey system of eastings and northings, though probably not in an immediately familiar form. The values are given in metres, and use full numerical coordinates, rather than the familiar two-letter designator for each 100-kilometre square.

You can see the relationship between the two systems using a chart that shows the distance of each 100-kilometre square from the origin of the OS grid. So the NG square, which contains Blaven, is 100 kilometres east and 800 kilometres north. To specify a location within NG to the nearest metre, we therefore need a six-digit easting followed by a six-digit northing.

This full set of digits appears at all the corners of Ordnance Survey maps, though they go largely unnoticed. That means I can read coordinates suitable for QGIS directly from a paper map.

Taking a look at the relevant OS sheet for Blaven, I see that the car park is at NG 560216 (to the nearest 100m). So that is 1560,8216 in full numerical style (to the nearest 100m), or 156000,821600 if we add trailing zeroes to give a figure correct to the metre. Comparing this to the figure I pulled directly off QGIS (156064,821604) shows that everything is internally consistent. So I can take coordinates from a paper map and convert them to something QGIS understands. Or I can just read coordinates directly from QGIS itself.

But how do I get those figures into QGIS? I’m going to write a simple little text file of Comma Separated Values. Here it is, giving the data for the car park:

ID,Nature,X,Y,Orientation,Name
1,Carpark,156064,821604,,Blaven Car Park

The first line gives the names for each field in the dataset. ID is a unique identifier that I probably don’t really need in a tiny file like this, Nature contains information about the kind of feature I’m describing, X and Y give the coordinates of the feature, Orientation lets me specify a rotation for any label applied, and Name is … well, the name. All fields are separated by commas. The next line is the entry for my car park, using coordinates I’ve read off the QGIS map. Since I’m not interested in specifying an orientation I can leave that field blank—one comma follows immediately after another in that location.

Now I’ll add a couple more items to my list:

ID,Nature,X,Y,Orientation,Name
1,Carpark,156076,821610,,Car Park
2,Feature,153792,822358,30,Choire a’ Caise
3,Building,151379,819984,,Boat House

I save this as a text file, but with the suffix *.csv to specify its nature. Then I can load it into QGIS using Layer/Add Layer/Add Delimited Text Layer…, selecting Project CRS for the “Geometry CRS” option, and ticking “First record has field names”. You can see the little database that produces at the bottom of the Delimited Text dialogue box:

With the layer loaded, I can now set up filters and rules based on the content of the Nature field. Here, for instance, is the “Symbology” entry for the Layer Properties, showing how I’ve set up “Nature” filters. (I gave a detailed description of using this sort of rule-based labelling system in Part 3 of this series.)

I gave the car park its own symbol, I formatted Choire a’ Caise so that its text matched the other corries, and the Boat House so that it matched other buildings. Here’s the result, with the new features circled:

QGIS provides a good selection of different symbols, but I designed the car park symbol myself, to roughly match British road signs:

If you don’t fancy drawing your own symbols, you can usually find suitable Public Domain images, like this one on Wikimedia Commons.

Symbols need to be in *.svg (Scalable Vector Graphics) format. The Wikimedia symbol I linked to above already is, but if you’re faced with a *.jpg or *.png symbol (like the one I produced), then there are many free and easy-to-use conversion utilities on-line—I used this one. Once you’ve produced your *.svg file, copy it into a sub-folder of the QGIS program directory on your hard drive. For QGIS 3, the sub-folder is /apps/qgis/svg/, which contains a number of themed sub-folders. For lack of a better idea, I dropped my carpark.svg into the /symbols sub-folder. Once there, it became available to me when editing “Symbology”—by changing the “Symbol Layer Type” to SVG Marker, I was able to scroll down and find my new symbol amid the pre-existing selection.

Finally, I confess that an Ordnance Survey map always looks naked to me without a superimposed one-kilometre grid, which is also an aid to judging scale. Charles Roper has produced a Public Domain set of ESRI shape files for the Ordnance Survey grid. The main trick to using these grid files is to select “Transparent Fill” for the fill colour—otherwise you’ll just end up with an opaque tiling that obscures everything else! ( I dealt in detail with managing shape files in Part 1 and Part 2.)

So here’s the final map. There are still things that could be improved—for instance, the ability to edit layers in QGIS goes far beyond simply being able to delete unwanted labels, as I did above. But I hope I’ve shown you how easy it is to produce useful and attractive UK maps using only open data sources.

I finish my last post about using Ordnance Survey OpenData in QGIS having produced this map of the area around Blaven, on the Isle of Skye:

It’s tinted for height, shaded and marked up with contours to emphasize landforms, and has features such as surface water, coastline, roads and buildings added.

Now it needs some labels. If you’ve been following along with the previous posts, you’ve already downloaded the relevant ESRI vector data for OS grid square NG. The relevant shape file is NG_NamedPlace.shp, which is sitting in the directory OS OpenMap Local (ESRI Shape File) NG/data. Add it to the map by going through the top menu bar in QGIS, Layer/Add Layer/Add Vector Layer….

When the shape file is first loaded, you’ll just see an array of dots marking named locations, but with no names, which is a little disappointing. The Ordnance Survey actually provides a NamedPlace.qml stylesheet which will do some basic formatting for you (I discussed the use of OS stylesheets in my previous post), but I think it’s more useful to build the formatting a step at a time on this occasion, to introduce some of the more complicated things you can do with QGIS.

So before we do anything else, we need to turn on the names. To see how to do this, double-click on the NamedPlace layer in the Layers window to bring up its Layer Properties dialogue window. At left, choose “Source Fields” to see a list of all the attributes associated with NamedPlace entities. It looks like this:

Checking the OS OpenMap – Local Product Guide (1.7MB pdf)* we can find out what these attribute names mean:

ID is a unique identifier we don’t need to worry about
DISTNAME is the distinctive name of the place
HTMLNAME repeats the distinctive name, but using html control characters to deliver any accented letters—you might need to use this to display Welsh place names properly
CLASSIFICA is the classification of the named place—the rather limited options are Populated Place, Landform, Woodland Or Forest, Hydrography or Landcover
FONTHEIGHT gives a recommendation (Small, Medium or Large) for the size of label to be used, according to the size of the named feature
ORIENTATIO is the orientation of the label, measured in degrees from the horizontal, to align it with a linear feature
FEATCODE is a feature code number—in the case of named places, it simply provides one of five numerical codes according to the feature’s classification, so adds no new information

So we can use either DISTNAME or HTMLNAME to label our features, and CLASSIFICA, FONTHEIGHT and ORIENTATIO to determine what the label looks like.

So now click on “Labels” at the left of the Layer Properties dialogue window. Choose Single Labels from the drop-down dialogue box, and choose DISTNAME in the “Label with” dialogue that now appears. The “Text Sample” box shows you the size your labels will appear on the map. Provided that is a reasonable size (it should be, the default is 10-point lettering), leave everything else alone at present, and click Apply at lower right to see the result.

My display comes up looking like this, with lots of question marks where special characters should be:

I can fix this by selecting “Source” at the left of the Layer Properties dialogue window, and then changing “Data source encoding” to System.

Now it would be nice to label the five different classifications in five different ways. To do this, go the “Labels” section of the Layer Properties dialogue, and switch the drop-down menu at top to Rule-based Labeling. It comes up with a single unnamed default rule, which is to label everything with DISTNAME. Double-click on this rule to bring up the Edit Rule dialogue.

I want to label hydrographic features in blue. I type Hydrography into the “Description” box, to give my rule a name, and then set the “Filter” rule like this:

“CLASSIFICA” = ‘Hydrography’

It’s important to type the double quotes around the attribute name, the single quotes around the value you want to filter on, and get all the spelling and capitalization correct. The Test button to the right is useful, because it lets you check that your filter is actually working—I pick up 1916 hydrographic features with this filter, so all is well. I need to type DISTNAME into the “Label with” field, and then the whole lower half of the dialogue lets me configure my text, with multiple additional options available by clicking the various headings at left (“Text”, “Formatting”, “Buffer”, and so on). It’s informative to just play with these settings to see what happens, but at present I’ve just changed the “Color” option to blue.

I click on OK at bottom right when I’ve finished setting the text formatting, and that returns me to the rule-based labelling, with the Hydrography rule in place. Now I can add another rule by clicking the green plus sign at bottom left, and filling in a new filter and new text formatting, always remembering to fill the “Label with” field, too. (When my labels don’t appear, it’s usually because I’ve become so preoccupied with setting the rules and formatting, I’ve forgotten to specify the attribute to use for the label.)

Working my way through all five classifications, I end up with a set of rules that look like this:

Within those rules, I’ve set woodland labels to green, landcover to brown, water to blue, and used a different typeface to distinguish populated places and landforms. Only the last three of those actually show up in the area of my Blaven map:

You can do exactly the same thing under “Symbology”, by selecting Ruled-based from the drop-down menu at the top of the window, and then stipulating different markers for different classifications. But for now, I’m just going to make all the markers disappear, by moving the “Opacity” slider to 0% in “Symbology”.

Now I’d like to use FONTHEIGHT to specify larger labels on larger features. Here’s the Edit Rule window for Landforms:

Although it seems to allow only one size of typeface for each rule, the slightly mysterious icons arrayed down the right-hand side of this dialogue window allow me to define more attribute rules to determine each font setting. I Click on the icon next to “Size” (ringed in red above), select Edit…, and I’m presented with the Expression String Builder dialogue window.

it looks a bit daunting, but if I click on “Fields and Values”, I’m presented with a familiar list of the names of all the attributes associated with NamedPlace. Clicking on FONTHEIGHT brings up a window that can be used to display the values of that attribute. A click on the all unique button shows me all the different values that FONTHEIGHT contains:

I’d like to enter a set of conditions using the CASE … WHEN … THEN format. If I know the syntax, I can just type the code into the left-hand window. But if I need guidance, I can click on the “Conditional” option, select “CASE”, and see the syntax spelled out for me in the right-hand window.

Here’s what the window looks like after I’ve entered the necessary code to associate ‘Large’, ‘Medium’ and ‘Small’ features with 30, 20 and 10-point labels, respectively. The text below the left window will let you know if you’ve used the wrong syntax.

(Again, be sure to use double quotes on the attribute names and single quotes on the values, and to get all the capitalization correct.)

When I click on OK, QGIS lets me know that I’ve set up rules for font size by placing a little yellow icon containing an ε next to the “Size” text box. Any value in that box will now be overruled by the conditions I’ve programmed. While I’m in the Edit Rule window, I also set up some conditions for “Style”, by entering the following code in the Expression String Builder:

CASE
WHEN “FONTHEIGHT”=’Large’ THEN ‘Bold’
ELSE ‘Regular’
END

This should make my largest Landform labels appear in bold.

Finally, I centre the label over the Landform by calling up “Placement” in Edit Rule, clicking on the “Offset from point” radio button, and selecting the central placement from the grid of options presented. Like this:

And here’s the result when I apply that set of rules to my map labels:

It’s a bit shouty and needs some fine tuning, but you get the idea. Then it’s just a matter of going through the other four classifications, and tweaking them to achieve the effect you want—I’ve used some very simple rules, but a little experimentation will show you the wealth of configuration options you have at your fingertips.

Here’s what it looks like with a little more formatting:

For Hydrography I’ve used the “Formatting” options to set “Wrap on character” to a space, so that those long Gaelic names are stacked one word above the other.

Finally, we need to use the ORIENTATIO attribute to align the text labelling linear features. Going back to the Edit Rule window we can enter a rule for “Rotation” (down near the bottom of the “Placement” window). In the Expression String Builder I just type “ORIENTATIO” to set the text rotation to equal the Ordnance Survey’s orientation attribute. It seems to have no effect on any feature except Landforms, so that’s the only rule worth changing. But when I make the change, I get a disappointing result:

You can see that the names of the two corries below Blaven are orientated almost crosswise to the features they label. The problem is that QGIS changed the expected direction of its rotation angles in the transition from QGIS 2 to QGIS 3, and the OS’s dataset hasn’t changed to match that, at time of writing. But it’s easily fixed, once you understand the problem. Just put a minus sign in front of “ORIENTATIO” in the Expression String Builder for “Rotation”, and order is restored:

That’s it for this time. In my next post on this topic, I’ll add in some data from sources outside the Ordnance Survey.

• Go to the next post in this series

* Pages 52-57 provide information specific to the NamedPlace shape files.

So, by the end of my previous post on this topic, I’d used Ordnance Survey OpenData products in QGIS to produce a nice smooth depiction of the topography of Ordnance Survey grid square NG, tinted to show height and shaded to show relief. It looked like this:

A detail, showing the region around the mountain Blaven, on the Isle of Skye, looked like this:

The next step is to add some contour lines, to give an extra impression of the relief. Last time, I described how I’d downloaded the OS Terrain 50 vector dataset, in the form of ESRI files, and unzipped its data folder inside a folder on my hard drive named OS Terrain 50 (ESRI), so as to keep it separate from the Terrain 50 Grid dataset I used last time. This data folder contains a host of sub-folders with two-letter names, each of them corresponding to one of the OS’s 100km grid squares (shown at left), and each sub-folder containing a set of anything up to a hundred zip files of its own, each containing contour and spot-height data for a 10-kilometre square of terrain. Once these are unzipped, you find the contour data in files with “line” in their names, and the spot-height data in files with names containing the word “point”. There are multiple different files for each 10-kilometre square, but the important ones have the extension .shp—shape files. The rest contain supporting data that QGIS will handle automatically.

To get contours for the whole NG square, I loaded all the “line” shape files from the ng sub-folder. I find the easiest way to do this is to use the Browser window in QGIS to navigate to the appropriate folder, and then to enter “*line.shp” into the filter tool (brought up by clicking on the little picture of a filter funnel in the toolbar of the Browser window). This brings up a list of only the necessary files. I select all of them, right-click, and choose Add Selected Layer(s) to Canvas.

The result looks something like this:

It resembles some sort of mad quilting project, because QGIS has coloured the contours from each 10-kilometre square differently. We need to combine these into a single file, so that they can be consistently coloured. From the main toolbar, select Vector/Data Management Tools/Merge Vector Layers…. In “Input Layers” select the names of all the *line.shp files. For the “Destination CRS” choose the option that includes “OSGB36”, and under “Merged” provide a memorable name for the output file.

Once you have the new merged layer loaded, you can discard all the individual tiles from which it was derived. Now we just need to apply the default style from the OS’s cartographic stylesheets. Double-click on the name of the merged contour layer in the Layers window to bring up its Layer Properties dialogue box. Click on Style/Load Style at lower left of this dialogue. Navigate to the correct style definition file in the Terrain 50 stylesheets folder (I described how to create this last time). There are a lot of nested folders, but the file we want is OS-Terrain-50-stylesheets-master/ESRI Shapefile contour stylesheets/QGIS Stylesheets (QML)/line.qml. Once applied, the final result looks like this:

It’s a bit cluttered at this scale, because the Ordnance Survey style for contours is to plot them at a constant width, irrespective of scale, which makes sense. Zooming in on Blaven, we find things look more reasonable:

The OS contours include three classes—meanHighWater and meanLowWater, which appear along the coast and are tinted blue; and ordinary, which marks land elevations and which defaults to a rather garish russet. I toned this last one down a little by modifying its properties in the Layer Properties dialogue box, under “Symbology”, like this:

I’ve set it to a browner shade, and wound its opacity down to 50%. In general, I’ve tweaked most of the OS’s default styles to suit my own purposes and tastes. (By the way, you can label the contours with their heights by going to “Labels” in the Layers Property dialogue, replacing No Labels with Single Labels and then setting “Label With” to PROP_VALUE, which is the variable in which the dataset stores the height of each contour. I prefer to reduce the clutter and keep labels turned off—for the maps I’m making I just want the contours to indicate the shape of the landform.)

Now to add some more geographical features. The meanLowWater contour looks a little odd at present, sitting in the sea, but in the OpenMap – Local dataset (which I described downloading last time), the OS provides a shape file called *Foreshore.shp, which fills the space between high and low water. In this case the necessary file is NG_Foreshore.shp, which is stored in a folder called OS OpenMap Local (ESRI Shape File) NG/data, along with all the other shape files I’m going to be using in this post. You can add it as a layer using the main toolbar Layer/Add Layer/Add Vector Layer…, and then navigating to the right folder.

While we’re there, we can add surface water features, in the form of NG_SurfaceWater_Line.shp and NG_SurfaceWater_Area.shp. NG_Woodland.shp adds areas of forest. All of these will load with random colours assigned by QGIS, and need to have styles applied from the OS OpenMap – Local stylesheets, which I described downloading last time. The styles we want are installed to your hard drive in a folder called OS-OpenMap-Local-stylesheets-master/ESRI Shapefile stylesheets/QGIS stylesheets (QML)/Full colour style. They have descriptive names that match the shape files—Foreshore.qml and so on.

Here’s what Blaven looks like with those geographical features added, and after a little tweaking to the default OS styles:

It’s becoming important to have all these layers in the right order—you can see the order they’re stacked in in the Layers window, and you can drag them up and down the sequence to achieve the right effect. I have Foreshore sitting immediately on top of TidalWater, and just below the contour layer. SurfaceWater features are on top of the contour layer—I think rivers look better without contours crossing them. Woodland has had special treatment. I’ve turned its opacity down to 30%, so the topographic tints can show through slightly, and slipped it below the Hillshade layer, so the forest areas look like they’re following the slope of the land.

With the natural environment properly depicted, I’m now going to add NG_Building.shp and NG_Road.shp. Again, these can be styled from the OS stylesheet, and then tweaked according to taste. But there’s a twist with the styles for roads. Not only does the road style file contain multiple different styles according to whether we’re dealing with a motorway, an A-road or a track, there are actually three separate style files for roads—RoadCase.qml, RoadFill.qml and RoadCentreLine.qml. These are designed to stack one on top of the other, as three separate layers, producing (respectively) a dark edge, a coloured middle, and any centre line required to symbolize dual carriageways. All of them use exactly the same shape file. So, having loaded NG_Road.shp, right-click on its name in the Layers window, and select Duplicate Layer. Then do the same again. Now you have three copies of the Roads layer. Right-click on each, choose Rename Layer, and give it a name corresponding to the style you’re going to apply. Then add the OS styles. Here’s the order everything should appear in in the Layers window:

And here’s how it all looks after I’ve slightly tweaked the OS styles:

There are other features in the OpenMap – Local shape dataset, but none of them are relevant to the image I’m working on here. You can add roundabouts (two styles are provided, one for the dark outline and one for a coloured fill, so the layer needs to be duplicated). There are railway tracks, railway stations, and road and rail tunnels, all of which are necessary when producing maps of other areas. (The depicted railway tracks are broken where they pass under bridges, so you should put the railway layer on top of your road layers.) A number of other more specialized features are also available—take a look at the Ordnance Survey’s OpenMap – Local product guide (1.7MB pdf) for more detail.

Next time, I’m going to write about how to add and format place names.

• Go to the next post in this series

Recently, I’ve been preparing my UK walking maps using the Ordnance Survey’s free OpenData products, which I’ve rendered into maps using a free, open-source Geographical Information System, QGIS. I thought I’d write a little bit about that, now that I’ve got my maps looking more or less as I’d like them. For this first part, I’m going to write about using one of the OS’s free topographic datasets. Later posts will deal with adding features like contours, rivers, lakes and roads, and with adding custom data.

First, of course, you need to install QGIS. I’ve been using version 3, which at time of writing is the latest. With that done, you then need some OS data. I downloaded the ASCII grid and ESRI contours from their Terrain 50 dataset, which provides elevation data at 50m horizontal resolution. The “Grid” format provides raster elevation data—lots of cells in a square grid, each containing a number representing the elevation in metres above sea level for that location. The “Contours” format provides a vector dataset, full of “shape files”—properly interpreted by QGIS, they’ll draw contour lines and spot heights for you. I’ll use only the Grid data for this post, though I’ll be using the ESRI version of Contours later.

These downloads need to be unzipped, at which point they each produce a folder called data, full of subfolders lettered according to the OS’s 100-km grid system. To keep the Grid and Contour data separate, I unzipped them to separate folders named OS Terrain 50 (Grid) and OS Terrain 50 (ESRI). Annoyingly, each lettered grid folder contains a multitude of zipped files—anything up to a hundred, each representing a 10-km square tile of topographic data. QGIS can actually peer inside these zipped files and load tile data directly, but I find it easier to deal with multiple tiles if I do a mass unzipping for each lettered grid square that interests me, and then clear away the zip files.

Features like rivers, lakes, woodlands and buildings are added using more datasets. I’ve been using the Open Map – Local ESRI shape files. These are downloaded in packages that cover a single grid square. For my examples here I’m going to use data from the NG square. Downloaded and unzipped, that produces a folder called OS Open Map Local (ESRI Shape File) NG. (Round about this point, I started stuffing all my data folders inside one big folder called OS Data, to make them easier to find.)

The OS also provides a variety of stylesheets—instructions that tell your GIS software how to display your data. These used to be readily accessible on the OS’s own website, but now (as reported in the Comments section below) they’re rather obscurely located on the GitHub developers’ site. Here are direct links to the two stylesheets required: Open Map – Local and Terrain50. Clicking on these links will download a couple of zipped files, and unzipping those will generate another couple of folders on your hard drive called OS-Terrain-50-stylesheets-master and OS-OpenMap-Local-stylesheets-master. Into the OS Data folder they go.

With all that in place, we can open QGIS 3 and start producing a map. QGIS opens with a load of menu items and toolbars across the top, a “Browser” window at upper left, which allows you to navigate to and load data files, and a “Layers” window at lower left, which keeps track of the various layers you’re putting together to create your map. The rest of the screen will hold the map itself. Navigating to the ng subfolder of my Terrain 50 Grid data (having first unzipped all its files), I find an eyewatering array of files with different names and extensions. I want to load all the files with extension .asc, and I can call them up using the filter tool (shaped like a little funnel) in the Browser window toolbar, and typing *.asc as my filter criterion. Then I select all the .asc files, right-click and select Add Selected Layer(s) to Canvas.

This is what appears in the map window:

All the 10-km tiles containing elevation data have been loaded, and colour-coded by height, from black at the lowest to white at the highest point of each tile. The white squares are areas of no data, containing only sea. If you know your Scottish islands, it’s possible to make out the distinctive shape of the Isle of Skye, but it’s all a bit of a mess because each tile has been tinted individually.

The first thing to do is to merge all the tiles into one big square, so they can be tinted consistently. We can do that from the top menu, Raster/Miscellaneous/Merge…. For “Input Layers”, select all the tiles. Under “Merged”, save the merged data as a file with a descriptive name you can find later. I also nominate a specific “no data” value for the output, setting it to -100, so QGIS knows which areas of the merged file to make transparent.

Here’s what the merged version looks like:

Now it could do with a bit of colour. Double-click on the name of the layer in the “Layers” window, to open the Layer Properties dialogue box. (Choose the “Symbology” view if QGIS doesn’t take you there by default.) Switch the “Render type” to Singleband pseudocolor, and QGIS will offer you a colour ramp—a series of colours that can be used to code the height data on the map. QGIS has a wide variety of built-in ramps, but they’re hidden away. Drop down the menu for “Color ramp”, choose Create New Color Ramp… and drop down the menu in the dialogue box that follows. Catalog: cpt-city contains all sorts of useful stuff.

I made my own ramp, based on the height tints of the classic OS tourist maps of the 1970s, and saved it (using the Style button at lower left) so I could reuse it. Here’s the set-up for the ramp:

And here’s what the map looks like with my colour ramp applied:

No sea colour, but that’s deliberate. Zero height in the topographic data doesn’t correspond precisely to the coastline, and the OS provides a set of tiles in Open Map – Local that will lay a precise coastline on to my topo map. From the QGIS menu, Layer/Add Layer…/Add Vector Layer… brings up a dialogue box that lets you browse to the directory in which the ESRI shape files are stored—in my case, OS Open Map Local (ESRI Shape File) NG/data is the file I’m after . Adding that as a layer on top of the topographic data produces this:

Lovely coastline, shame about the colour, which has been assigned at random by QGIS. Time to use an OS stylesheet. Double-click on the new TidalWater layer to open its Layer Properties dialogue, go to “Symbology”, and use the button at lower left to open Style/Load Style. Navigate to the Open Map – Local stylesheets—in my case exhaustingly named OS-OpenMap-Local-stylesheets-master/ESRI Shapefile stylesheets/QGIS stylesheets (QML)/Full colour style. Load TidalWater.qml. Presto! Now the sea is sea-coloured, and all those tile margins have disappeared:

The awkward white boxes can be eliminated by setting the background colour of the project to the same shade as the OS’s tidal water. Project/Properties… takes you to the dialogue box. Drop down the menu for “Background colour”—Pick Color will give you a little paint-dropper pointer that you can use to copy the tidal water colour off the map by clicking on it. The result looks like this:

Starting to look pretty good, isn’t it? *

Adding a little shading will produce a more three-dimensional effect. Choose Raster/Analysis/Hillshade…. In the dialogue box, choose your topographic layer as the “Input layer”, and assign a filename to save the Hillshade result. The default settings work fine for everything else. Here’s what the hillshade layer looks like when it’s loaded on top of the topographic layer, but below the TidalWater tiles:

Very pretty, but it would be nice to see the topo colours, too. Double-click on the hillshade layer to bring up its Layer Properties dialogue, choose “Transparency”, and fiddle with the “Global opacity” slider. I find an opacity of 20% looks nice:

There’s a problem, though. If you want to use these maps at large scale, you come up against the limited horizontal resolution of 50m imposed by the Ordnance Survey on its free products. Here’s what the mountain Blaven, on the Isle of Skye, looks like if we zoom in on the map above:

Click or tap to enlarge the above view, and it’s glaringly obvious that the 50m squares are showing up intrusively in the map tint and shading.

Since I’m not particularly concerned with the accuracy of the height data, only in using them to generate a nice tint and shade to demonstrate the general topography, I’m happy to run an interpolation to increase the horizontal resolution and produce a smoother effect. I do that from Raster/Projections/Warp (Reproject)…. Here’s the dialogue box completed and ready to start rendering:

I’m not interested in changing the Coordinate Reference System (CRS) of my map—it stays the same (OSGB36). All I’m doing is changing the horizontal resolution to 10m. A bit of experimentation has shown me that using the Cubic spline resampling method produces the most pleasant-looking results. Here’s what I end up with, after producing the 10m-resolution layer and repeating the production of the hillshade layer, as described above:

That’s better! In my next post on this topic, I’ll add some contours and other features.

• Go to the next post in this series

* The sea colour cover isn’t perfect—depending on your graphics card, you may see occasional seams around tile margins when the view is zoomed out. I have some solutions to this, which I may write about another time.