I get different results using 2 methods to convert co-ordinates from WGS84, epsg:4326 to BNG (British National Grid) epsg:27700. The differences in the plotted eastings and northings values are very small resulting in a difference of approximately 0.5m.

The main reason I am concerned is that when I plot the converted points in QGIS the results from using pyproj are in the same location as the non transformed points from WGS84. Converting the WGS84 points on the fly in QGIS plots the points in the same location as those I converted using the OS software.

I may need to use pyproj in the future and would like to ensure I have used the software correctly.

I am using pyproj and Grid InQuest II software from the Ordnance survey to run the conversions.

WGS84 Co-ordinate set

  1. longitude = -3.209168460809744
  2. Latitude = 55.950621342577172
  3. Altitude = 116.378547668457031

pyproj result and code
x = 324588.97991822625 y = 673725.6892528223

trans1 = Transformer.from_crs("epsg:4326", "epsg:27700")
x1, y1, z1 = trans1.transform (lat, lon, alt)
print ("Transformer lon =   " +str(lon), " lat = " + str(lat) + " x = " + str(x1) + " y = " + str(y1))

Ordnance Survey result
Easting = 324589.0436663538 Northing = 673726.1910941075

OS conversion validation
I have 3 conversion methods from the Ordnance Survey Website

  1. Grid InQuestII source code, used to create result above. https://www.ordnancesurvey.co.uk/business-government/tools-support/os-net/for-developers
  2. Grid InQuestII software, a stand alone application, same co-ordinates but rounded to 2 decimal places
  3. Online conversion page, same result to 3 decimal places. https://www.ordnancesurvey.co.uk/gps/transformation/

The OS website and code converts from from ETRS89, epsg:4937, not WGS84, epsg:4326. I did try using epsg:4937 in pyproj and got the same result as using epsg:4326.

OS comment on using ETRS89, EPSG:4937

In Europe, ETRS89 is a precise version of the better known WGS84 (EPSG code 4326) coordinate reference system optimised for use in Europe; however, for most purposes it can be considered equivalent to WGS84. Specifically, the motion of the European continental plate is not apparent in ETRS89, which allows a fixed relationship to be established between this system and Ordnance Survey mapping coordinate systems.

Rendering in QGIS
I plotted a .geojson file with my original WGS84 lat, long values to see how that location compared with the converted values. I load 2 .csv files, one with the OS conversion and one with the pyproj conversion.

Method 1
Project Properties - Datum Transformations EPSG:4326 to EPSG:27700 selected

WGS84 points and OS points in same locations. pyproj points about 0.5m apart

Method 2
Project Properties - Datum Transformations blank

WGS84 and pyproj points in same location This was the confusing result, I would have accepted a result where the OS conversion was slightly different from the pyproj conversion and the plotting of the WGS84 result was in a slightly different location.

Added images of project reference system and project properties

Project Reference system

Project Properties

full transform

  • It looks a lot like a reference system issue. Can you add the proj definition (from the CRS selection dialog) of EPSG:27700 from qgis and/or from EPSG site? Any conversion on the reference axes is explicit there with the +to_wgs84 parameter
    – Javier JC
    Commented Jun 14, 2020 at 16:07
  • 2
    Can you copy the full datum tranformation, from +proj=pipeline ...,? It goes far to the right of the screen.
    – Javier JC
    Commented Jun 14, 2020 at 16:23
  • 1
    I deleted my answer, it was not precise enough, you should see the docs pyproj4.github.io/pyproj/stable/api/transformer.html and see how you can reproduce the transformation qgis is using.
    – Javier JC
    Commented Jun 14, 2020 at 17:41
  • 3
    Do you have the needed transformation grids installed? pyproj4.github.io/pyproj/latest/transformation_grids.html
    – snowman2
    Commented Jun 14, 2020 at 19:31
  • 1
    Yes, download_grids will be part of that release.
    – snowman2
    Commented Jun 15, 2020 at 12:16

1 Answer 1



This worked for epsg:4326 to epsg:27700 co-ordinate conversion. The instructions will be different for other systems but the principals will be the same.

Download the NTv2 grid information from the following web page, the second link is direct to the .zip.



Unzip to your data directory, the location I used was as follows :-


Pycharm and pyproj automatically finds the correct grid file and my coordinates now plot where I expect.

The following 2 steps did not solve the problem


Gives the following error
AttributeError: 'TransformerGroup' object has no attribute 'download_grids

****NOTE - will be fixed in the next release so check the date ****

I could manually download the file uk_os_OSTN15_NTv2_OSGBtoETRS.tif, however the transformation did not work and when I tried to check the install with tg I got an error. (sorry I forgot to make a copy) I suspect I am missing a step here.

On the same page I had also tried the following 2 installs. They both suceeded but must be missing the NTv2 grid.

conda install -c conda-forge proj-data

conda install -c conda-forge proj-datumgrid-europe proj-datumgrid-north-america proj-datumgrid-oceania proj-datumgrid-world
  • I still get the following error: 'Transformation Inverse of OSGB 1936 to WGS 84 (9) + British National Grid is unavailable', and indeed the link only seems to include grids for ETRS89←→OSGB36, and none for WGS84? Commented Jul 6, 2020 at 1:30
  • Hi, assuming you are using QGIS, you also have to download the NTV2 grid information into QGIS. Download zip file from Ordnance Survey ordnancesurvey.co.uk/business-government/tools-support/os-net/…. Unzip and copy the files to C:\Program Files\QGIS 3.10\share\proj (or equivalent), there are other .gsb files there. I have another issue and there are some links to my sources there gis.stackexchange.com/questions/365132/…
    – Roo
    Commented Jul 6, 2020 at 8:05
  • 1
    I was using pyproj, and solved the issue, which was essentially that I needed to unzip the grids into the PROJ data directory at /usr/local/lib/python3.8/dist-packages/pyproj/proj_dir/share/proj, rather than /usr/local/share/proj (even though the latter was set with the PROJ_DIR environment variable, and set with pyproj.datadir.set_data_dir...). Commented Jul 6, 2020 at 8:42
  • That's useful to know as I have to run a clean install sometime to solve my other problem.
    – Roo
    Commented Jul 6, 2020 at 9:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.