Last time, I finished working on my Alaska map with political boundaries and shading in place, and the major rivers and lakes depicted. This time, I’m going to use some more Natural Earth data to add more information to the map.
The first thing I want is some towns and villages, so I download the Natural Earth “Populated Places” vector dataset from the “Cultural” section of the download page, unzip it into my default directory, and clip it down to just my area of interest, as I’ve described in previous posts. But there’s an important consideration during the clipping process, this time. Northern Iñupiat placenames use a special “dotted g” (ġ) character, which I’ll lose if I don’t make sure that the clipped file is saved with an appropriate character set. So I process this one individually, which lets me set the character set of the clipped file. Having gone through Vector>Geoprocessing Tools>Clip…, I set “Input layer” to ne_10m_populate_places.shp (the original Natural Earth file), and “Overlay layer” to the clipping mask I saved in Part 1. Then I click on the […] button to the right of the “Clipped” text box, choose “Save to File…” and call my clipped file alaska_ne_10m_populated_places.shp, consistent with my other clipped files. But then I click on […] again, and select “Change File Encoding” which will let me choose from a huge array of potential character sets. I make sure to set this to UTF-8, which will retain any special Inuit characters in the original dataset, and then click the Run button. After all that, I can load the shape file as a new vector layer, and start formatting the way towns and other settlements are displayed.
Click to enlarge
There are a lot of very small settlements in Alaska, and I want to give some indication of the largest population centres. So I double-click on my alaska_ne_10m_populate_places layer to bring up the Layer Properties dialogue box, and set up some rule-based symbology, as previously described. After poking around in the very large number of data fields supplied by Natural Earth, I establish that POP_MAX contains the numbers I want, and set up two sets of symbols—a large marker that corresponds to populated places that match the rule:
“POP_MAX” >20000
and a smaller marker for:
“POP_MAX” <=20000
To label these points I can just use the NAME field, but I’m going to do something more complicated. Natural Earth stores some alternative placenames in a field called NAMEPAR, so I want to set up a rule-based label that will add the alternative name in brackets if one exists—so I can display Iñupiat and English placenames side by side, for historical interest.
I test for the absence of an alternative name with the rule:
“NAMEPAR” is NULL
If this is true, I just label with the NAME field. But then I set up the handy rule ELSE, which will be true only if there’s something worth printing in the NAMEPAR field.
Now I need to find a way to combine the contents of two dataset fields (NAME and NAMEPAR), along with some additional text, into a single label. In the Edit Rule window, there’s a button labelled with a little epsilon (ε) next to the “text box in which you enter the name of the data field to be used for labels”Value” text box for Labels. I’ve marked it with the mouse cursor in the screenshot below:
Click to enlarge
If I click on this, I can combine fields into one label, using QGIS’s string concatenation operator “||”. This is available on one of a row of buttons featuring common operators (additions, subtraction, etc) at lower left of the Expression Dialog window, or you can type it from the keyboard by entering the “vertical bar” character twice. Again, I’ve marked the button with the mouse cursor, below:
Click to enlarge
As you can see from my screenshots, my method of combining fields looks like this:
“NAME” || ‘ (‘ || “NAMEPAR” || ‘)’
Disappointingly, it turns out there’s only one place on my map that has an alternative name listed by Natural Earth. Here it is, showing the effect of my string-concatenation rule (as well as showing that I’ve properly carried over the dotted-g character into my clipped dataset):
Here’s a screenshot of the label rules in final form:
Click to enlarge
But there’s a problem. Despite all this effort, when I plot my map some of my populated places don’t have labels. (Notice, for instance, the two unlabelled settlements on the Mackenzie River between Fort McPherson and Norman Wells.)
It seems that my label text is fighting for space with some of the other features on the map, particularly rivers. I find I can fix this problem by editing the “Placement” option for label text. Right at the bottom of this set of options, there’s a check-box labelled “Features act as obstacles”. Turning this off makes QGIS more willing to overwrite other map features. I disable this both for populated places and for rivers, and QGIS then manages to accommodate (almost) all my labels. Again, the location of the relevant check-box is marked with the mouse cursor, below:
Click to enlarge
To finish off this post, I’ll add roads and railways, which are available as cultural vector datasets. Each comes with a North American supplement, and the supplementary roads dataset is very useful for showing the extensive unpaved Alaskan road system. I download the files, unzip them, clip them, and add them as new layers.
Adding railways is easy—there’s even a nice pre-formatted “railway” symbol in the Layer Properties window, though I tweaked the thickness of the line and width of the crossbars for visibility.
Click to enlarge
The two road datasets are complementary, to some extent. The main file is better at showing ferry routes (which I don’t particularly want). The North American supplement is better for minor roads (which I do want). So I went with just the supplemental dataset for this project. It stores a useful road classification in a field called type. So I set up Symbology rules to mark Primary and Secondary roads with a thick red line, minor paved roads with a thin red line, and unpaved roads with a black dashed line, like this:
Last time, I described how I used free Natural Earth data and the software package QGIS to produce a basic map of Alaska and its surroundings, shown above.
This time, I’m going to lay some more vector datasets on top of this map to make it a little more useful. First, I want to add political boundaries, using some vector data I downloaded previously: Admin 0 – Countries, Admin 0 – Boundary Lines, and Admin 1 – States, Provinces from Natural Earth’s Cultural Vectors page. In my last post, I described how I’d unzipped all these files into the same folder on my hard-drive, and then batch-processed them to clip away all the data I didn’t need.
First of all, I go through Layer>Add Layer…>Add Vector Layer… in the top menu, and navigate to the directory containing my clipped files, to which I added the prefix alaska_ during processing, last time. The original Natural Earth shape file was ne_10m_admin_0_countries.shp, so I’m opening alaska_ne_10m_admin_0_countries.shp. This dumps a set of opaque polygons of uniform colour on top of my nice shaded-relief map.
We can see the international boundary between Alaska and Canada, and also an ugly seam running along the 180° meridian across the Russian Chukchi peninsula and Wrangel Island. To get rid of this artefact, I can adopt the same strategy I used when I encounter the 180° seam in the ocean—set the polygon colours and borders to the same shade. But first I need to find a way to colour the USA, Canada and Russia in different shades.
I do this by double-clicking on the countries layer in the “Layers” window, to the left of the map window, to bring up the Layer Properties dialogue, and then selecting Symbology from the options at the left of that box. From the drop-down box at the head of the dialogue window, I select “Rule-based”. This brings up a default, blank rule for shading the country polygons, marked “no filter”.
By double-clicking on that “empty” rule, I bring up the Edit Rule dialogue, which is where most of the action is going to be happening as I add further layers. I’m going to call my rule “Russia”. I change the colour for this country to a pale pink, and set its transparency to 50%, so that my shaded relief will show through.
Click to enlarge
To make sure the border is the same colour as the rest of the country, I click on Simple Fill to bring up some more polygon properties, which lets me change “Stroke Color” to match “Fill Color”.
But I still need to define the rule by which QGIS can identify which polygon is Russia, and shade it accordingly. So I click on the button marked with a little curly epsilon (ε) character, next to the “Filter” text box.
Another dialogue opens up, the Expression String Builder. Here, I can access the various data fields attached to each Natural Earth polygon. In the centre panel I click on “Fields and Values” to drop down a list of all the data fields that are associated with the Natural Earth country polygons. “SOVEREIGNT” looks promising, and I confirm this by clicking on the All Unique button, which shows me that my clipped country file contains polygons linked to Russia, USA, Canada, and Denmark (I included a corner of Greenland when I trimmed the file).
Click to enlarge
Now to create my filter rule, I can double-click on “SOVEREIGNT”, type an equals sign, and then double-click on “Russia”. This creates an expression in the left panel that looks like this:
“SOVEREIGNT” = ‘Russia’
It’s easy enough to type this sort of stuff in yourself, but notice that the field name needs to be enclosed in double quotes, while the field value is in single quotes.
Clicking on OK a couple of times gets me back to the Layer Properties dialogue, with my new rule in place. I can now repeat this process to create additional rules, assigning colours to the USA and Canada—clicking on the little green cross at bottom left brings up a new Edit Rule dialogue. Here’s the final set of rules:
I’d like to emphasize the country borders and the coastline a little more, as well as showing provincial borders in Canada, so I add three more layers, using files I downloaded and clipped last time: alaska_ne_10m_coastline.shp, alaska_ne_10m_admin_0_countries.shp, and alaska_ne_10m_admin_1_states_provinces_lines.shp. By opening the Layer Properties dialogue and editing Symbology, I can assign suitable colours and widths to each of these. I also want to see only Canadian internal boundaries, so I can set up a rule-based symbology for that file like this:
Now I’d like to add some more detail. So I download “rivers and lake centerlines” and “lakes & reservoirs” from Natural Earth’s physical vectors page, unzip, them into my master directory, and clip them down to my area of interest using the process I described in Part 1. Once the *.shp files are added as new layers, and their symbology edited for colour, my map looks like this:
(The lakes layer needs to go on top of the rivers layer.) I’m not entirely happy with the depiction of the Mackenzie River delta, which is notoriously complicated, and a bit under-represented in Natural Earth’s basic dataset. So I download the “North America supplement” for rivers, clip it, and add it as another layer. This turns out to add far too much detail for this scale of map, and I’m really only interested in enhancing the appearance of the Mackenzie Delta, so (after poking around to discover the correct field names) I set up a rule-based symbology:
“name” = ‘Mackenzie‘
This excludes all the other rivers and draws only those that have been labelled as belonging to the Mackenzie. Here’s a before-and-after to show the effect of the extra data:
It would be nice to add names to the rivers, and these can be turned on by going through the Layer Properties dialogue and selecting Labels from the choices at left. First, I use the “Value” drop-down box at the top of the dialogue to look at a list of all the data fields Natural Earth has associated with the rivers, and select the option “name”. (In the hurry to configure all the other options available, I often forget to choose the “Value” entry, and end up with no labels at all.) Then, under “Text”, I can select a nice text colour, and, under “Placement”, choose how the labels align with the river courses—I chose “Parallel”. But there’s a problem when I apply these edits—some of the river names appear twice, with one of the names superimposed on a lake. This is because (as the name implies) the “rivers and lake centerlines” dataset also includes segments that mark the centre-lines of lakes—so there’s a river labelled “Mackenzie”, but a lake centre-line with the same label, and that label turns up annoyingly superimposed on Great Slave Lake.
Time for some rule-based labelling. The data field “featurcla” tells us whether a given feature is a river or a lake centre-line, so I can set my labels to appear only when
“featurecla” = ‘River’
Click to enlarge
Finally, I’d like to label some of the larger lakes, without cluttering the map with names on every lake. The Natural Earth dataset helpfully includes a field called “scalerank”, which classifies features by their approximate size, and a bit of experimentation reveals that I can get the effect I want using rule-based labels with
“scalerank” BETWEEN 0 and 2
Which demonstrates that we can do all sorts of logical tests on fields to get the desired result. More on that next time, when I’ll add some artificial features like roads and settlements.
A while ago, I wrote about my experience using Ordnance Survey data to generate maps of the UK using the free and open-source Geographical Information System package QGIS 3. At that time I was using the then-current Long-Term Release, QGIS 3.4. Things have moved on, though, and this report uses the current QGIS LTR, version 3.28.
If you hang about this blog much, you’ll have noticed that there are a lot of maps. My UK maps are all generated using QGIS, but my world maps are a bit of a mix-and-match set drawn from various public domain sources, prominently Ian Macky’s excellent Portable ATlas site.
But (you’ll also have noticed) I do like making my own maps, and it’s been on my to-do list for a while, to make use of the free and well-curated data resources provided by Natural Earth.
So that’s what this is about. My project is to generate a map of Alaska, for reasons that will become obvious in another post, but what I write about here will be applicable to other mapping projects, too.
The Natural Earth download page provides data suitable for three different scales—1:10 million, 1:50 million and 1:110 million. My Alaska project realistically would be fine with the 1:50 million scale, but I’ll be using the 1:10 million dataset because I have other larger scale projects in mind for later.
For the base layer of my map, I download a 1:10 million shaded relief raster image—specifically their “Gray Earth with Shaded Relief, Hypsography, and Flat Water”. This comes as a zip file, which I unzip into a suitable new folder on my hard-drive. The data are in an image file called GRAY_HR_SR.tif, which I can open in QGIS using the menu bar at the top of the screen: Layer>Add Layer>Add Raster Layer…, and then navigating to the file.
This is a pretty thing, but if we zoom in on Alaska there are two problems—Alaska is stretched out from west to east, and the nearby Chukchi Peninsula in Russia is truncated by the edge of the map.
So I need to find a more suitable map projection. I can do this from the menu bar again: Raster>Projections>Warp (Reproject)…, which brings up a dialogue box. The “Input layer” should be the name of my raster image (in this case, GRAY_HR_SR), and the “Source CRS” (Coordinate Reference System) is just the default reference system established as the Project CRS when I open the tif file. I also want to save the generated projection for later use, so I skip down to the “Reprojected” text box, click on the button marked with […] to tell the program I want to save a file, and enter a suitable name.
Immediately below the “Reprojected” text box, I’ve unchecked the little box labelled “Open output file after running algorithm”. (Leaving this ticked means that QGIS will load my newly-created reprojected map, but will undo the reprojection, forcing it to conform to the original Project CRS.)
To find the correct entry for “Target CRS”, I have to click on the little globe to the right of that drop-down box, which opens a new dialogue. Under “Select CRS” I choose “Predefine CRS”, and that gives me access to the huge number of map projections QGIS knows about. If I type “Alaska” into the “Filter” box, I can find projections suitable for Alaska, and I choose NAD83(NSR2007)/Alaska Albers. Hitting the Run button at the bottom of the window then starts the reprojection process running.
That takes a while. After it completes, I can open a new project from the menu bar (Project>New), and load my reprojected map:
QGIS has reprojected the whole world, but it’s extremely distorted in regions that aren’t at Alaska’s high latitude. If I zoom in on Alaska, I can see that there’s been a good result there, and that the two edges of the original map have been brought together seamlessly to complete the Chukchi Peninsula:
But the rest of the distorted world map is of no use to me, so I’d like to crop out just the area that interests me, above. I do this by right-clicking on the file name in the “Layers” panel at the left of the interface, and then choosing Export>Save As… from the pop-up menu. This brings up a dialogue box in which I enter the name under which I want to save my cropped file, and then click on the Map Canvas Extent button to stipulate that I want to save just the area I’ve made visible on the screen. Keeping the tick in the “Add saved file to map” check-box ensures that my cropped file is loaded on top of the original, once processing is finished. Then I hit OK to create the new file.
Once the export is finished, the new layer appears in the “Layers” window, though the display doesn’t change much. I can now right-click on the original map layer, and dispose of it by selecting Remove Layer…, leaving just my new, cropped layer on display.
This is (at last) the base layer for my new “Alaska” project. I right-click on its name in the “Layers” panel, and choose Layer CRS…>Set Project CRS from Layer, and then save my new project from the top menu bar with Project>Save.
Now I want to lay some of Natural Earth’s vector mapping on top of this. Initially, I downloaded Admin 0 – Countries, Admin 0 – Boundary Lines, and Admin 1 – States, Provinces from their Cultural Vectors page, and Coastline and Ocean from Physical Vectors. All of these are provided as zip files, which I unzipped into a new folder on my hard drive. (Although I was tempted to give each set of files their own folder, they’re easier to batch process later if all the shape files are grouped together.)
QGIS will happily reproject all these files to match the Project CRS when I lay them on top of my Alaska base map. But (as with my raster map), I’d like to clip out just the area around Alaska before I start using them. I can do that using a batch process, but first I need to make a small adjustment to QGIS’s settings. Some of the Natural Earth files are, at time of writing, slightly badly behaved—their geometry contains tiny overlaps that are more or less invisible, but which will be detected and rejected during processing by QGIS. The ideal solution would be to fix these geometries, but that’s a whole other tutorial. So instead I’ll ask QGIS to ignore the problem. I go to the top menu and select Settings>Options…. In the dialogue box that appears, I scroll down the options in the left panel to click on Processing near the bottom, choose General, and set Invalid features filtering to Do not filter (better performance).
There are various ways to do the clipping I want. This time I’m going to create a mask layer, which tells QGIS which bits of the map I want to keep, and which I want rid of.
First I go through Project>New to open a temporary project in which I can generate my mask. Then to provide a reference I load one of my new vector world maps. Layer>Add Layer>Add Vector Layer…, and then navigate to my vectors folder. The files I want are the *.shp files, and I load ne_10m_admin_0_countries.shp, which brings up a world map tiled with all the various countries.
Now I create an overlying layer for my mask.Layer>Create Layer>New Shapefile Layer…. In the dialogue box that appears, I give the new layer a suitable filename and set “Geometry Type” to polygon.
Once my layer has been created, I make it editable by clicking on the little pencil icon in one of the top menu bars, and then on the green “Add Polygon Feature” icon a short distance to its right.
Now I can use the cursor to create a polygon, left-clicking in each place I want a vertex, and then right-clicking to end the process. A little dialogue box pops up, and I accept its default setting, and now I have my mask layer superimposed on the countries map.
To make sure this mask is saved to disk, I right-click on my mask layer in the “Layers” window at left of screen, and choose Save Layer Edits.
Project>New again clears the decks to run the batch process in which I clip all my new vector maps according to the mask layer I’ve just created. Vector>Geoprocessing Tools>Clip…, and then click on the Run as Batch Process… button at bottom left of the dialogue box. This brings up a new dialogue, containing three columns headed “Input Layer” (the files I want to clip), “Overlay Layer” (my newly created mask layer), and “Clipped” (the new files I want to create, containing just the vicinity of Alaska). Each column is headed with an Autofill… button, which is used to populate the three file lists. (A powerful but mildly counterintuitive tool.)
The first thing I do is to tug at the margins of the first two columns, sliding them to the right so that I can read the filenames I’m about to insert. For the first column, I choose the Select Files… option from Autofill, and select my five vector *.shp files. In the second column, I click on the […] button of the first row, and then Select File…. The file to select is the *.shp file for my Alaska mask. Once this is entered in the first row of the second column, I can copy it into the other rows with Autofill…>Fill Down.
The last column is where things get a little counterintuitive. I click on […] in the first row again, and in the “Save as type” textbox choose *.shp. But under “File name” I don’t enter a full filename, but just a prefix—I want all my newly generate clipped files to be prefixed “alaska_”, so that’s what I type into that text box. When I hit Save a little dialogue box appears, offering me autofill options. I choose Fill with parameter values, and leave the default parameter to use as Input Layer.
And (presto!) the “Clipped” column is populated with filenames echoing the original but prefixed “alaska_”.
Click to enlarge
Hitting Run will throw up some error messages about absent spatial indices which aren’t a big problem for this project, and our five clipped Alaska files are generated.
Time to open my original project, and add the ocean layer to mask off the dark grey sea. Here it is, zoomed back a bit to show that I’ve successfully trimmed off the rest of the world.
There’s an unfortunate seam at 180 degrees longitude, but I can fix that by double-clicking on the ocean layer in the “Layers” window, to bring up the Layer Properties dialogue box. Under Symbology, I click on Simple Fill, and set both “Fill color” and “Stroke color” to a nice shade of oceanic blue, using the little down arrows at the right of each drop-down box.
A shorter version of this post was published on 11 October 2017.
There are some things I hate about “in-flight” models of piston-engine aircraft. One is when the aircraft appear to be flying without a pilot; the other is a stationary propeller.
Modellers have a couple of ways of dealing with this second problem. One is to simply remove the propeller blades, leaving only the filled and smoothed spinner visible—it’s a well-recognized technique which many feel produces the most realistic appearance. But it always makes me think, Where’s the propeller? I find the complete absence of anything in the space where the propeller should be is a little distracting. I’m also not very keen on the photo-etched “prop-blur” option, which aims to produce a blurred sector for each prop blade, reproducing what we see in photos and movies, but not what we see with the naked eye.
So what I want to see is a transparent disc of the correct propeller colour(s), with the colour density at each radius matching the relative amount of prop blade and empty space at that radius. Like this:
Click to enlarge
Years ago, I posted a short tutorial about this on WW2Aircraft.net; and shortly after I started this blog, I put up a slightly revised version. But it was light on detail—so now this is the extensively revised, expanded and updated version.
I appreciate that some people can’t be bothered doing all the measuring and editing I’ll describe below, which is intended to produce a prop disc that matches the specific measurements of the propeller. If you’re such a person, I encourage you to skip past the measurement and mathematics and read the start of the section about creating a GIMP gradient. Once you’ve seen how I create a gradient of the correct colour, skip ahead to the section on using that gradient to draw the prop disc, and follow on from there. (To skip the first dose of maths, follow this link.)
The first thing I do is to measure the radius of my kit propeller, and then divide it into eight equal sections, from boss to tip, marking off the divisions with a felt-tip pen. Here, I’m marking up two different kinds of propeller for a Blohm & Voss 138 seaplane:
Click to enlarge
Then I measure the propeller blade width at each of my marked locations. To calculate what proportion of the prop disc is occupied by prop blades at each of my eight points along the radius of the propeller, I first work out the radius at each marked distance, which is just the radius of the propeller multiplied by the number of eighths—the first mark on my 24mm propeller is at 3mm, the next at 6mm, and so on. Then I multiply each of those distances by 2π to derive the local circumference. To find out how much of that circumference is occupied by propeller blades, I take the measured width of a propeller blade at that distance, and multiply by the number of blades. Dividing this length by the total circumference tells me what proportion of the prop disc is occupied by propeller blades.
I use a little Excel spreadsheet to do the calculations for me:
The first column is the number of eighths, measured from the hub of the propeller. The second column converts this to a radial distance. In the third column I’ve entered my measured blade widths, and the fourth column does the maths—multiplying the local blade width by the number of blades, and dividing by 2π times the local radius. You’ll see these numbers turn out to be relatively small, and I find that discs printed with opacities to match are fairly unimpressive, visually—primarily because you can see through even a “zero transparency” layer of ink. So in the fifth column I take the highest number in the fourth column, and express all my numbers as a proportion of that. These are the numbers I’m going to feed to my printer, with 100% representing maximum opacity printing, and 0% full transparency.
I also need to specify a colour for my prop disc. The BV 138 aircraft I’m modelling would have had propellers painted in Luftwaffe Schwarzgrün, which was coded RLM70. I can use the handy digital colour charts created by William Marshall, available here, to discover that RLM70 translates into RGB values of 56/62/50.
So now I’m ready to create my prop disc in a graphics program. I’m going to use GIMP, which has all the tools I need. You can download it here, for Linux, Apple or Windows. (My screenshots and menu sequences below are from version 2.10.)
After opening GIMP, I go through Windows/Dockable Dialogs/Gradients, which brings up a list of GIMP’s built-in colour gradients. I right-click on the list, and choose New Gradient. This gives me a simple colour gradient, from black to white, ready to be edited. Here, I’ve renamed it “BV 138 three-blade prop”, and I’m ready to edit:
First, I tell GIMP my chosen colour, by right-clicking on the gradient and selecting Left Endpoint’s Color…, which brings up a colour dialogue box. All I’m interested in setting are the R, G and B values, for my colour, and the A value (for opacity). But first I need to ensure I’m using the right scale—the figures given by Marshall are based on a range of zero to 255, so I need to click on the 0..255 button before I start entering numbers. Then I set R equal to 56, G to 62 and B to 50, leaving A with its default value of 255 (that is, completely opaque). Here’s what that looks like:
Then I go through the same process with Right Endpoint’s Color…, except setting A to zero, for full transparency. So now I have a colour gradient that is RLM70 throughout, fading from complete opacity to complete transparency. That would actually produce a pretty convincing prop disc, just as it stands, but I can make it more physical accurate by adding the opacity profile I derived from my little spreadsheet. (To skip that detail and go straight to instructions on how to draw the prop disc using a gradient, follow this link.)
To give the gradient a more realistic opacity profile, I need to split my colour gradient into eight equal parts, to match the eight measurements I made above. That’s easy to do. I right-click on the gradient again, and click Split Segment at Midpoint—now I have three little black triangles at the base of my gradient, splitting it into two segments, and two white triangles marking the midpoints of these segments. (These triangles can be dragged around to modify the gradient, but they can stay right where they are at present.) Right-clicking again produces Split Segments at Midpoints, and creates four segments; and again, and I have the eight segments I need. Clicking between two black triangles in the bar at the bottom of the gradient selects one segment to be edited—it appears bright while the others go dark. Like this:
Now I can edit the colour and opacity within that segment. The RLM70 colour I set at the start has been inherited by all the segments I’ve created, so all I need to do is tweak the opacity. For the first (leftmost) segment, I leave the left endpoint unedited, but bring up Right Endpoint’s Color…. Now, because my calculated opacities from the spreadsheet run from 0 to 100, I click on the 0..100 button, and then set A to 80, the figure for the first eighth of my 3-blade prop.
(Notice how the RGB numbers seem to have changed from the original 56/62/50—that’s just the effect of changing the scale from 0..255 to 0..100, and the underlying colour has stayed the same.)
Then it’s just a matter of selecting each segment in turn, and editing the opacity. For the other segments, I need to make sure the left end of the segment inherits its opacity from the right end of the previous segment—I do that by using the sequence Load Left Color From…/Left Neighbor’s Right Endpoint from the right-click menu. Then I repeat the process above to set the opacity for the right endpoint. And so on. Here’s the final result, with a distinctive dark band a quarter of the way out, created by the broad bases of the paddle blades on this propeller.
There’s one last thing to do, which will come in handy later. I select the leftmost segment, and then right-click to Split Segment at Midpoint. I select the leftmost of these new segments, and set its left and right endpoints to black (RGB 0/0/0) with maximum opacity. Then I select the new segment immediately to its right, and set the opacity of its left endpoint to maximum. That ends up looking like this:
The narrow black segment at left is going to end up as a black dot marking the centre of the propeller disc. But it’s a little too broad at present. I can fix that by dragging the leftmost white triangle all the way to the left, and then dragging the neighbouring black triangle so as to close up the black segment while expanding the segment to its right.
Now I’m ready to use my gradient to create a prop disc.
I start with a new blank image using File/New… from the menu bar. Since I measured my propeller radius at 24mm, I make my blank 60mm across, to give plenty of space. And I note that the default resolution is 300 pixels per inch, which matches my printer settings.
Then I go through Tools/Paint Tools/Gradient to bring up the gradient tool at the left of the work area. I set Shape to “Radial”, and check that the Gradient is “BV 138 3-blade prop”. (If it isn’t, clicking on the little square to the left of Gradient brings up a list of available gradients.) I’ve captured all that in the screen-shot below:
Click to enlarge
Once all that’s set up, I plonk my cursor in the middle of my new blank image, hold down the left mouse button, and drag it outwards towards the edge of the image. And my propeller disc appears.
To get the size right, I need to glance at the bottom left of the screen, where GIMP gives me a readout of the radius of the pattern I’m creating—I need to tune it to 24mm, give or take a hundredth of a millimetre.
And then I’m done. I go through File/Export As… from the menu bar, and click on Select File Type (By Extension) so that I can save a *.jpg image to some directory where I can find it again.
Having gone through the same process for my 4-bladed propeller, I can print a test sheet to check that my prop discs are the right size:
Click to enlarge
Then I can print the discs on to a transparent sheet. Here, I’ve used an ink-jet compatible overhead transparency. My compass cutter is set to 24mm, the measured prop radius, and I can use the black dot I created in my colour gradient in GIMP to ensure that my cut disc is properly centred.
Click to enlarge
I don’t use laser transparencies, because the laser printer tends to a bake a curve into the transparent sheet which is very difficult to remove. I’ve had success in the past with printing on to transparent decal paper, and then laying the decals on to discs cut from transparent plastic sheet—you can produce a thicker and more rigid final product in that way, at the expense of several more production steps. And be sure not to use plastic so thick the compass cutters won’t go through it!
Preparing the propeller bosses and spinners is very much kit-dependent. Obviously, the propeller blades need to be removed from the boss, and the boss split so as to accommodate the plastic prop disc. For the BV 138 I trimmed a millimetre or so off the back of the spinners, replacing it with appropriately sized styrene tube, and filled the holes in the side of the spinner, producing a two-part assembly in which I could sandwich the prop disc.
Click to enlarge
I then used a hole punch to make appropriately sized holes in the middle of my discs, so that I could slide them on to the propeller spindle.
Click to enlarge
On other occasions I’ve simply had to glue the discs in place within the split boss and spinner.
Here’s the final result, with the spinners painted up:
Click to enlarge
And here they are on my BV 138 mine-sweeper:
Click to enlarge
Click to enlarge
Click to enlarge
There are a couple of limitations to this approach. It’s visually unsatisfying once you get up to larger scales (but then again, the alternatives are, too). And if your propeller has white markings on it, you’re out of luck unless you have an expensive printer that uses white ink.
I’ve also had a request for a tutorial on how to add yellow safety tips to propellers, for instance of the kind used by the RAF and USAF during the Second World War. It’s easy enough to do, and all the necessary knowledge is actually present in this post, but I’ll add a supplement at some time in the future that shows how I produced the yellow tipped propellers on my Supermarine Walrus:
The good people at the National Library of Scotland have gone to the trouble of georeferencing a large collection of out-of-copyright historical maps of Scotland (and some of the wider UK), and this is a fabulous resource for anyone who wants to explore their local history and geography. And it got me hankering for the ability to load such detailed maps into a portable GPS-enabled device.
Now, my go-to service for georeferenced electronic Ordnance Survey maps is usually Anquet. Mainly, I use them on my PC or laptop, but I also keep a few local topographic maps on my mobile phone, and use them for the occasional bit of GPS navigation. Anquet also used to sell a variety of historical Ordnance Survey maps, but they were fairly pricey, and I anyway discover that the service now seems to have been discontinued.
So I began to wonder if I could parasitize the work of the National Library of Scotland, and get a copy of their georeferenced map on to my phone. And it turns out I could. Here’s what I did.
I dusted off and updated my old copy of the venerable OziExplorer software on my PC. OziExplorer has been around for decades, dating back to a time when it was expensive or impossible to get good quality maps into a hand-held navigation device. The unique feature it offers is the ability to import map images (in those days, from scanned paper maps) and “calibrate” them with latitude and longitude information. I bought my own copy of the program years ago. It’s nowadays fairly expensive, and probably not something you’d purchase for a one-off project. However, I’m pretty sure the trial version will let you do everything I’m describing here, if you’re prepared to put up with restarting it every hour.
My next step was to take a screenshot of the Ordnance Survey map from the NLS website. I use Greenshot for these tasks, but there are many options.
Click to enlarge
I fed this image to OziExplorer, using the “Load And Calibrate Map Image” option from the File menu.
OziExplorer is extremely versatile in how it calibrates map images. If the map gridlines run parallel to the edges of the image (as they do in the NLS maps), it only requires three calibration points, preferably close to three corners of the image. For skewed maps, or maps with curved gridlines, more points are needed.
But first I need to tell OziExplorer what map projection was used, in the Setup tab of the calibration window at top right.
From the drop-down menus, I choose “Ord Srvy Grt Britn” for my Map Datum, and “[BNG] British National Grid” for Map Projection. The next three tabs in this window are the set-up for the three calibration points.
So now it’s back to the NLS map, with a notepad and pencil, to write down coordinates for three points. I just place my cursor over a suitable point, and then read off the coordinates at the bottom right of the screen. When I started doing this, I spent some time casting around for suitable natural features or buildings on the map, before I had the blinding revelation that the text on the map would work just as well for this purpose. So here I am with the cursor on the dot of the first “i” of Menzieshill.
And here are the associated coordinates for that point:
What I want to feed to OziExplorer are the letters and numbers in bold in the top line—these are the Ordnance Survey grid square letters, and the easting and northing values. It’s important not to use the latitude and longitude provided by the NLS, since this will create a position error on the order of a hundred metres if transferred to OziExplorer. The NLS is providing the global standard WGS84 coordinates, which is what your GPS receiver tells you. But once you’ve stipulated to OziExplorer that you’re using the British National Grid, it then assumes (I think) that any latitude and longitude you enter pertain to coordinates on the specific ellipsoid on which the BNG is based, which is not the same shape and orientation as the WGS84 ellipsoid.
The underlying reason for the mismatch in latitude and longitude doesn’t really matter for practical purposes, though—just be sure to use the grid letters and numbers offered by the National Library of Scotland as your input to OziExplorer.
Going back to OziExplorer armed with my three calibration points, I enter the first set of coordinates by opening the “Point 1” tab in the calibration window at top right. This changes the cursor to a set of cross-hairs that I use to select the same points I copied off the NLS map:
Positioning the cross-hairs accurately is aided by the little magnified square that appears on the screen at top left—you can see it to the left of my screenshot above.
Once I have the position right, I click to set my calibration point:
And then I enter the grid reference for Point 1:
Then it’s just a matter of repeating the process for Point 2 and Point 3, and hitting Save. OziExplorer saves a little file with the same name as the map image file, but with the suffix *.map, and the map image is now calibrated.
In a minute I’ll go on to explain how I moved a calibrated map to my phone, but there’s one other thing that’s worth dealing with at this point. Even with a UHD monitor, you may want to capture more than one screenful to get complete coverage of an area of interest. This is where OziExplorer‘s free “Map Merge” utility comes in. It will combine any overlapping array of calibrated OziExplorer maps into a single large image.
So for my little project relating to Dundee’s abandoned railway lines, I captured a series of screenshots of the 1903 Ordnance Survey map from NLS, and calibrated them in OziExplorer as described above. This involves jotting down quite a lot of calibration coordinates, but not as many as you might expect—because the screenshot edges must overlap to produce a single large map, and because the calibration points need to be at the corners of each image, then calibration points can and should be reused, to ensure that the images are perfectly aligned in the final map.
Then I open Map Merge, and point it at the folder on my hard drive containing all the map images and their associated *.map files. When these are imported, Map Merge tiles them together to display the coverage of the final map:
Click to enlarge
When I’m happy with the coverage, I tell Map Merge to create a map from the selected maps:
I also need to tell it what projection and scale to use:
And then I just sit back and wait for Map Merge to zip all the individual files together into one calibrated map, which is saved to the hard drive as two files—an image file with extension *.ozfx3, and a *.map. calibration file for that image. I can load these back into OziExplorer to make sure everything is aligned as it should be.
To get this final map on to my phone, I needed to download and install theOziExplorer Android app. There’s nothing for Apple users, unfortunately, but there is a version for PocketPC handheld devices, which is a bit of a legacy market these days. You can find details on the OziExplorer website. Again, the full version of the Android app is distinctly pricey, but the trial version will do what I describe here, if you don’t mind a prominent watermark on your map display, and having to restart the app every fifteen minutes.
With the app installed on my phone, I plugged it into my PC via a USB cable, and used Windows Explorer to navigate my way to the phone’s OziExplorer\Maps folder. Then I copied across the *.ozfx3 and *map files created by Map Merge.
And that was that. When I opened the OziExplorer app on my phone, I was able to call up my Victorian OS map and follow the line of my disappeared railway using the phone’s GPS. So here I am on the Perth Road, just about to set off cross-country:
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”:
Click to enlarge
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:
Click to enlarge
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.)
Click to enlarge
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:
Click to enlarge
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.
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.
Click to enlarge
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….
Click to enlarge
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:
Click to enlarge
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.)
Click to enlarge
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.
Click to enlarge
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.)
Click to enlarge
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.
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:
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.
Click to enlarge
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:
Click to enlarge
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:
Click to enlarge
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.
Click to enlarge
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:
Click to enlarge
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.
Click to enlarge
(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:
Click to enlarge
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:
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:
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.
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:
Click to enlarge
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:
Click to enlarge
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.
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.
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.
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.
Click to enlarge
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:
Click to enlarge
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:
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:
Click to enlarge
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:
* 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.
Back in 1995, a little packet of laminated cardboard diagrams fell through my letterbox. Dave Hewitt, editor of The Angry Corrie, wanted me to write a review of these items. Which I did—it appeared in TAC25, Nov ’95-Jan ’96.
They were called ViewFinder Panoramas, they’d been created by Jonathan de Ferranti, and in my opinion they were things of exquisite, minimalist beauty. Each laminated strip showed the view from the summit of some named hill, colour-coded and annotated to allow the easy identification of other hills. They had been produced from Ordnance Survey Digital Elevation Models, rendered so as to depict the curvature of the Earth and the effects of atmospheric refraction, and then carefully annotated with the names and distances of individual peaks. On occasion, magnified sections were inset to provide additional detail. And features near the horizon were subtly stretched vertically so as to bring out the detail without giving the impression of distortion.
Here’s a comparison of the view eastwards from the summit of Ben Hope, compared to the corresponding ViewFinder diagram:
Click to enlargeClick to enlarge
From the colour-coded distances, to the sector indicator at bottom left, to the bearings along the top of frame, it was a beautifully designed product. ViewFinders retailed for £1, or £1.50 for the larger, more complex products. You could order a bespoke view from the summit of your favourite hill for £16. Nowadays the entire catalogue is freely available on-line, covering worldwide views.
In 1999, Jonathan de Ferranti and I wrote an article together for the Scottish Mountaineering Club Journal, investigating whether it was possible to see any part of the Cuillin ridge in Skye from the Cairngorm plateau.* In this, we used Jonathan’s ViewFinder technology to revisit a question first raised by Guy Barlow in the same journal in 1956.† Barlow had constructed a wood and paper model, and concluded that Sgurr a’Ghreadaidh, on the Cuillin ridge, would be visible from the summit of Cairn Toul in the Cairngorms, because of a fortuitous sightline down the length of Glen Shiel. Jonathan produced a rendering of the same view and discovered that, although Barlow had the alignments exactly correct, he had neglected to allow for the position of Bla Bheinn, which sits east of the main Cuillin ridge, and which neatly blocked the view of Sgurr a’Ghreadaidh. The glimpse of Bla Bheinn, 90 miles away, was minute, occupying more or less a single pixel of the ViewFinder panorama, and in reality would need a telescope, strong refraction and perfect seeing conditions to appreciate. (In the scan below, Bla Bheinn takes its Anglicized spelling, Blaven.)
All of this is a roundabout introduction to Fabio Soldati’s excellent PeakFinder app, which is the natural successor to ViewFinder—indeed Jonathan de Ferranti is credited with providing some of the Digital Elevation Model data used by PeakFinder. With the huge leaps in processing speed and storage capacity that have occurred during the last two decades, it’s now possible to perform the necessary rendering tasks on the fly, producing annotated panoramas of pretty much anywhere in the world, on demand. Apps are available for Android and Apple phones at a cost of a few pounds, and there’s also a rather lovely on-line version. Here’s the view from Ben Hope again, compared with PeakFinder‘s on-line rendered view, and the version displayed by my rather primitive Android phone.
Click to enlargeClick to enlargeClick to enlarge
The on-line version provides shading, shows lochs and coastlines, and offers a few other bells and whistles, but the more basic rendering on my phone is beautifully clear. And having this software as a phone app produces multiple benefits. It can use the phone’s GPS to generate an annotated panorama for your current location, wherever that might be. And the app keeps its database locally, so it will work without a phone signal, provided you have already made the appropriate download. One quick 20MB download covers the whole of the UK, and you can add or delete additional areas as required, with most of the world available in handy chunks of data. If you have a smarter phone than I have, the app will use the phone’s orientation data to overlay its labels on the real view seen by your phone’s camera. This not only lets you easily figure out what you’re look at, but allows you to keep and share an annotated photograph. (Details on that one here.)
Apart from using your phone’s current location, you can select a different location by choosing from PeakFinder‘s extensive names database, tapping on Google Maps (you need a data connection for that), or by entering latitude and longitude coordinates.
Tapping on any of the named peaks in the displayed panorama brings up some information about that feature, and you can also flit across to look at the view from its summit. The names of all the visible peaks in the panorama can be displayed, searched, and sorted by elevation, distance or heading. Tap on one of these names, and you’re returned to the display with a handy marker pointing out that summit’s location. So with a couple of quick taps I was able to establish that the most distant feature visible from the summit of Dundee Law is Windlestraw Law, east of Peebles and a remarkable 88km away. Here’s the PeakFinder display showing me where to look for it:
Click to enlarge
The display units are configurable, and you can pop up depictions of the tracks of sun and moon across the sky, for a given date. Here’s the sun rising over the Orkneys from Ben Hope:
Click to enlarge
Is it accurate? It certainly seems to be, when compared to summit photographs from my collection. For me, Jonathan de Ferranti’s ViewFinder panoramas are the gold standard, so I challenged PeakFinder to show me the extremely marginal view of Bla Bheinn from Cairn Toul that Jonathan identified twenty years ago. Here it is again:
Here’s the view from the web-based version of PeakFinder, with Bla Bheinn again occupying pretty much a single pixel:
Click to enlarge
And here’s the view on my phone, zoomed in to its maximum extent:
Click to enlarge
No Bla Bheinn. I suspect the difference comes from either the screen resolution or the processing limitations of my dumb phone.
Setting aside ridiculously exacting tests like the one above, this is an extremely impressive bit of a kit, even more so if you have a phone that will allow you to use the app’s photographic annotation mode. If you’ve ever sat by a cairn and indulged in an endless, fruitless debate about the identity of some little notch on the horizon (and which of us has not?), then you’ll certainly want to spring a few quid on this lovely little app.
* “On Seeing The Cuillin From The Cairngorms—Again” SMCJ 1999, Vol. 37 No. 190 pp 42-8. † “On The Possibility Of Seeing The Cuillin From The Cairngorms” SMCJ 1956, Vol. 26 No. 147 pp 16-24.
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”:
