Using OSTN15 with QGIS

As you may be aware, the United Kingdom has a new transformation model that is OSTN15. But why? What does it mean to the geospatial community?

Without being too nerdy, tectonic plate movement means that the “model” surface (the geoid) is slowly moving away from being the best fit for the coordinate system. It has been 13 years since Ordnance Survey implemented OSTN02, so the shift since then is enormous: a whole 1cm, and vertically it is 2.5cm. See this article here from Ordnance Survey.

The whole story is that sensors—and our ability to calculate our positi0n relative to both the mathematical models and our relative position to those—are constantly evolving. So, just as OSTN02 revolutionised the accuracy of projecting GPS (WGS84) coordinates using a grid transformation (250 points over the seven parameters used until 2002), OSTN15 both uses the OS Net of 250 points but has also been improved further with 12 zero-order stations with accuracy of 2mm horizontal and 6mm vertical.

How will this change the way you use your GIS?

If you are already using OSTN02 for your transformations between EPSG 27700 and EPSG 4326, then you will see only a 5cm improvement over a 1m area at best, and this is based on the worst places in the UK; on average you will see only a 2cm improvement anywhere in the UK. To put this into context, when you are zoomed in to an A3 map to about 1:100, you are talking about a few pixels on the screen. It won’t be groundbreaking (at the moment).

Currently, as this goes to press, the OSTN15 transformation has been available only for a few weeks, and it is still being tested on different software to ensure it works. I am told that Esri UK have been testing it with their software as this is being written.

As with OSTN02, I’ve created a fix for QGIS and OSTN15. I will describe how to implement this farther here.

There are many ways to use proj. Without a GIS you can use it through a command line by defining parameters. QGIS uses the proj library by accessing a spatialite database called srs.db. This is held at .\apps\qgis\resources\srs.db in Windows and Linux.

The proj spatialite database is a relational database that, when analysed, holds tables for coordinate systems, epsg codes & transformations. What is really clever is that it recognises direction of transformation.

Why is direction important?

Most coordinate transformations go from the projected coordinate system to the geographic coordinate system, For example, epsg 4277 to epsg 4326. OSTN15 bucks the trend and is the reverse direction, from 4326 to 4277.

As I found when I first tested OSTN15 with QGIS, I was getting a uniform 200m shift in the data that was being translated, and I was really confused. After talking with the gridfile creator, I discovered that the file was created from ETRS89 to OSGB36, hence the 200m shift I was getting.

QGIS is awesome; you’ve probably overlooked just how clever it is and so did I. Next time you run a transformation, or when you try this one, you may notice that there are two fields noted in the columns SRC (source) and DST (destination), and this is a godsend for solving this issue as QGIS can read the coordinate in both directions.

Show us the magic

So, I talked with Ordnance Survey and found that OSTN15 has been given the epsg of 7709 and has created a new record with the srs.db that is distributed with Windows, Linux & Mac releases. To utilise this, all you need to do is to download the OSTN15 file from Ordnance Survey (here) and then place the OSTN15_NTv2.gsb file in the shared projections folder .\share\proj\OSTN15_NTv2.gsb this has been found to be correct in Mac and Windows (there should be similar in Linux). You know it is the right folder as there should be other .gsb files in there!

You can download the updated srs.db from here; this should be placed in the resources folder that can be found at .\apps\qgis\resources\srs.db – I highly recommend changing the name of the srs.db file in this folder to something like srs.db.old before adding the new version, just in case it doesn’t work for your particular set up. BUT it has been checked on Mac and Windows distributions of QGIS from version 2.12 through to QGIS 2.17.

A Chartered Geographer with more than 15 years experience in GIS, data management, and geospatial innovation, Nicholas has consulted and provided work for most industry sectors such as offshore & onshore renewables, environmental, maritime archaeology, offshore & onshore survey, land management, public rights of way, demography, shipping, and traffic management.
Previously employed with one of the UK’s largest renewable energy consultancies, Nicholas led teams to deliver projects for clients such as National Grid, Eneco, Scottish Power, and Dong.
His career includes working for the UK’s National Mapping Agency, Ordnance Survey.
In recent years, Nicholas has made way for his alter-ego (on social media, at least), Dragons8mycat, a voice for growing the geospatial community and pushing the geospatial software providers for better solutions.
Nicholas currently is the CTO of the end-to-end geospatial solutions company The Carto Group,
Follow him on twitter: @dragons8mycat
His LinkedIn profile is here: https://uk.linkedin.com/in/dragons8mycat

“Using OSTN15 with QGIS” Comments

I’m using QGIS 2.18.10 and I can see the entry in the srs.db file but everytime I try and search for 7709 it won’t find it. Do you have to refresh/update something after the change has been made. Also there are two gsb files one from ETRS to OSGB and one the other way round. I’m assuming it is the OSGB to ETRS one that I need and I have also renamed it to be the same as in the srs.db table OSTN15_NTv2gsb.

Any ideas how to fix?

Thanks,

Duncan

Karl Jones

January 4, 2018 at 10:26 am

I have the same problem (after the SRS has been replaced and the gsb file added) – I cannot see the OSTN15 or 7709 CRS option (in QGIS 2.14.19-Essen). Did you find a solution to this?

Hi Duncan, Karl,
I’ve just re-installed QGIS 2.14 and this method still works.
What are you using for reading the spatialite database? I highly recommend using something like this: http://sqlitebrowser.org/
With regards to direction, with QGIS you do not need to worry, if you use epsg 7709 as the entry, use the OSGB1936 to ETRS89 gsb file

Thanks for looking at this for me. Someone on GIS-exchange suggested updating my QGIS to the latest (which I did – but that didn’t make any difference).

Yes, I used sqlitebrowser to check the content as you recommended – it contains epsg 7709, but I just can’t see this in the CRS selection window.

I also noted the OSTN02 line in the SRS db file as EPSG code 27700 – which suggests that the conversion selecting that code in the CRS window of QGIS should give an accurate transformation – but, if I use that, the positions (when the KML is opened in Google Earth) are circa 20m south of where they should be – so it suggests that it isn’t sub-1m accuracy (when QGIS does the conversion – so I’m not convinced it is using OSTN2) – separate issue, I know, but I’m just trying to find a way to transform National Grid to KML and have good accuracy – which I’m struggling to achieve via OSGB1936 and I can’t access the 7709. Thanks Karl