Movable Type Home Page

Movable Type Scripts


Convert co-ordinates between WGS84 and OSGB36

Before I started writing these geodesy scripts, I assumed a lat/long point was a lat/long point, and that was it. Since then, I have discovered that – if you’re being accurate – you need to know what datum you are working within.

In the UK, a latitude/longitude point in WGS84 (as generally used by GPS systems or any world-wide reference system) can be over 100 metres from the same latitude/longitude point in OSGB36 (as used in all Ordnance Survey mapping). The exact difference varies according to location. If you are using Vincenty formulae for calculating distances between points on an ellipsoidal model of the earth, these differences can become relevant.

Note: this is why the Greenwich Meridian shows up about 100 metres from the 0° meridian on GPS units: try 51°28′39″N, 000°00′00″W  as an OSGB36 point...

Functional demo
Latitude Longitude
WGS84
OSGB36

To convert between datums, a ‘Helmert transformation’ is used. The Ordnance Survey explain the details in section 6 (and the annexes) of their Guide to coordinate systems in Great Britain.

The procedure is:

  1. convert polar lat/long/height φ, λ, h to cartesian co-ordinates x, y, z (using the source ellipsoid parameters)
  2. apply 7-parameter Helmert transformation; this applies a 3-dimensional shift, rotation, and scale
  3. convert cartesian co-ordinates back to polar (using the destination ellipsoid parameters)

1 convert (geodetic) latitude/longitude to cartesian:

e² = (a²−b²) / a² (eccentricity of source ellipsoid )
ν = a / √(1 − e² · sin²φ) (transverse radius of curvature)
x = (ν+h) · cosφ · cosλ
y = (ν+h) · cosφ · sinλ
z = ((1−e²)·ν + h) · sinφ

2 apply Helmert transform

The Helmert transform is given by:

transform matrix

Hence:

x′ = tx + (1+s) · x rz · y + ry · z
y′ = ty + rz · x + (1+s) · y rx · z
z′ = tzry · x + rx · y + (1+s) · z

3 convert cartesian co-ordinates back to latitude/longitude

While the conversion from geodetic to cartesian is straightforward, converting cartesian to geodetic is a complicated problem.

There are a number of possible approaches: this uses Bowring’s 1985 method (The Accuracy of Geodetic Latitude and Height Equations – Survey Review Vol 28, 218, Oct 1985), which provides approximately μm precision on the earth's surface, in a concise formulation. If you have more demanding requirements, you could compare e.g. Fukushima (2006), Vermeille (2011), Karney (2012), and others.

e² = (a²−b²) / a² (1st eccentricity of ellipsoid)
ε² = (a²−b²) / b² (2nd eccentricity of ellipsoid)
ν = a · √(1 − e² · sin²φ) (length of normal terminated by minor axis)
p = √(x² + y²)
R = √(p² + z²)
tanu = (b·z)/(a·p) · (1 + ε² · b/R) (17)
tanφ = (z + ε²·b·sin³u) / (pe²·a·cos³u) (18)
tanλ = y / x
h = p·cosφ + z·sinφa²/ν (7)

The Ordnance Survey say a single Helmert transformation is accurate to within about 4–5 metres (between WGS84 and OSGB36) – for greater accuracy, a ‘rubber-sheet’ style transformation, which takes into account distortions in the ‘terrestrial reference frame’ (TRF), must be used: if you’re learning anything from this page, you don’t want even to think of going there...

For other scripts for calculating distances, bearings, etc between latitude/longitude points, see my Lat/Long page. I have also done a script for converting between (OSGB36) lat/long and OS grid references.


See below for the JavaScript source code, also available on GitHub. Note I use Greek letters in variables representing maths symbols conventionally presented as Greek letters: I value the great benefit in legibility over the minor inconvenience in typing.

With its untyped C-style syntax, JavaScript reads remarkably close to pseudo-code: exposing the algorithms with a minimum of syntactic distractions. These functions should be simple to translate into other languages if required, though the object literal notation (used for ellipsoid & transform parameters) is particularly concise in JavaScript.

I have extended base JavaScript object prototypes with trim(), toRadians(), and toDegrees() methods: I don’t see great likelihood of conflicts; trim() is now in the language, and degree/radian conversion is ubiquitous.

OSI MIT License I offer these scripts for free use and adaptation to balance my debt to the open-source info-verse. You are welcome to re-use these scripts [under an MIT licence, without any warranty express or implied] provided solely that you retain my copyright notice and a link to this page.

If you need any advice or development work done, I am available for consultancy.

If you have any queries or find any problems, contact me at ku.oc.epyt-elbavom@oeg-stpircs.

© 2006-2014 Chris Veness