.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. \*(C+ will
.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
. ds C`
. ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
. if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. if !\nF==2 \{\
. nr % 0
. nr F 2
. \}
. \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "Geo::Coordinates::OSGB::Background 3pm"
.TH Geo::Coordinates::OSGB::Background 3pm "2022-12-06" "perl v5.36.0" "User Contributed Perl Documentation"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
Geo::Coordinates::OSGB::Background \- Background and extended description
.SH "VERSION"
.IX Header "VERSION"
2.20
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
These notes are part of Geo::Coordinates::OSGB, a Perl implementation of
latitude and longitude co-ordinate conversion for England, Wales, and
Scotland based on formulae and data published by the Ordnance Survey of
Great Britain.
.PP
These modules will convert accurately between an \s-1OSGB\s0 national grid
reference, and coordinates given in latitude and longitude using the
\&\s-1WGS84\s0 model. This means that you can take latitude and longitude
readings from your \s-1GPS\s0 receiver, (or read them from Wikipedia, or Google
Earth, or your car's sat-nav), and use this module to convert them to an
accurate British National grid reference for use with one of the
Ordnance Survey's paper maps. And \fIvice versa\fR, of course.
.PP
These notes explain some of the background and implementation details
that might help you get the most out of them.
.PP
The algorithms and theory for these conversion routines are all from \fIA Guide
to Coordinate Systems in Great Britain\fR published by the \s-1OSGB,\s0 April 1999
(Revised December 2010) and available from the Ordnance Survey
website . You may also like to read some of
the other introductory material there. Should you be hoping to adapt this code
to your own custom Mercator projection, you will find the paper called
\&\fISurveying with the National \s-1GPS\s0 Network\fR, especially useful.
.SS "Upgrading from V2.09 or earlier"
.IX Subsection "Upgrading from V2.09 or earlier"
These modules suffered a major overhaul in V2.10 which changed the
semantics and interface. The motivation for the change was to simplify
the interface, to make \s-1WGS84\s0 the default model for latitude and
longitude, and to speed up conversions. This section explains what you
might have to change to get your old code to work with V2.10 and above.
.IP "\(bu" 4
The module structure changed from V2.09 to V2.10 so it would probably be
a good idea to clean up any old installation you have and re-install a
new version so that none of the old files hangs about. The simplest way
to do this is to use the \f(CW\*(C`cpanm\*(C'\fR application.
.IP "\(bu" 4
The parsing and formatting routines have been split into a separate
module, so before V2.10 you could do this:
.Sp
.Vb 1
\& use Geo::Coordinates::OSGB \*(Aq:all\*(Aq; # Don\*(Aqt do this any more
.Ve
.Sp
now you need to do this:
.Sp
.Vb 2
\& use Geo::Coordinates::OSGB qw(grid_to_ll ll_to_grid);
\& use Geo::Coordinates::OSGB::Grid qw(parse_grid format_grid);
.Ve
.IP "\(bu" 4
The old \f(CW\*(C`OSTN02.pm\*(C'\fR module has been removed. The data and the
functions it provided are now integrated into \f(CW\*(C`OSGB.pm\*(C'\fR. The
old \f(CW\*(C`OSGB36_to_ETRS89\*(C'\fR and \f(CW\*(C`ETRS89_to_OSGB36\*(C'\fR functions are
now built into \f(CW\*(C`ll_to_grid\*(C'\fR and \f(CW\*(C`grid_to_ll\*(C'\fR; the \s-1OSTN\s0 data
is now used automatically when needed.
.IP "\(bu" 4
The main conversion routines now assume the \s-1WGS84\s0 model for lat/lon
coordinates. If you still want to work with the \s-1OSGB36\s0 model for
lat/lon, then you need to add the \f(CW\*(C`{ shape => \*(AqOSGB36\*(Aq }\*(C'\fR option
when converting. In other words if you did this before:
.Sp
.Vb 1
\& my ($e, $n) = ll_to_grid(52.5, \-2);
.Ve
.Sp
then to get exactly the same results, you now need to do this
.Sp
.Vb 1
\& my ($e, $n) = ll_to_grid(52.5, \-2, { shape => \*(AqOSGB36\*(Aq } );
.Ve
.Sp
On the other hand, if you are working with the \s-1WGS84\s0 model, then before
V2.10 you had to do this:
.Sp
.Vb 2
\& # Old and exact
\& my ($e, $n) = ETRS89_to_OSGB36(ll_to_grid(52.5, \-2));
.Ve
.Sp
or this:
.Sp
.Vb 2
\& # Old and approximate
\& my ($e, $n) = ll_to_grid(shift_ll_from_WGS84(52.5, \-2));
.Ve
.Sp
now you can just do:
.Sp
.Vb 1
\& my ($e, $n) = ll_to_grid(52.5, \-2);
.Ve
.Sp
This means that the most likely use case is the default. In other words
you can take lat/lon from your \s-1GPS\s0 and get correct grid references by
default
.IP "\(bu" 4
The functions \f(CW\*(C`shift_ll_into_WGS84\*(C'\fR and \f(CW\*(C`shift_ll_from_WGS84\*(C'\fR are
no longer provided. They were not very accurate, and they were
confusing. \f(CW\*(C`ll_to_grid\*(C'\fR and \f(CW\*(C`grid_to_ll\*(C'\fR now do the necessary
adjustments for you automatically.
.IP "\(bu" 4
The functions to parse and format grid references are moved to
\&\f(CW\*(C`OSGB/Grid.pm\*(C'\fR. They have also been radically simplified, so that
there are now only two functions: \f(CW\*(C`parse_grid\*(C'\fR and \f(CW\*(C`format_grid\*(C'\fR.
The old names like \f(CW\*(C`parse_GPS_grid\*(C'\fR and \f(CW\*(C`format_grid_trad\*(C'\fR are
retained with their former meanings, but they are just synonyms
for the two core functions.
.IP "\(bu" 4
The functions to parse and format lat/lon have been removed. They
were not really a core function of this module. There are other modules
on \s-1CPAN\s0 to deal with latitude and longitude. I also give an example of
how to format decimal degrees as degrees, minutes, and seconds in
\&\f(CW\*(C`examples/bngl.pl\*(C'\fR.
.SS "Coordinates and ellipsoid models"
.IX Subsection "Coordinates and ellipsoid models"
This section explains the fundamental problems of mapping a spherical
earth onto a flat piece of paper (or computer screen). A basic
understanding of this material will help you use these routines more
effectively. It will also provide you with a good store of ammunition
if you ever get into an argument with someone from the Flat Earth
Society.
.PP
It is a direct consequence of Newton's law of universal gravitation (and
in particular the bit that states that the gravitational attraction
between two objects varies inversely as the square of the distance
between them) that all planets are roughly spherical; if they were any
other shape gravity would tend to pull them into a sphere. On the other
hand, most useful surfaces for displaying large scale maps (such as
pieces of paper or screens) are flat. Therefore the fundamental problem
in making a map of the earth is that the curved surface being mapped
must be distorted at least slightly in order to get it to fit onto a
flat map.
.PP
This module sets out to solve the corresponding problem of converting
latitude and longitude coordinates (designed for a spherical surface) to
and from a rectangular grid (for a flat surface). A spherical
projection is a fairly simple but tedious bit of trigonometry, but the
problem is complicated by the fact that the earth is not quite a sphere.
Because our planet spins about a vertical axis, it tends to bulge out
slightly in the middle, so it is more of an oblate spheroid (or
ellipsoid) than a sphere. This makes the arithmetic even more tedious,
but the real problem is that the earth is not a regular ellipsoid
either; it is an irregular lump that closely resembles an ellipsoid and
which is constantly (if slowly) being rearranged by plate tectonics. So
the best we can do is to pick an imaginary regular ellipsoid that
provides a good fit for the region of the earth that we are interested
in mapping.
.PP
An ellipsoid model is defined by a series of numbers: the major and
minor semi-axes of the solid, and a ratio between them called the
flattening. There are four ellipsoid models that are relevant to the \s-1UK:\s0
.IP "\s-1OSGB36\s0" 4
.IX Item "OSGB36"
The \s-1OSGB36\s0 ellipsoid is a revision of work begun by George Airy the
Astronomer Royal in 1830, when the \s-1OS\s0 first undertook to make a series
of maps that covered the entire country. It provides a good fit for
most of the British Isles.
.IP "\s-1EDM50\s0" 4
.IX Item "EDM50"
The European standard ellipsoid is a compromise to get a good fit for
most of Western Europe. This is not used by these modules.
.IP "\s-1WGS84\s0" 4
.IX Item "WGS84"
As part of the development of the \s-1GPS\s0 network by the American military
in the 1980s a new world-wide ellipsoid called \s-1WGS84\s0 was defined. This fits most
populated regions of the world reasonably well. (Technically the ellipsoid is
called \s-1GRS80,\s0 and \s-1WGS84\s0 refers to the whole World Geodetic System that is based on it, plus
some very nerdy modifications, but for the purposes of this module it's just a label).
.IP "\s-1ETRS89\s0" 4
.IX Item "ETRS89"
The European Terrestrial Reference System is also based on \s-1GRS80,\s0 and for our
purposes is identical to \s-1WGS84.\s0 The technical difference is that in the \s-1ETRS89\s0
system assumes that the Eurasian tectonic plate is the reference, whereas
\&\s-1WGS84\s0 assumes that the American plate is the reference. But this makes no
practical difference whatsoever for the use of these modules.
.PP
The latitude and longitude marked on \s-1OS\s0 maps printed before 2015 are given in
the \s-1OSGB36\s0 model. The latitude and longitude you read from your \s-1GPS\s0 device, or
from Wikipedia, or Google Earth are in the \s-1WGS84\s0 model. So the point with
latitude 51.4778 and longitude 0 in the \s-1OSGB36\s0 model is on the prime meridian
line in the courtyard of the Royal Observatory in Greenwich, but the point with
the same coordinates in the \s-1WGS84\s0 model is about 120 metres away to the
south-east, in the park.
.PP
In these modules the shape used for the projection of latitude and
longitude onto the grid is \s-1WGS84\s0 unless you specifically set it to use
\&\s-1OSGB36.\s0
.SS "The British National Grid and \s-1OSTN02 / OSTN15\s0"
.IX Subsection "The British National Grid and OSTN02 / OSTN15"
A Mercator grid projection like the British National Grid is defined by
the five parameters defined as constants at the top of the module.
.IP "\(bu" 4
True point of origin Latitude and Longitude = 49N, 2W
.IP "\(bu" 4
False origin easting and northing = 400000, \-100000
.IP "\(bu" 4
Convergence factor = 0.9996012717
.PP
One consequence of the True Point of Origin of the British Grid being
set to 49N, 2W is that all the vertical grid lines are parallel
to the 2W meridian; you can see this on the appropriate \s-1OS\s0 maps (for
example Landranger sheet 184), or on the \s-1PDF\s0 picture supplied with this
package in the \f(CW\*(C`examples\*(C'\fR folder. The effect of moving the False Point
of Origin to the far south west is to make all grid references positive.
.PP
Strictly speaking, grid references are given as the distance in metres
from the False Point of Origin, with the easting always given before the
northing. For everyday use however, the \s-1OSGB\s0 suggest that grid
references need only to be given within the local 100km square as this
makes the numbers smaller. For this purpose they divide Britain into a
series of 100km squares, each identified by a pair of letters: \s-1TQ, SU,
ND,\s0 etc. The grid of the big squares actually used is something like
this:
.PP
.Vb 10
\& HP
\& HU
\& HY
\& NA NB NC ND
\& NF NG NH NJ NK
\& NL NM NN NO NP
\& NR NS NT NU
\& NW NX NY NZ OV
\& SC SD SE TA
\& SH SJ SK TF TG
\& SM SN SO SP TL TM
\& SR SS ST SU TQ TR
\& SV SW SX SY SZ TV
.Ve
.PP
\&\s-1SW\s0 covers most of Cornwall, \s-1TQ\s0 London, \s-1HU\s0 the Shetlands, and there is one
tiny corner of a beach in Yorkshire that is in \s-1OV.\s0 The system has the
neat feature that N and S are directly above each other, so that most Sx
squares are in the south and most Nx squares are in the north. The
system logically extends far out in all directions; so square \s-1XA\s0 lies
south of \s-1SV\s0 and \s-1ME\s0 to the west of \s-1NA\s0 and so on. But it becomes less
useful the further you go from the central meridian of 2W.
.PP
Within each of the large squares, we only need five-digit coordinates \-\-\- from
(0,0) to (99999,99999) \-\-\- to refer to a given square metre. But general use
rarely demands such precision, so the \s-1OSGB\s0 recommendation is to use units of
100m (hectometres) so that we only need three digits for each easting and
northing \-\-\- (000,000) to (999,999). If we combine the easting and northing we
get the familiar traditional six figure grid reference. Each of these grid
references is repeated in each of the large 100km squares but this does not
usually matter for local use with a particular map. Where it does matter, the
\&\s-1OS\s0 suggest that the six figure reference is prefixed with the identifier of the
large grid square to give a `full national grid reference', such as \s-1TQ330800.\s0
This system is described in the notes in the corner of every Landranger
1:50,000 scale map.
.PP
This system was originally devised for use on top of the \s-1OSGB36\s0 model of
latitude and longitude, so the prime meridian used and the coordinates
of the true point of origin are all defined in that system. However as
part of standardizing on an international \s-1GPS\s0 system, the \s-1OS\s0 have
redefined the grid as a rubber sheet transformation from \s-1WGS84.\s0
There is no intrinsic merit to using one model or another, but there's
an obvious need to be consistent about which one you choose, and with
the growing ubiquity of \s-1GPS\s0 systems, it makes sense to standardize on
\&\s-1WGS84.\s0
.PP
The grid remains the primary reference system for use with maps, but
the \s-1OS\s0 has always also printed a latitude and longitude `graticule' around the
edges of the large scale sheets. Traditionally these coordinates have been
given in the \s-1OSGB36\s0 model, but since 2015 the \s-1OS\s0 has been printing revised
editions of Explorer and Landranger sheets with \s-1WGS84\s0 coordinates instead.
The legend of my recently purchased copy of Explorer 311 has this paragraph under the
heading `The National Grid Reference System':
.IP "\(bu" 4
Base map constructed on Transverse Mercator Projection, Airy Ellipsoid, \s-1OSGB\s0 (1936) Datum.
Vertical datum mean sea level. The latitude, longitude graticule overlay is on the \s-1ETRS89\s0 datum
and is compatible with the \s-1WGS84\s0 datum used by satellite navigation devices.
.PP
If your map does not have the last sentence you can assume that it shows \s-1OSGB36\s0
latitude and longitude. Of course, this change makes no difference to the grid
itself.
.PP
The differences between the \s-1OSGB36\s0 and \s-1WGS84\s0 models are only important if you
are working at a fairly small scale. The average differences on the ground
vary from about \-67 metres to + 124 meters depending on where you are in the
country.
.PP
.Vb 10
\& Square Easting difference Northing difference
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\& HP 109 66
\& HT HU 100 106 59 62
\& HW HX HY 73 83 93 51 48 47
\& NA NB NC ND 61 65 81 89 40 39 38 40
\& NF NG NH NJ NK 57 68 79 92 99 30 29 28 26 26
\& NL NM NN NO 56 66 79 91 18 17 15 15
\& NR NS NT NU 66 77 92 100 3 2 1 0
\& NW NX NY NZ 70 77 92 103 \-9 \-8 \-10 \-13
\& SC SD SE TA 77 93 104 112 \-19 \-22 \-23 \-24
\& SH SJ SK TF TG 79 91 103 114 124 \-35 \-34 \-35 \-38 \-40
\& SM SN SO SP TL TM 72 80 90 101 113 122 \-49 \-47 \-46 \-46 \-46 \-47
\& SS ST SU TQ TR 80 90 101 113 121 \-57 \-56 \-57 \-57 \-59
\& SW SX SY SZ TV 71 79 90 100 113 \-67 \-64 \-62 \-62 \-62
.Ve
.PP
The chart above shows the mean difference in each grid square. A
positive easting difference means the \s-1WGS84\s0 Lat/Lon is to the east of
\&\s-1OSGB36\s0; a positive northing difference means it is to the north of
\&\s-1OSGB36.\s0 At a scale of 1:50,000, 124 meters is 2.48 mm, and at 1:25,000
it is 4.96 mm, so the difference is readily visible if you compare new
and old editions of the same map sheet.
.PP
The transformation from \s-1WGS84\s0 to \s-1OSGB36\s0 published in 2002 was called \s-1OSTN02\s0 and
consisted of a large data set that defined a three dimensional shift for each
square kilometre of the country. This dataset was revised (apparently to give
a better fit) in 2015 and the revised dataset is called \s-1OSTN15.\s0
.PP
To get from \s-1WGS84\s0 latitude and longitude to the grid, you project from the
\&\s-1WGS84\s0 ellipsoid to a pseudo-grid and then look up the relevant shifts from
\&\s-1OSTN15\s0 and adjust the easting and northing accordingly to get coordinates in
the \s-1OSGB\s0 grid. Going the other way is slightly more complicated as you have to
use an iterative approach to find the latitude and longitude that would give
you your grid coordinates.
.PP
It is also possible to use a three-dimensional shift and rotation called
a Helmert transformation to get an approximate conversion. This
approach is used automatically by these modules for locations that are
undefined in \s-1OSTN15,\s0 and, if you want to, you can explicitly use it
anywhere in the \s-1UK\s0 by using the \f(CW\*(C`grid_to_ll_helmert\*(C'\fR and
\&\f(CW\*(C`ll_to_grid_helmert\*(C'\fR routines.
.PP
Modern \s-1GPS\s0 receivers can all display coordinates in the \s-1OS\s0 grid system.
You just need to set the display units to be `British National Grid' or
whatever similar name is used on your unit. Most units display the
coordinates as two groups of five digits and a grid square identifier.
The units are metres within the grid square. However you should note
that your consumer \s-1GPS\s0 unit will \fBnot\fR have a copy of the whole of
\&\s-1OSTN15\s0 in it. To show you an \s-1OSGB\s0 grid reference, your \s-1GPS\s0 will be
using either a Helmert transformation, or an even more approximate
Molodenksy transformation to translate from the \s-1WGS84\s0 coordinates it is
getting from the satellites.
.PP
Note that the \s-1OSGB\s0 (and therefore this module) does not cover the whole
of the British Isles, nor even the whole of the \s-1UK,\s0 in particular it
covers neither the Channel Islands nor Northern Ireland. The coverage
that is included is essentially the same as the coverage provided by the
\&\s-1OSGB\s0 \*(L"Landranger\*(R" 1:50000 series maps. The coverage of the \s-1OSTN02\s0 data
set was slightly smaller, as the \s-1OS\s0 did not originally define the model for any
points more than about 2km off shore. The main difference in \s-1OSTN15\s0 is that
coverage is extended to the whole rectangle from grid point (0,0) to (700000,1250000),
although the accuracy far off shore should not be relied on more than about +/\- 5m.
.SS "Implementation of \s-1OSTN\s0 shift data"
.IX Subsection "Implementation of OSTN shift data"
The \s-1OSTN15\s0 is the definitive transformation from \s-1WGS84\s0 coordinates to
the British National Grid. It is published as a large text file giving
a set of corrections for each square kilometre of the country. The \s-1OS\s0
also publish an algorithm to use it which is described on their website.
Essentially you take \s-1WGS84\s0 latitude and longitude coordinates and
project them into an (easting, northing) pair of coordinates for the
flat surface of your grid. You then look up the corrections for the four
corners of the relevant kilometre square and interpolate the exact
corrections needed for your spot in the square. Adding these exact
corrections gives you an (easting, northing) pair in the British grid.
.PP
The distributed data also includes a vertical height correction as part
of the \s-1OSGM15\s0 geoid module, but this is not used in this module, so it
is omitted from the module in order to save space.
.PP
The table of data supplied by the Ordnance Survey contains 876951 rows with
entries for each km intersection between (0,0) and (700000, 1250000). In
\&\s-1OSTN02, 567472\s0 of these entries referred to square kms that are more than 10 km
away from the British mainland (either in the sea or in Eire) and these were
set to zero, indicating that \s-1OSTN02\s0 is not defined at these places. In order
to save more space, these were omitted from the beginning and end of each row
in the data as stored in my original implementation. The last 21 rows (north of
Shetland) were all zeroes, so these were omitted as well.
.PP
My implementation of the \s-1OSTN02\s0 data was included in the \f(CW\*(C`OSGB.pm\*(C'\fR module after
the \f(CW\*(C`_\|_DATA_\|_\*(C'\fR line, and was read using the magic \f(CW\*(C`\*(C'\fR file handle.
In tests this proved to be the fastest way to load all that data, by a long
way.
.PP
There were 1229 rows of data, and each row contained up to 701 pairs of shift
data encoded as pairs of integers representing the shift in mm. Leading and
trailing zeros were omitted, and the number of leading zeros omitted was stored
in the first three characters of each row. The integer pairs were all coded in
a home-grown version of base32 using the character set \f(CW\*(C`0123456789:;<=>?@ABDEFGHIJKLMNO\*(C'\fR. This allowed integers up to 32767 to be
stored in three bytes of printable \s-1ASCII.\s0 that could be stored inside
\&\f(CW\*(C`OSGB.pm\*(C'\fR. Decoding them was very slightly slower than decoding hex strings,
but using 3 bytes integer instead of 4 reduced the memory and loading time by
25%.
.PP
When the \s-1OSGB\s0 revised \s-1OSTN02\s0 to \s-1OSTN15,\s0 they filled in all the zeros, so
this complicated approach was no longer justified. In version 2.20 and above
of this module, the shift data sets are included in the module's `share` directory
and loaded at run time. This turns out to be faster and simpler.
.SS "Accuracy, uncertainty, and speed"
.IX Subsection "Accuracy, uncertainty, and speed"
This section explores the limits of accuracy and precision you can
expect from this software.
.PP
\fIAccuracy of readings from \s-1GPS\s0 devices\fR
.IX Subsection "Accuracy of readings from GPS devices"
.PP
If you are converting readings taken from your own handheld \s-1GPS\s0 device, the
readings themselves will not be very accurate. To convince yourself of this,
try taking your \s-1GPS\s0 on the same walk on different days and comparing the track:
you will see that the tracks do not coincide. If you have two units take them
both and compare the tracks: you will see that they do not coincide.
.PP
The accuracy of the readings you get will be affected by cloud cover,
tree cover, the exact positions of the satellites relative to you (which
are constantly changing as the earth rotates), how close you are to
sources of interference, like buildings or electricity installations,
not to mention the ambient temperature and the state of your
rechargeable batteries.
.PP
To get really accurate readings you have to invest in some serious
professional or military grade surveying equipment.
.PP
\fIHow big is 0.000001 of a degree?\fR
.IX Subsection "How big is 0.000001 of a degree?"
.PP
In the British Isles the distance along a meridian between two points
that are one degree of latitude apart is about 110 km or just under 70
miles. This is the distance as the crow flies from, say, Swindon to
Walsall. So a tenth of a degree is about 11 km or 7 miles, a hundredth
is just over 1km, 0.001 is about 110m, 0.0001 about 11m and 0.00001 just
over 1 m. If you think in minutes, and seconds, then one minute is
about 1840 m (and it's no coincidence that this happens to be
approximately the same as 1 nautical mile). One second is a bit over
30m, 0.1 seconds is about 3 m, and 0.0001 second is about 3mm.
.PP
.Vb 9
\& Degrees Minutes Seconds * LATITUDE *
\& 1 = 110 km 1 = 1.8 km 1 = 30 m
\& 0.1 = 11 km 0.1 = 180 m 0.1 = 3 m
\& 0.01 = 1.1 km 0.01 = 18 m 0.01 = 30 cm
\& 0.001 = 110 m 0.001 = 2 m 0.001 = 3 cm
\& 0.0001 = 11 m 0.0001 = 20 cm 0.0001 = 3 mm
\& 0.00001 = 1.1 m 0.00001 = 2 cm
\& 0.000001 = 11 cm 0.000001 = 2 mm
\& 0.0000001 = 1 cm
.Ve
.PP
Degrees of latitude get very slightly longer as you go further north but
not by much. In contrast degrees of longitude, which represent the same
length on the ground as latitude at the equator, get significantly
smaller in northern latitudes. In southern England one degree of
longitude represents about 70 km or 44 miles, in northern Scotland it's
less than 60 km or about 35 miles. Scaling everything down means that
the fifth decimal place of a degree of longitude represents about
60\-70cm on the ground.
.PP
.Vb 8
\& Degrees Minutes Seconds * LONGITUDE *
\& 1 = 60\-70 km 1 = 1.0\-1.2 km 1 = 17\-20 m
\& 0.1 = 6\-7 km 0.1 = 100\-120 m 0.1 = 2 m
\& 0.01 = 600\-700 m 0.01 = 10\-12 m 0.01 = 20 cm
\& 0.001 = 60\-70 m 0.001 = 1 m 0.001 = 2 cm
\& 0.0001 = 6\-7 m 0.0001 = 10 cm 0.0001 = 2 mm
\& 0.00001 = 60\-70 cm 0.00001 = 1 cm
\& 0.000001 = 6\-7 cm
.Ve
.PP
\fIHow accurate are the conversions?\fR
.IX Subsection "How accurate are the conversions?"
.PP
The \s-1OS\s0 supply test data with \s-1OSTN15\s0 that comes from various fixed
stations around the country and that form part of the definition of the
transformation. If you look in the test files \f(CW\*(C`06\-osgb\-*.t\*(C'\fR you can see
how it is used for testing these modules.
.PP
In all cases translating from the \s-1WGS84\s0 coordinates to the national grid
and vice versa
is accurate to the millimetre, so these modules are at least as accurate
as the \s-1OSGB\s0 software that produced the test data.
.PP
The main difference between the \s-1OSTN02\s0 transformation and \s-1OSTN15\s0
is that the model fits the whole grid area better. With \s-1OSTN02\s0 the
conversions were (very slightly) less accurate for places west of 7W.
Translating from the given grid coordinates to \s-1WGS84\s0 latitude and
longitude coordinates was accurate to 1mm for all of
England, Wales, Scotland and the Isle of Man, but
`round trip' testing (by generating random grid
references, converting them to \s-1WGS84\s0 latitude and longitude and then converting
them back to grid easting and northing), showed
that beyond of 6W (that is in the Scilly Isles and the Hebrides), the
error creeps up to about 4mm if you go as far as St Kilda (at about 8.57W).
The new \s-1OSTN15\s0 numbers are all very slightly different, so that converting any given latitude
and longitude in \s-1WGS84\s0 gives a grid reference that may be a few mm different. But \s-1OSTN15\s0
no longer shows greater round trip errors in the far west. The accuracy of round trip conversions
is less than 1mm for all of the \s-1OSGB\s0 test points in both directions.
.PP
Outside the rectangle covered by \s-1OSTN15,\s0 this module uses the small Helmert
transformation recommended by the \s-1OS.\s0 The \s-1OS\s0 state that, with the parameters
they provide, this transformation will be accurate up to about +/\-5 metres, in
the vicinity of the British Isles.
.PP
You can also use this transformation within the \s-1OSTN15\s0 rectangle by calling the
\&\f(CW\*(C`grid_to_ll_helmert\*(C'\fR and \f(CW\*(C`ll_to_grid_helmert\*(C'\fR routines. If you compare the
output from these routines to the output from the more accurate routines that
use \s-1OSTN15\s0 you will find that the differences are between about \-3.6 metres and
+5.1 metres depending on where you are in the country. In the South East both
easting and northing are underestimated, in northern Scotland they tend to be
overestimated.
.PP
\fIHow fast are the conversions?\fR
.IX Subsection "How fast are the conversions?"
.PP
In general the answer to this question is \*(L"probably faster than you need\*(R", but if
you have read this far you might be interested in the results of my benchmarking.
The slowest part of these routines used to be the loading of the \s-1OSTN15\s0 data set but I have
put considerable effort into making this faster since about version 2.08 of this module, so that
now the accurate routines the use the \s-1OSTN15\s0 data are pretty much the same as the approximate
routines (\f(CW\*(C`ll_to_grid\*(C'\fR is slightly faster, \f(CW\*(C`grid_to_ll\*(C'\fR is slightly slower).
.PP
The tests used to be a bit generous to my code because of the caching
effect. In order to speed up the \s-1OSTN\s0 data lookups, the routines used to keep a
cache of the data fetched, so that if you convert a sequence of coordinates in
the same square km, the second and subsequent lookups will get the data from a
local hash instead of having to read the table. The benchmark test (using the
standard Benchmark.pm approach) consists of getting Perl to run as many
conversions as possible for about 5 \s-1CPU\s0 seconds, and as a result the cache hit
ratio was probably rather exaggerated. Nevertheless this might still be
reasonably representative if you are converting, say, the steps in a \s-1GPX\s0 track,
where successive steps are highly likely to be the same square km as the one
before. Moreover, since converting to \s-1OSTN15, I\s0 have removed the cache look ups
so I'm no longer getting any such boost.
.PP
Last year (2016) with version 2.16 of this module, a typical bench mark run on
my development machine (a Mac Mini server from 2011) using the Apple-supplied
Perl 5.16 gave:
.PP
.Vb 4
\& Subroutine calls per sec ms per call
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\& ll_to_grid 41677 0.024
\& ll_to_grid_helmert 42145 0.024
\&
\& grid_to_ll 18131 0.055
\& grid_to_ll_helmert 35793 0.028
.Ve
.PP
On my newer work machine (a \s-1MBP\s0 from 2015) using the newer Perl 5.18 supplied
with macOS Sierra, I got slightly better numbers with V2.16
.PP
.Vb 4
\& Subroutine calls per sec ms per call
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\& ll_to_grid 50980 0.020
\& ll_to_grid_helmert 68267 0.015
\&
\& grid_to_ll 25831 0.039
\& grid_to_ll_helmert 54371 0.018
.Ve
.PP
But after a bit more work to simplify the way that the cache is implemented
I get this on the same \s-1MBP\s0 with the version 2.19:
.PP
.Vb 4
\& Subroutine calls per sec ms per call
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\& ll_to_grid 69099 0.0145
\& ll_to_grid_helmert 66158 0.0151
\&
\& grid_to_ll 29114 0.0343
\& grid_to_ll_helmert 53969 0.0185
.Ve
.PP
Now, on the same \s-1MBP,\s0 but with the new \s-1OSTN15\s0 data set and the simpler data look up I get:
.PP
.Vb 4
\& Subroutine calls per sec ms per call
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\& ll_to_grid 70730 0.0141
\& ll_to_grid_helmert 63308 0.0158
\&
\& grid_to_ll 32238 0.0310
\& grid_to_ll_helmert 55286 0.0181
.Ve
.PP
In my opinion, this justifies my decision to make the accurate \s-1OSTN\s0 conversion
the default. The approximate Helmert-based routine is no quicker for ll to
grid conversions.
.PP
It is always going to be slightly slower converting from grid to ll, due to the
iterative nature of the algorithm that is built into \s-1OSTN15.\s0 So the
approximate routine is likely to remain slightly faster. Having said that
none of the routines is really slow, since even \f(CW\*(C`grid_to_ll\*(C'\fR averages under 60
microseconds per call on the older machine. `Your mileage may vary', of
course.
.PP
The routines have been tested with various versions of Perl, including recent
versions with the \f(CW\*(C`uselongdouble\*(C'\fR option enabled. Using a locally compiled
version of Perl 5.22 with ordinary doubles, I saw a small improvement on the
Helmert routines, but the default routines are about the same. On the same
system, long doubles slowed everything down by about 10%, and made no
difference to the round trip precision of the routines. Since the formulae were
specifically designed for ordinary double precision arithmetic, Perl's default
arithmetic is more than adequate.
.SS "Maps"
.IX Subsection "Maps"
Since Version 2.09 these modules have included a set of map sheet
definitions so that you can find which paper maps your coordinates are
on.
.PP
See Geo::Coordinates::OSGB::Maps for details of the series included.
The first three series are \s-1OS\s0 maps:
.PP
.Vb 3
\& A \- OS Landranger maps at 1:50000 scale;
\& B \- OS Explorer maps at 1:25000;
\& C \- the old OS One\-Inch maps at 1:63360.
.Ve
.PP
Landranger sheet 47 appears in the list of keys as \f(CW\*(C`A:47\*(C'\fR, Explorer
sheet 161 as \f(CW\*(C`B:161\*(C'\fR, and so on. As of 2015, the Explorer series of
incorporates the Outdoor Leisure maps, so (for example) the two sheets
that make up the map `Outdoor Leisure 1' appear as \f(CW\*(C`B:OL1E\*(C'\fR and
\&\f(CW\*(C`B:OL1W\*(C'\fR.
.PP
Thanks to the marketing department at the \s-1OS\s0 and their ongoing
re-branding exercise several Explorer sheets have been promoted to
Outdoor Leisure status. So (for example) Explorer sheet 364 has
recently become `Explorer sheet Outdoor Leisure 39'. Maps like this are
listed with a combined name, thus: \f(CW\*(C`B:395/OL54\*(C'\fR.
.PP
Many of the Explorer sheets are printed on both sides. In these cases
each side is treated as a separate sheet and distinguished with
suffixes. The pair of suffixes used for a map will either be N and S,
or E and W. So for example there is no Explorer sheet \f(CW\*(C`B:271\*(C'\fR, but you
will find sheets \f(CW\*(C`B:271N\*(C'\fR and \f(CW\*(C`B:271S\*(C'\fR. The suffixes are determined
automatically from the layout of the sides, so in a very few cases it
might not match what is printed on the sheet but it should still be
obvious which side is which. Where the map has a combined name the
suffix only appears at the end. For example: \f(CW\*(C`B:386/OL49E\*(C'\fR and
\&\f(CW\*(C`B:386/OL49W\*(C'\fR.
.PP
Several sheets also have insets, for islands, like Lundy or The Scilly
Isles, or for promontories like Selsey Bill or Spurn Head. Like the
sides, these insets are also treated as additional sheets (albeit rather
smaller). They are named with an alphabetic suffix so Spurn Head is on
an inset on Explorer sheet 292 and this is labelled \f(CW\*(C`B:292.a\*(C'\fR. Where
there is more than one inset on a sheet, they are sorted in descending
order of size and labelled \f(CW\*(C`.a\*(C'\fR, \f(CW\*(C`.b\*(C'\fR etc. On some sheets the insets
overlap the area of the main sheet, but they are still treated as
separate map sheets.
.PP
Some maps have marginal extensions to include local features \- these are
simply included in the definition of the main sheets. There are,
therefore, many sheets that are not regular rectangles. Nevertheless,
the module is able to work out when a point is covered by one of these
extensions.
.PP
In the examples folder there is an extended example showing how to work
with the map data as supplied through the \f(CW\*(C`Maps.pm\*(C'\fR interface.
.PP
The source files for the map data are in the \f(CW\*(C`maps\*(C'\fR directory. The script that
builds \f(CW\*(C`Maps.pm\*(C'\fR from the source files is \f(CW\*(C`build/make_maps_code\*(C'\fR.
.PP
It's probably fair to say that currently (in early 2016) everything about the
maps is still experimental and may change in the future.
.PP
For each series there are two files:
.IP "\(bu" 4
\&\f(CW\*(C`catalogue\*(C'\fR which defines:
an index number for each map (unique to this project);
the sheet number for the map \- not necessarily an integer;
the sheet title as a \s-1UTF8\s0 string;
the current \s-1ISBN\s0 number for maps that have them.
.IP "\(bu" 4
\&\f(CW\*(C`polygons\*(C'\fR which has:
index numbers that match the corresponding \f(CW\*(C`catalogue\*(C'\fR;
sheet numbers that match the corresponding \f(CW\*(C`catalogue\*(C'\fR;
a flag \- an integer to show the status of the entry (no formal meaning);
followed by a \s-1MULTIPOLYGON\s0 in \s-1WKT\s0 format.
.PP
There is one line in each of the files for each map in the series. The data
format for the sheet polygons is Well Known Text (as defined in Wikipedia).
The set of polygons for each map is defined as a \s-1MULTIPOLYGON\s0; a list of
\&\s-1POLYGONS.\s0 There are no holes in any of the polygons. A missing polygon list
is recorded as \*(L"\s-1EMPTY\*(R"\s0 (this is part of \s-1WKT\s0).
.PP
The units are metres from the false point of origin (which is some miles west
of the Scilly Isles). So the south west corner of Landranger sheet 204, which has
traditional grid reference \s-1SW 720 140\s0 is defined in this data as \*(L"172000
14000\*(R". This is essentially what \*(L"parse_grid\*(R" returns. No leading zeros
needed.
.PP
The polygon starts at the south west corner of the sheet and is recorded
anticlockwise. \s-1WKT\s0 insists that the first pair is repeated at the end to close
the polygon. So a simple 40km square Landranger sheet with no insets or
extensions, such as Sheet 152, whose \s-1SW\s0 corner is at \s-1SP 530 300\s0 is recorded as
.PP
.Vb 1
\& (((453000 230000, 493000 230000, 493000 270000, 453000 270000, 453000 230000)))
.Ve
.PP
If the sheet boundary is more complicated than a square, the polygon consists of a coordinate
pair for each corner. Extensions \- where the coloured printing spills
over the neat edge \- are included as part of the main polygon in the appropriate place,
always moving anticlockwise. Extensions don't have to be rectilinear but they
are made up of straight lines. Extensions consisting of administrative boundaries
and labels are ignored. If in doubt, use common sense.
.PP
If an inset is drawn on the map sheet with its own grid margin then it is recorded
as a separate polygon following the \s-1WKT\s0 format, even if it overlaps the main sheet.
.PP
On \s-1OS\s0 Landranger maps, the first (and last) pair should always be the \s-1SW\s0
corner, if an extension affects the \s-1SW\s0 corner, start and end with the regular
corner pair even if they are technically redundant. This allows me to find the
\&\s-1SW\s0 corners currently defined for the Landranger maps easily. In other series,
start somewhere near the \s-1SW\s0 and go anticlockwise.