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.
POIgraves also offers a range of interesting data, including youth hostel locations.
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:
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:
2,Feature,153792,822358,30,Choire a’ Caise
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.
2 thoughts on “Ordnance Survey OpenData In QGIS 3: Part 4”
Thanks for excellent series of tutorials on map production with Qgis. I have been using the package for a number of years but you demonstrated a number of features I was unaware of.
I’m glad you found it useful.